mboost-dp1
.NET performance
Der er efter min mening flere fejl og dårlige råd i dette, men derfor kan det jo godt være interessant:
http://www.smelser.net/blog/post/2011/04/16/A-few-...
som linker til:
http://www.smelser.net/blog/post/2011/02/13/Knowin...
http://www.smelser.net/blog/post/2011/04/16/A-few-...
som linker til:
http://www.smelser.net/blog/post/2011/02/13/Knowin...
Det er interessant at se forholdet mellem tallene.
Det jeg typísk oplever som flaskehalse er dog I/O. Men nu drejer hele verden sig jo ikke om mig og mine projekter.
Det jeg typísk oplever som flaskehalse er dog I/O. Men nu drejer hele verden sig jo ikke om mig og mine projekter.
Det er da meget interessant at poste nogen tal man har målt selv. Desværre er det ikke sikkert at tallene er brugbare, da de potentielt kan variere fra maskine til maskine.
Artiklen (Nummer 2) skriver intet som helst omkring hvordan de er målt eller hvilken maskine var brugt til formålet, hvilket gør den mindre pålidelig.
Artiklen (Nummer 2) skriver intet som helst omkring hvordan de er målt eller hvilken maskine var brugt til formålet, hvilket gør den mindre pålidelig.
#4
Det er jo super med sådan noget konkret info som kan bruges til at evaluere forskellige algoritmer med.
Problemet er at det ikke har noget med virkeligheden at gøre.
Den tid en arithmetisk operation tilføjer til CPU forbrug afhænger udover af operationen også af:
- data type (1/2/4/8 byte int, 4/8 byte FP)
- clock frekvens
- CPU (instruktion X kan godt være 10 gange langsommere nd instruktion Y på en Intel Core i7 men kun 6 gange langsommere på en AMD Phenom X6)
- mode (8 byte int og FP udføres helt forskelligt i 32 bit og 64 bit mode på x86-64)
- hvor data befinder sig (register, L1 cache, L2 cache, RAM, pagefile - noget i magnitude af 0, 1, 10, 100 og 10 millioner ns)
- hvorvidt data er natural aligned eller ej
- hvor godt instruktionen kan overlappe med tidligere og følgende instruktioner (afhænger af om de bruger forskellige ekskverings enheder, hvorvidt alle skal bruge memory connect og hvorvidt der er afhængigheder fordi nogens output er efterfølgendes input)
Arithmetic Operations
Addition 1.0 ns
Subtract 1.0 ns
Multiply 2.7 ns
Divide 35.7 ns
Shift 2.1 ns
Det er jo super med sådan noget konkret info som kan bruges til at evaluere forskellige algoritmer med.
Problemet er at det ikke har noget med virkeligheden at gøre.
Den tid en arithmetisk operation tilføjer til CPU forbrug afhænger udover af operationen også af:
- data type (1/2/4/8 byte int, 4/8 byte FP)
- clock frekvens
- CPU (instruktion X kan godt være 10 gange langsommere nd instruktion Y på en Intel Core i7 men kun 6 gange langsommere på en AMD Phenom X6)
- mode (8 byte int og FP udføres helt forskelligt i 32 bit og 64 bit mode på x86-64)
- hvor data befinder sig (register, L1 cache, L2 cache, RAM, pagefile - noget i magnitude af 0, 1, 10, 100 og 10 millioner ns)
- hvorvidt data er natural aligned eller ej
- hvor godt instruktionen kan overlappe med tidligere og følgende instruktioner (afhænger af om de bruger forskellige ekskverings enheder, hvorvidt alle skal bruge memory connect og hvorvidt der er afhængigheder fordi nogens output er efterfølgendes input)
#5
Mere reelt:
addition:
(0.25-1.0 ns for ekskvering + et sted mellem 0 og 200 ns for at hente data) * en faktor mellem 0.0 og 1.0 p.g.a. overlappende instruktioner
addition:
(0.5-5.0 ns for ekskvering + et sted mellem 0 og 200 ns for at hente data) * en faktor mellem 0.0 og 1.0 p.g.a. overlappende instruktioner
Og det kan man jo ikke bruge til så meget!
Mere reelt:
addition:
(0.25-1.0 ns for ekskvering + et sted mellem 0 og 200 ns for at hente data) * en faktor mellem 0.0 og 1.0 p.g.a. overlappende instruktioner
addition:
(0.5-5.0 ns for ekskvering + et sted mellem 0 og 200 ns for at hente data) * en faktor mellem 0.0 og 1.0 p.g.a. overlappende instruktioner
Og det kan man jo ikke bruge til så meget!
#4
Object reuse er ikke entydigt nogen performance forbedring i systemer med generational garbage collection såsom .NET og Java.
Der er nogen som er begyndt at betragte det som et anti-pattern for objekter hvor creation ikke involverer disk/net IO).
En klassisk tekst (dog Java):
http://www.ibm.com/developerworks/java/library/j-j...
Consider reusing object instances. Samples of each of these can be found in the below Coding Guidelines
Object reuse er ikke entydigt nogen performance forbedring i systemer med generational garbage collection såsom .NET og Java.
Der er nogen som er begyndt at betragte det som et anti-pattern for objekter hvor creation ikke involverer disk/net IO).
En klassisk tekst (dog Java):
http://www.ibm.com/developerworks/java/library/j-j...
In his "Performance Myths Exposed" talk at JavaOne 2003, Dr. Cliff Click offered concrete benchmarking data showing that object pooling is a performance loss for all but the most heavyweight objects on modern JVMs. Add in the serialization of allocation and the dangling-pointer risks, and it's clear that pooling should be avoided in all but the most extreme cases.
#4
Jeg forstår ikke hvad han vil.
Hvis data ikke opdateres, så bør der ikke være nogen omkostning ved multithreaded tilgang.
Hvis man multiplikere data vil jeg forvente lavere cache hit ratio og dermed dårligere performance.
Hvis data opdateres, så er det dyrt at synkronisere adgangen.
Men hvis man multiplikere data, så ændrer man programmets funktionalitet.
Share nothing across threads, even at the expense of memory
Sharing across thread boundaries leads to increased preemptions, costly thread contention, and may introduce other less obvious expenses in L2 cache, and more
When working with shared state that is seldom or never updated, give each thread its own copy even at the expense of memory
Jeg forstår ikke hvad han vil.
Hvis data ikke opdateres, så bør der ikke være nogen omkostning ved multithreaded tilgang.
Hvis man multiplikere data vil jeg forvente lavere cache hit ratio og dermed dårligere performance.
Hvis data opdateres, så er det dyrt at synkronisere adgangen.
Men hvis man multiplikere data, så ændrer man programmets funktionalitet.
Er der ikke også hotspot teknologi involveret, så beregninger osv. falder i eksekvering, hvis de gentages?
Jeg ville i det hele taget hellere have et ikke tidsbaseret mål, som f.eks. instruktioner.
Jeg ville i det hele taget hellere have et ikke tidsbaseret mål, som f.eks. instruktioner.
arne_v (12) skrev:#11
.NET CLR JIT compiler så vidt jeg ved altid første gang koden udføres.
Modsat Java som først JIT compiler når JVM tror det giver mening.
Jeg tænker ikke på kompileringen med på runtime. Der har Java jo sin hotspot teknologi. Jeg tror dog at begrebet hotspot har ændret sig siden jeg først lærte om det i 1997. Det, jeg mener er runtime optimeringer. Jeg har aldrig sat mig helt ind i hvordan det er lavet, for det har ikke været så relevant. Jeg har kun interesseret mig for konsekvensen af det ;)
Brugernavn (13) skrev:Jeg tænker ikke på kompileringen med på runtime.
JIT kompilering er runtime.
Brugernavn (13) skrev:Der har Java jo sin hotspot teknologi.
CLR gør det samme som JVM bortset fra at jeg mener at CLR altid gør det ved første kald mens JVM kan beslutte sig for at vente og se om koden bliver kaldt meget.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Tagwall
Gå til bund