[C++] Performance-problemen in x64 modus?

[Verwijderd]

Hoi,

Ik had een tijd terug een stukje code gepost, elders op het forum: Mijn voorlopige bevindingen over multicore-processing

De bedoeling was in eerste instantie om vooral een beetje te kijken hoe verschillende CPUs en systemen omgingen met multithreading en 32/64-bit code.

Nou had ik in eerste instantie wat problemen met de 64-bit versie. Er werd een recursieve functie aangeroepen met aardig wat argumenten. Omdat ieder argument in 64-bit mode meteen ook 64-bit is, op de stack, hakte dit er aardig in qua bandbreedte, en was de 64-bit versie een stuk trager dan de 32-bit versie.
Beetje onverwacht, maar achteraf gezien best logisch... Toen ben ik de hele code nog maar eens zorgvuldig nagelopen, en heb ik overal zo veel mogelijk geprobeerd 'bits eraf te schaven'.
Dat wierp z'n vruchten af, want op m'n Core2 Duo was de 64-bit versie nu een stukkie sneller dan de 32-bit versie. Da's mooi meegenomen. Op een Pentium D schoot de 64-bit versie helemaal vooruit nu.

Maargoed, er kwamen maar geen mensen met Athlon64/Opteron resultaten in 64-bit... Ik voelde de bui toen al een beetje hangen.
Inmiddels hebben twee mensen met AMD-systemen in 64-bit getest, en inderdaad... De 64-bit versie is gewoon nog steeds trager daar.

Dus mijn vraag is eigenlijk heel simpel: Hoe kan dat nou?
Aangezien het zowel met 1 als met 2 threads gebeurt, lijkt me niet dat het geheugen het probleem is. Het moet haast wel iets zijn binnen de core zelf.
Nou kan ik 2 dingen bedenken:
1) De 32-bit versie drukt de cache al tot het uiterste... In 64-bit modus heb je toch *net* wat meer nodig, omdat bepaalde pointers, stack etc toch 64-bit moeten zijn ipv 32-bit... Dingen die ik eigenlijk niet in de hand heb... Dus gaat de snelheid wat omlaag... hoewel er misschien toch meer rekenkracht is in 64-bit.
2) De 64-bit instructies zijn wat groter en lastiger te decoderen, en misschien struikelt de decoder van de Athlon daar een beetje over, waardoor je net wat minder instructies per seconde kunt verwerken.

Maargoed, als dit het geval zou zijn, heb ik dat niet in de hand, dan perst de code gewoon het uiterste uit de CPU, en moet je het daar mee doen.
Aan de code ligt het niet echt, lijkt me... want de Intels halen wel winst. En het is bekend dat hun caches groter en sneller zijn, vandaar dat ik denk dat dat ermee te maken heeft... Zeker in het geval van de Pentium D, wat niet echt een wonder is qua IPC, en nogal berucht is omdat 64-bit er achteraf maar een beetje opgeplakt is.
Heeft iemand nog andere ideeen, of eigen ervaring met problemen in 64-bit? Specifiek op Athlon misschien?
Het zou mooi zijn als ik de Athlon op de een of andere manier toch sneller zou kunnen krijgen... maar ik heb nu geen idee waar ik zou moeten beginnen... Alles wat ik kon bedenken, had ik al gedaan.

Het is overigens gecompileerd met Microsoft Visual Studio.NET 2005. Misschien eens andere compilerflags gebruiken? Maar welke?

[LauPro]

Ik denk dat je het probleem wat eenzijdig benaderd. 64bit is tov 32bit 2 keer zo langzaam te verwerken, dat is de basis. Echter zit het rendement van 64bit tov 32bit niet in hoe snel het te verwerken is (dus stacks e.d.), maar hoeveel extra geheugen je kan aanspreken, met wat voor een getallen je kan rekenen etc. Als je puur eenzijdig naar de snelheid van verwerking van de stack kijkt dan is er inderdaad geen voordeel.

Zelfde met IPv6. Dat is ook trager dan IPv4. Echter is het makkelijker te routen, er zijn meer adressen, er hoeft geen NAT meer te worden gebruikt etc. Dát zijn de voordelen van IPv6.

Dus ja, 64bit is op de punten waar jij het vergelijkt langzamer. En dat sommige 64bit processoren toch sneller zijn is alleen maar te wijten aan de extra snelle cache die er hier en daar bijgezet is.

offtopic:
Ik blijf er maar op hameren: je hebt geen code gepost maar een binary

[ Voor 5% gewijzigd door LauPro op 07-05-2007 14:24 ]

[Verwijderd]

Nee, de stack was een bottleneck, maar die zou opgelost moeten zijn...
Afgezien daarvan doet hij veel floating-point berekeningen, die met SSE2 gaan, waar je voordeel zou kunnen hebben van de extra registers.
Ook de fastcall-aanroepmethode die standaard is in 64-bit zou voor wat extra performance kunnen zorgen.

Die andere 64-bit processors zijn ook alleen maar sneller omdat ze voordeel halen uit die nieuwe 64-bit features (en in het geval van de Pentium D niet zo'n beetje ook. Ging van 340 fps naar 385 fps, dat is dus 13%, niet gering). Anders zouden ze even snel of zelfs trager moeten zijn dan 32-bit, niet?
Want ik gebruik geen 64-bit berekeningen, en ook het geheugengebruik komt lang niet in de buurt van de grenzen van 32-bit, dus daar heeft het niets mee te maken.

Maar je vermoedt dus ook dat bij de Athlon de cache hem in de steek laat?

64bit is tov 32bit 2 keer zo langzaam te verwerken, dat is de basis.

Dat is trouwens niet waar. De ALU is gewoon 64-bit, evenals de registers, en kan daarom een 64-bit operatie net zo snel verwerken als een 32-bit of 16-bit operatie.
Alleen bij 64-bit data heb je problemen, omdat je databus niet twee keer zo breed is als in 32-bit mode. Maar in mijn code kwam dat alleen maar voor bij de stack, ik gebruik zelf geen 64-bit datatypen, maar uitsluitend 32-bit en kleiner. Dat kan dus geen invloed hebben.

[ Voor 23% gewijzigd door Verwijderd op 07-05-2007 14:33 ]

[.oisyn]

Verwijderd schreef op maandag 07 mei 2007 @ 14:15:
Het is overigens gecompileerd met Microsoft Visual Studio.NET 2005. Misschien eens andere compilerflags gebruiken? Maar welke?

Heb je al eens "optmize for size" ipv "optimize for speed" geprobeerd? Het is inmiddels al een tijdje zo dat die twee aan elkaar gewaagd zijn, waarbij die eerste het soms (vaak?) wint van die tweede. Bottom line is dat memory idd baggertraag is

Dan nog iets anders, prefetch je wel? Zeker als je werkt met grote datastructuren kan dit echt gigantsich veel schelen qua performance. Jij weet natuurlijk veel beter dan de compiler wanneer je bepaalde data nodig gaat hebben, en dus kun je dat van tevoren al aangeven zodat dat alvast in de cache klaargezet kan worden.

[LauPro]

Het zal een combinatie van cache en die extra features zijn. Maar dat neemt niet weg dat een database die maar 4 GB kan aanspreken voor indices in 32bit langzamer is dan een database die 16GB tot zijn beschikking heeft met 64bit. En dáár komt het echte voordeel van 64bit kijken, niet in stack-aanroepen en een paar custom features her en der.

[Soultaker]

Heb je het nu over x86-64 (aka AMD64 aka EM64T) of IA-64? Ik denk het eerste, maar in dat geval is de instructieset niet zoveel verschillend. Je theorie van het trager decoderen van instructies gaat niet op; daar ligt het echt niet aan.

Verder zijn in mijn ervaring de verschillen in performance tussen IA-32 en x86-64 grotendeels terug te brengen tot deze twee punten:
• x86-64 heeft meer registers, wat vaak efficiëntere code oplevert;
• x86-64 pointers zijn twee keer zo groot, waardoor het geheugengebruik en de vereiste bandbreedte naar de cache en het geheugen groter is.
Het eerste is positief voor x86-64, het tweede negatief (wat performance betreft tenminste; 64-bits addressering heeft nog meer voordelen). Voor een specifieke applicatie kan het snelheidsverschil zowel positief als negatief uitvallen, afhankelijk van wat de code ongeveer doet.

Merk ook op dat niet alles twee keer zo groot is; alleen pointers. Als het echt moet kun je die vaak omzeilen door (32-bit) integers te gebruiken in combinatie met een base pointer. Om te bepalen of dat zinnig is, zul je moeten profilen om de hot spots in je programma te vinden. Post daarna eens wat code van de kritieke onderdelen, dan kunnen we je misschien meer specifiek advies geven.

[Verwijderd]

.oisyn schreef op maandag 07 mei 2007 @ 14:33:
[...]

Heb je al eens "optmize for size" ipv "optimize for speed" geprobeerd? Het is inmiddels al een tijdje zo dat die twee aan elkaar gewaagd zijn, waarbij die eerste het soms (vaak?) wint van die tweede. Bottom line is dat memory idd baggertraag is

Dat kan ik vanavond eens proberen... Volgens mij had ik dat op m'n C2D wel geprobeerd, maar zonder resultaat. Misschien dat het bij de Athlon anders is.

Dan nog iets anders, prefetch je wel? Zeker als je werkt met grote datastructuren kan dit echt gigantsich veel schelen qua performance. Jij weet natuurlijk veel beter dan de compiler wanneer je bepaalde data nodig gaat hebben, en dus kun je dat van tevoren al aangeven zodat dat alvast in de cache klaargezet kan worden.

Ik genereer al m'n data zelf, en ik heb het eens nagerekend, maar in totaal zat het volgens mij nog onder de 1 mb, dus bij een beetje CPU moet dat allemaal wel in de L2-cache passen.
Ik heb ook de code zodanig geordend dat het geheugen zoveel mogelijk lineair doorlopen wordt, alle data netjes gegroepeerd etc.
Ik heb dat destijds allemaal gefinetuned op een Athlon XP nota bene... Je zou denken dat een Athlon64 daar goed mee overweg zou kunnen.
Als ik de indrukwekkende prestaties van de C2D en Pentium D zie, denk ik dat dat allemaal behoorlijk goed zit. Ook valt me op dat het bij overklokken echt 100% lineair schaalt. M'n CPU van 2.4 GHz naar 3.0 GHz klokken geeft me precies 25% extra (~440 fps -> ~550 fps)... Aangezien m'n geheugen niet meeklokt, lijkt mij dat de C2D dus alles via z'n cache kan doen.

[Verwijderd]

LauPro schreef op maandag 07 mei 2007 @ 14:34:
Het zal een combinatie van cache en die extra features zijn. Maar dat neemt niet weg dat een database die maar 4 GB kan aanspreken voor indices in 32bit langzamer is dan een database die 16GB tot zijn beschikking heeft met 64bit. En dáár komt het echte voordeel van 64bit kijken, niet in stack-aanroepen en een paar custom features her en der.

Daar gaat het hier niet om. Het gaat er hier om dat 2 van de 3 x64-processors WEL een behoorlijke snelheidswinst halen na het optimaliseren van de 64-bit versie, en de derde processor niet.
Ik wil graag weten waar dat aan ligt, en of ik daar nog wat aan kan doen.
Met databases en indices heeft dat niks te maken... met bedelen om sourcecode ook niet, trouwens.

[LauPro]

Je legt de focus verkeerd. Het voordeel van 64bit zit hem niet in de zaken die jij nu zoekt. Dat die andere 2 64bit processoren toevallig sneller zijn heeft er meer mee te maken dat die ook bepaalde onderdelen hebben aangepast (bijv. de cache en wat extra fancy instructies).

[Verwijderd]

Soultaker schreef op maandag 07 mei 2007 @ 14:36:
Heb je het nu over x86-64 (aka AMD64 aka EM64T) of IA-64? Ik denk het eerste, maar in dat geval is de instructieset niet zoveel verschillend. Je theorie van het trager decoderen van instructies gaat niet op; daar ligt het echt niet aan.

x86-64 dus, maar da's zo'n mond vol, dus gebruik ik maar x64, net als Microsoft.
Maar de instructies zijn toch wel (vaak) wat groter... mede doordat de extra registers in een extra byte gecodeerd moeten worden. Hoeft misschien geen invloed te hebben, maar het zou kunnen. Ik weet iig uit het verleden met m'n Athlon XP dat AMD niet echt een ster was in het decoderen van wat grotere/complexere instructies.

Merk ook op dat niet alles twee keer zo groot is; alleen pointers. Als het echt moet kun je die vaak omzeilen door (32-bit) integers te gebruiken in combinatie met een base pointer. Om te bepalen of dat zinnig is, zul je moeten profilen om de hot spots in je programma te vinden. Post daarna eens wat code van de kritieke onderdelen, dan kunnen we je misschien meer specifiek advies geven.

Tsja, ik heb geen Athlon64, dus profilen is nogal lastig voor mij.
Ik gebruik verder geen functiepointers in de cruciale delen van het algoritme, dus daar zou het niet aan moeten liggen. Integers zijn gewoon 32-bit of kleiner.

[.oisyn]

Verwijderd schreef op maandag 07 mei 2007 @ 14:42:
Ik genereer al m'n data zelf, en ik heb het eens nagerekend, maar in totaal zat het volgens mij nog onder de 1 mb, dus bij een beetje CPU moet dat allemaal wel in de L2-cache passen.

Zo werkt het helaas niet, doorgaans zijn caches 2 of 4 way set-associative en niet full-associatief. Dat wil zeggen dat als jij 1 mb aan 4 way cache-mem hebt, hij 4 entries heeft voor 256k aan cache, waarbij de associatie slechts wordt gelegd op de onderste 18 bits van het geheugenadres. Zoiets zeg maar:

C++:

int fetch(int address)
{
    int caddr = address & (256*1024 - 1);

    for (int i = 0; i < 4; i++)
        if (cache[caddr][i].addr == address)
            return cache[caddr][i].data;

    return fetch_memory(address);
}

Dit betekent dus dat als je 5 ints hebt waarvan hun adres allemaal eindigen op dezelfde 18 bits (oftewel, ze liggen exact 256k uit elkaar), dat je altijd een cache-mis zal hebben als je ze omstebeurt uitleest.

Pas als je data fysiek 1 mb aan contiguous mem gebruikt dan zou het erin passen, op voorwaarde dat je geen ander geheugen accesst. En daar komt meteen de crux - je hebt natuurlijk nog steeds last van taskswitching van het OS, waardoor ander geheugen ook getouched wordt en daardoor je cache vernaggeld.

Daarom is prefetchen heel belangrijk. Onder MSVC++ kun je daar de _mm_prefetch() intrinsic voor gebruiken.

[Verwijderd]

LauPro schreef op maandag 07 mei 2007 @ 14:51:
Je legt de focus verkeerd. Het voordeel van 64bit zit hem niet in de zaken die jij nu zoekt. Dat die andere 2 64bit processoren toevallig sneller zijn heeft er meer mee te maken dat die ook bepaalde onderdelen hebben aangepast (bijv. de cache en wat extra fancy instructies).

Ik leg de focus niet verkeerd.
Het gaat er mij niet om dat de 64-bit versies per se een stuk sneller zouden moeten zijn... Maar hij is op de Athlon gewoon een behoorlijk stuk trager, en dat is eigenlijk niet acceptabel. Zeker niet aangezien hij op de Intel-processors WEL een flink stuk sneller is.
Overigens draaien alle processors precies dezelfde code, dus 'fancy instructies' zijn niet van toepassing.
En als de cache effect heeft, betekent dat dat de code ook efficienter moet zijn, want de cache is niet anders in 32-bit of 64-bit mode... Alleen als je meer instructies per saldo kunt verwerken kan de cache de snelheid verhogen.
Hou je nou op?

[Verwijderd]

.oisyn schreef op maandag 07 mei 2007 @ 14:54:
[...]

Zo werkt het helaas niet, doorgaans zijn caches 2 of 4 way set-associative en niet full-associatief. Dat wil zeggen dat als jij 1 mb aan 4 way cache-mem hebt, hij 4 entries heeft voor 256k aan cache, waarbij de associatie slechts wordt gelegd op de onderste 18 bits van het geheugenadres. Zoiets zeg maar:

Weet ik.

Pas als je data fysiek 1 mb aan contiguous mem gebruikt dan zou het erin passen, op voorwaarde dat je geen ander geheugen accesst.

Heb ik.

En daar komt meteen de crux - je hebt natuurlijk nog steeds last van taskswitching van het OS, waardoor ander geheugen ook getouched wordt en daardoor je cache vernaggeld.

Ja, niets aan te doen.

[LauPro]

Je doet behoorlijk wat aannames en slaat in mijn ogen de plank mis. Je hebt er blijkbaar geen oren naar verder dus ik zal het hier voorlopig bij laten.

[Verwijderd]

LauPro schreef op maandag 07 mei 2007 @ 15:08:
Je doet behoorlijk wat aannames en slaat in mijn ogen de plank mis. Je hebt er blijkbaar geen oren naar verder dus ik zal het hier voorlopig bij laten.

Nee, ik heb er geen oren naar. Zie je niet dat de bijdragen van bv .oisyn een stuk hulpvaardiger en meer to-the-point zijn dan jouw geleuter-in-de-ruimte over databases etc?
Is dit een database? Gebruik ik hier 4 gb geheugen? Wie slaat de plank dus mis?

[Soultaker]

Verwijderd schreef op maandag 07 mei 2007 @ 14:53:
Maar de instructies zijn toch wel (vaak) wat groter... mede doordat de extra registers in een extra byte gecodeerd moeten worden.

Het is misschien een wat ruwe maatstaf, maar als ik de grootte van de text section in een 32-bit binary met een 64-bit binary vergelijk, dan is de 64-bit binary ~2 procent groter. Lijkt me niet echt schokkend. Kan in een specifiek stukje code natuurlijk net desastreus zijn, maar om daar zonder meer van uit te gaan....

Tsja, ik heb geen Athlon64, dus profilen is nogal lastig voor mij.
Ik gebruik verder geen functiepointers in de cruciale delen van het algoritme, dus daar zou het niet aan moeten liggen. Integers zijn gewoon 32-bit of kleiner.

Als je een standalone test hebt die ik kan compileren of uitvoeren onder Linux wil ik wel even een korte test doen. Je zou trouwens ook gewoon onder IA-32 kunnen profilen en kijken waar de hot spots zitten (welk functies?); dat zal in de x86-64 binary niet veel anders zijn.

(Overigens kun je met tools als Valgrind ook je code simuleren op andere processoren. Maar dat zou ik alleen doen als je een specifiek stukje code hebt dat je wil analyseren, anders is het gewoon teveel gedoe en lastig uit te zoeken wat er precies misgaat.)

Overigens lijkt het mij vrij zinloos om zo veel te filosoferen over de oorsprong van het probleem, zonder te profilen wat er nu mis gaat.

Verwijderd schreef op maandag 07 mei 2007 @ 14:42:
Ik heb dat destijds allemaal gefinetuned op een Athlon XP nota bene... Je zou denken dat een Athlon64 daar goed mee overweg zou kunnen.

Ik ken de interne details van die processors niet, maar ik heb de indruk dat de Athlon64 behoorlijk anders in elkaar steekt dan de Athlon XP. Ik denk niet dat je hoeft te verwachten dat specifieke tuning voor Athlon XP enige winst geeft op de Athlon 64.

[ Voor 14% gewijzigd door Soultaker op 07-05-2007 15:25 ]

[Verwijderd]

Soultaker schreef op maandag 07 mei 2007 @ 15:23:
[...]

Het is misschien een wat ruwe maatstaf, maar als ik de grootte van de text section in een 32-bit binary met een 64-bit binary vergelijk, dan is de 64-bit binary ~2 procent groter. Lijkt me niet echt schokkend. Kan in een specifiek stukje code natuurlijk net desastreus zijn, maar om daar zonder meer van uit te gaan....

Tsja, er hoeft maar 1 byte teveel te zijn, of je hebt al weer 1 cycle extra te pakken. Aangezien je gemiddeld misschien zo'n 2 a 3 instructies per clk verwerkt, hooguit, hakt zo'n extra cycle er best in.

Als je een standalone test hebt die ik kan compileren of uitvoeren onder Linux wil ik wel even een korte test doen.

Helaas, het is allemaal Windows/Direct3D-code.

Je zou trouwens ook gewoon onder IA-32 kunnen profilen en kijken waar de hot spots zitten (welk functies?); dat zal in de x86-64 binary niet veel anders zijn.

Ik heb wel een x86-64 processor, namelijk een Core2 Duo, en daarop heb ik al geprofiled en geoptimaliseerd etc. Daar is het dan ook snel nu.

Overigens lijkt het mij vrij zinloos om zo veel te filosoferen over de oorsprong van het probleem, zonder te profilen wat er nu mis gaat.

Zonder CPU kan ik lastig profilen. Ik ben afhankelijk van anderen.
Ik vraag me alleen af of er uberhaupt wel iets aan te doen is. Misschien is de Athlon64 wel gewoon een te beperkt ontwerp. Ik dacht dat andere programmeurs hier misschien hun ervaringen konden delen.

[Icelus]

Neem aan dat .Net dit al regelt; zijn alle gegevens op 8-bytes uitgelijnd (vooral voor de SSE)?

[Verwijderd]

Ja, daar ligt het allemaal niet aan.
Sowieso zouden alle CPU's daarover struikelen, in zowel 32-bit als 64-bit modus... En dat is niet het geval.

[.oisyn]

Icelus schreef op maandag 07 mei 2007 @ 16:18:
Neem aan dat .Net dit al regelt; zijn alle gegevens op 8-bytes uitgelijnd (vooral voor de SSE)?

SSE data wil je op 16 bytes alignen overigens . MMX/3dnow! is wel 8.
ddbruijn: Wat voor profiler gebruik je nu trouwens? Of time je gewoon je eigen code. Want VTune kan bijvoorbeeld heel gedetailleerde info geven over waar de stalls zitten in je code.

[Verwijderd]

Ik gebruik VTune, maar daar heb ik niks aan. Bij mij loopt het als een zonnetje.
AMD is het probleem, niet Intel. Ik heb geen AMD, en ik vraag me af of VTune iets kan met een Athlon...

[.oisyn]

Oh right. Nee, VTune wil niet eens installeren op een niet-intel bak . AMD heeft CodeAnalyst, maar die is niet zo uitgebreid geloof ik. Maar goed, daar heb je natuurlijk ook weinig aan zonder een AMD proc

[Verwijderd]

Maar afgezien daarvan snap ik het hele fenomeen niet zo.
We zitten toch in AMD z'n instructiesetje te proggen nu?
Verder schelen de C2D en Athlon op zich niet heel veel van elkaar, wat stalls/bottlenecks etc betreft.
In 32-bit ligt de performance van beiden ook niet zo gek ver uit elkaar... Tenminste, niet verder dan wat je verwacht... C2D is gewoon ruim 20% sneller, dat is ie eigenlijk in bijna alle benchmarks. Dus de 32-bit code zal op de Athlon niet slecht lopen.
En het is precies dezelfde sourcecode. Er zitten geen specifieke #ifdef _AMD64 stukjes in, zeg maar...
Dus het enige verschil is wat de Microsoft-compiler ervan brouwt...

[Grijze Vos]

Je kunt eens kijken wat de performance is met andere compilers.

[Verwijderd]

Tsja, volgens mij heb ik alleen de Intel-compiler als alternatief, want voor zover ik weet kun je met gcc geen DirectX-code maken, omdat COM-support niet aanwezig is.
Eerlijk gezegd heb ik niet echt vertrouwen in de Intel-compiler op een Athlon64.

[Soultaker]

Volgens mij is dat onzin. Je hebt geen COM nodig voor DirectX, en volgens mij is er voor COM ook geen specifieke compiler nodig.

[Verwijderd]

Je moet wel de libraries van de DX SDK kunnen gebruiken, en ook de header-files moeten begrijpbaar zijn voor de compiler, anders begin je weinig.
Ik meen mij te herinneren dat gcc de DX SDK om wat voor reden dan ook niet pakte.

Als ik deze thread hier lees, ziet het er niet rooskleurig uit: http://ubuntuforums.org/showthread.php?t=426509

Het kan wel, maar dan moet je je eigen libs en headers brouwen. Daar heb ik geen zin an.

[ Voor 31% gewijzigd door Verwijderd op 07-05-2007 21:03 ]

[Verwijderd]

Ik heb even wat gerommeld met de optimalisatievlaggetjes van VC++:
http://scali.eu.org/~bohemiq/FireOpt.rar

In mijn geval draaien de twee size-optimized varianten waardeloos vergeleken met de andere... Ongeveer 440 fps vs zo'n 220 fps.
Voor de zekerheid maar getest of de mulithtreaded code nog wel werkte, maar met 1 thread werd het nog trager, dus die size-optimized code is echt zo genant op een Core2 Duo.
Ben benieuwd wat een Athlon hier nou weer van maakt.

[Verwijderd]

LauPro schreef op maandag 07 mei 2007 @ 14:22:

offtopic:
Ik blijf er maar op hameren: je hebt geen code gepost maar een binary

Een binary is ook code, namelijk binaire code ofwel machinecode.
Misschien geen sourcecode, maar dat zei ik niet.
Je weet toch hoe ik over sourcecode/opensource denk? Zo niet, dan wil ik dat wel even prive uitleggen.

offtopic:
Ik zag net ook al zo'n moderator die "mb" zo nodig via een modbreak naar "MB" moest veranderen met een flauwe opmerking... tsjongejonge...

[ Voor 16% gewijzigd door Verwijderd op 13-05-2007 12:07 ]

[Soultaker]

Als je hier broncode post betekent het niet dat dat open source is, hoor. Verder heeft LauPro i.m.o. gelijk dat het ontbreken van broncode het lastiger kan maken om in te schatten wat er gebeurt. Ik kan me voorstellen dat mensen geen zin hebben om veel moeite voor jou te doen (door assembly code te ontcijferen) als jij niet bereid bent om de code waar het om gaat te delen. Maar dat is een afweging die ieder voor zich maar moet maken.

Verwijderd schreef op maandag 07 mei 2007 @ 21:00:
Je moet wel de libraries van de DX SDK kunnen gebruiken, en ook de header-files moeten begrijpbaar zijn voor de compiler, anders begin je weinig.
Ik meen mij te herinneren dat gcc de DX SDK om wat voor reden dan ook niet pakte.

Ik gebruikte onder Windows vaak Dev-C++ en daarvoor is wel een kant-en-klare DirectX 9.0c SDK package, die dus werkt met de GCC die Dev-C++ gebruikt. Ik weet niet in hoeverre die getweakt is, maar het kan dus wel.

[Verwijderd]

Soultaker schreef op zondag 13 mei 2007 @ 14:01:
Als je hier broncode post betekent het niet dat dat open source is, hoor. Verder heeft LauPro i.m.o. gelijk dat het ontbreken van broncode het lastiger kan maken om in te schatten wat er gebeurt. Ik kan me voorstellen dat mensen geen zin hebben om veel moeite voor jou te doen (door assembly code te ontcijferen) als jij niet bereid bent om de code waar het om gaat te delen. Maar dat is een afweging die ieder voor zich maar moet maken.

Wie moet er assembly ontcijferen dan?
Dat vraag ik toch van niemand? Ik ben geen beginneling die even aan het handje genomen wil worden om z'n code te optimaliseren.
Ik vraag alleen input van anderen die mogelijk ook tegen bottlenecks aangelopen zijn op Athlons in x64-modus, zodat ik zelf wat gerichter kan zoeken.
Daarom word ik ondertussen een beetje moe van mensen als LauPro die geen flauw benul hebben van dit soort code, en alleen maar bedelen om sourcecode en misplaatste opmerkingen maken omtrent het gebruik van x64 of multithreading.

De code is al bijzonder geoptimaliseerd, dat moge duidelijk zijn. De 32-bit versie loopt ook prima op een Athlon64, ik vroeg me alleen af of er mogelijk iets anders kan zijn dan de cache-bottleneck in de 64-bit versie, iets dat ik misschien *wel* in m'n code zou kunnen oplossen. Maar dan had iemand al gereageerd... het zal dus wel de cache zijn, helaas voor AMD.

Afgezien daarvan zal iedereen met een beetje verstand van MarchingCubes weten dat je aan de code weinig meer ziet dan een paar tabelletjes en wat lookups. Alleen iemand die hands-on ervaring heeft zal weten hoe de code zich in de praktijk ongeveer gedraagt, en waar nou precies de bottlenecks zouden kunnen zitten. Maar die zijn jaren geleden allemaal al weggeoptimaliseerd, dus daar gaat het niet om. Feit dat de cache onder zulke hoge druk komt te staan zou al genoeg bewijs moeten zijn dat deze code poepstrak geoptimaliseerd is.
Maargoed, ik wil de opensource-aanhangers nog wel even verwijzen naar IBM's OpenDX. Daarin is ook een implementatie te vinden. Ik wil best de code voor het Fire-effect wel delen, dan kun je die op de OpenDX-versie laten draaien. Dan moet je eens zien welke er sneller is...

Ik gebruikte onder Windows vaak Dev-C++ en daarvoor is wel een kant-en-klare DirectX 9.0c SDK package, die dus werkt met de GCC die Dev-C++ gebruikt. Ik weet niet in hoeverre die getweakt is, maar het kan dus wel.

Ja, het kan wel... Punt is dat ik al een hele codebase heb, en die ga ik niet even met een druk op de knop compilen met die gcc-meuk.
De Intel-compiler kan dit wel, die is voor een heel groot deel compatible met de Microsoft-compiler. Maar zoiets kan ik voor gcc niet vinden. En het gaat te ver om m'n hele codebase te gaan porten naar gcc. Sowieso twijfel ik niet eens aan de compiler, dus van mij hoeft het niet zo nodig.

[ Voor 15% gewijzigd door Verwijderd op 13-05-2007 15:17 ]

[Soultaker]

Verwijderd schreef op zondag 13 mei 2007 @ 15:13:
Wie moet er assembly ontcijferen dan?
[..]
Ik vraag alleen input van anderen die mogelijk ook tegen bottlenecks aangelopen zijn op Athlons in x64-modus, zodat ik zelf wat gerichter kan zoeken.

Punt is dat er een heleboel redenen kunnen zijn, en om zinnig advies te geven moet toch de bottleneck code zichtbaar zijn. Je poneert hier je conclusie (het ligt aan de cache) en weigert verder specifieke informatie te geven; tja, dan houdt het op. Ik kan je conclusie niet bevestigen of ontkrachten.

Het is aan jou om te bepalen welke informatie je wel en niet geeft, maar ik vraag me wel af waarom je zo'n topic opent als je weinig specifieke informatie wil geven. Beetje flauw om dan LauPro af te zeiken dat hij 'bedelt' om code terwijl jij om advies vraagt. Als je het al zo goed weet en geen advies wil, waarom dan dit topic? Ik vraag me af hoe je verwacht dat mensen je kunnen helpen, behalve door algemene suggesties te doen die je waarschijnlijk al kent?

[rapture]

Werkt je programma voornamelijk met 64bit integers of eerder floatingpoints? 64bit floatingpoints zijn lang geleden in het FPU-gedeelte geïmplementeerd en deze hebben 64bit hun eigen registers, terwijl de rest van je processor op 32bit draait. Met de overstap naar 64bit ga je meer ram kunnen adressen (hier niet van toepassing) en 64bi integers (long) door de processor jagen (ipv vroeger dat men met 32bit registers rare dingen moest doen).

Afhankelijk van omstandigheden ga je niks uit 64bit opzich kunnen halen, dan gaan we naar de processorstructuren kijken.

.oisyn schreef op maandag 07 mei 2007 @ 14:54:
Zo werkt het helaas niet, doorgaans zijn caches 2 of 4 way set-associative en niet full-associatief. Dat wil zeggen dat als jij 1 mb aan 4 way cache-mem hebt, hij 4 entries heeft voor 256k aan cache, waarbij de associatie slechts wordt gelegd op de onderste 18 bits van het geheugenadres. Zoiets zeg maar:

C++:

int fetch(int address)
{
    int caddr = address & (256*1024 - 1);

    for (int i = 0; i < 4; i++)
        if (cache[caddr][i].addr == address)
            return cache[caddr][i].data;

    return fetch_memory(address);
}

Dit betekent dus dat als je 5 ints hebt waarvan hun adres allemaal eindigen op dezelfde 18 bits (oftewel, ze liggen exact 256k uit elkaar), dat je altijd een cache-mis zal hebben als je ze omstebeurt uitleest.

Interessant, zal het combineren met een post van mij.

The Conroe's L2 bus is also fully 256-bit, as opposed to the 128-bit L2 cache of the Athlon 64 FX and X2. The L1 cache has also been increased to 32KB instruction/32KB data caches per core (from 16KB/16KB on the Pentium D), and each has 8-way associativity. The Athlon 64 FX/X2 has larger 64KB/64KB L1 caches but these are only 2-way.
http://www.sharkyextreme....e/cpu/article.php/3620036

Naast het feit dat Core 2 Duo 2x bredere verbinding naar de caches heeft en grotere caches heeft. Kan 2-way of 8-way associativity meespelen. Op Wikipedia kwam ik de volgende grafiek tegen, invloed van cachegrootte en associativity op cache misses in een bepaalde applicatie.

Miss rate versus cache size on the Integer portion of SPEC CPU2000
In deze grafiek zie je dat 2x (AMD) heeft 256KB cache nodig, maar 8x (Intel) heeft slechts 128KB cache nodig. Dit combineren met merkbaar grotere caches en dubbele bandbreedte naar L2 cache zorgt ervoor dat Core 2 Duo heel snel kan draaien zolang het vanuit de caches werkt.

AMD heeft meer geheugenbandbreedte naar de RAM en reallife applicaties hebben dat graag. Je ziet dat 2 benaderingen: Intel kiest voor sneller en meer in de caches te werken, terwijl AMD voor snellere toegang naar de RAM kiest.

Jouw programma zal voornamelijk met floatingpoints werken zodat je weinig aan 64bit hebt, dan moet je het voordeel in processorarchitectuur zoeken. Met je benchmark probeert alles in de cache te stampen om "uberhoge fps" op het scherm te tonen, daarin in Intel sterk (zeker met Core 2 Duo) en AMD delft onderspit in deze benchmark.

Soultaker schreef op zondag 13 mei 2007 @ 16:07:
Punt is dat er een heleboel redenen kunnen zijn, en om zinnig advies te geven moet toch de bottleneck code zichtbaar zijn. Je poneert hier je conclusie (het ligt aan de cache) en weigert verder specifieke informatie te geven; tja, dan houdt het op. Ik kan je conclusie niet bevestigen of ontkrachten.

Het is aan jou om te bepalen welke informatie je wel en niet geeft, maar ik vraag me wel af waarom je zo'n topic opent als je weinig specifieke informatie wil geven. Beetje flauw om dan LauPro af te zeiken dat hij 'bedelt' om code terwijl jij om advies vraagt. Als je het al zo goed weet en geen advies wil, waarom dan dit topic? Ik vraag me af hoe je verwacht dat mensen je kunnen helpen, behalve door algemene suggesties te doen die je waarschijnlijk al kent?

De code laten peer-reviewen blijft altijd nuttig om duidelijk te zien wat je programma met de processor doet zodat we kunnen zien of de cache-aannames wel juist zijn. En mogelijk kunnen we een omzeilmethode verzinnen om het cache-probleem te minimaliseren.

[ Voor 14% gewijzigd door rapture op 13-05-2007 16:10 ]

[Verwijderd]

Soultaker schreef op zondag 13 mei 2007 @ 16:07:
[...]

Punt is dat er een heleboel redenen kunnen zijn, en om zinnig advies te geven moet toch de bottleneck code zichtbaar zijn. Je poneert hier je conclusie (het ligt aan de cache) en weigert verder specifieke informatie te geven; tja, dan houdt het op. Ik kan je conclusie niet bevestigen of ontkrachten.

Weet je waarom jij dat niet kan?
Omdat jij er niets van begrijpt.
Ten eerste vraag ik om ervaringen van mensen met hun eigen x64-code.
Ten tweede weiger ik geen specifieke informatie te geven, ik kan alleen weinig van de sourcecode laten zien, en dat is ook niet nodig voor mensen met verstand van zaken.
Jij kunt geen gerichte vragen stellen, dus kan ik geen specifieke informatie geven.


Ik doe waarschijnlijk qua kennis weinig onder voor anderen hier op het forum, waar het cache etc aangaat, dus voor dat soort triviale dingen hoef ik geen second opinion. Ik wil gewoon algemene ervaringen van x64, en als je gericht over mijn code wilt babbelen, dan toon je eerst maar eens aan dat je verstand van zaken hebt. Dat praat wat makkelijker.
Mijn innerloop is namelijk niet meer dan dit:

code:

    do
    {
        for (i = 0; i < 3; i++)
            GenerateVertex( pMeshInfo, *++edgeList );

        j -= 3;
    } while (j > 0);

Nou, succes ermee.
Wat zit er in edgeList? Tsja, daarvoor moet je het algoritme begrijpen.
Wat doet GenerateVertex? Tsja, daarvoor moet je het algoritme en mijn Direct3D-engine begrijpen.
Kortom, niet echt iets waar je even 5 seconden naar kijkt, en een antwoord voor klaar hebt.

Het is aan jou om te bepalen welke informatie je wel en niet geeft, maar ik vraag me wel af waarom je zo'n topic opent als je weinig specifieke informatie wil geven. Beetje flauw om dan LauPro af te zeiken dat hij 'bedelt' om code terwijl jij om advies vraagt. Als je het al zo goed weet en geen advies wil, waarom dan dit topic? Ik vraag me af hoe je verwacht dat mensen je kunnen helpen, behalve door algemene suggesties te doen die je waarschijnlijk al kent?

Hoe moeilijk is het te begrijpen dat er enorm veel over processors en algoritmen gediscussieerd kan worden zonder daadwerkelijk specifieke code voor je neus te hebben?
Hoe moeilijk is het ook om te begrijpen dat niet alle algoritmen dermate triviaal zijn dat je erover mee kunt praten zonder er zelf ooit mee gestoeid te hebben?
Ik heb al veel te vaak van die zelfbenoemde 'experts' meegemaakt, die pas begrepen dat bv een Boyer-Moore algoritme sneller is dan hun met de hand in assembly geoptimaliseerde bytescanner nadat je ze met een executable om de oren sloeg. De code en uitleg van het algoritme snapten ze gewoon niet.
Die mensen moeten zich er dan ook niet mee bemoeien.
Daarentegen snapten anderen meteen bij de uitleg al dat Boyer-Moore wel efficienter moet zijn, en dat de implementatie op instructieniveau niet echt relevant is.

Mijn ervaring is dus dat er twee groepen programmeurs zijn:
1) De 'opensource'-hoek... "Geef mij de sourcecode, dan snap ik het wel"... niet dus.
2) Mensen die er kaas van gegeten hebben, en nuttige dingen kunnen zeggen, met of zonder sourcecode.

Sourcecode heeft hier ook weinig mee te maken... Waarom doet ie het in 32-bit op alle CPUs goed, en in 64-bit op 2 van de 3?
Zou toch wel heel toevallig zijn dan dat er in de sourcecode iets fundamenteel fout zit dat je er even na 1 of 2 keer lezen uit zou pikken? Bovendien hebben er door de jaren al genoeg slimme programmeurs naar gekeken, dus waren dat soort foutjes en inefficienties er al uitgepikt.

[Verwijderd]

rapture schreef op zondag 13 mei 2007 @ 16:07:
Werkt je programma voornamelijk met 64bit integers of eerder floatingpoints?

Hij werkt helemaal niet met 64-bit integers. En de floating-point die gebruikt wordt, is uitsluitend single-precision (want extra precisie is niet nodig, en dit is dus het meest compact voor de cache).
Het grootste gedeelte doet ie lookups in tabellen van bytes.
Berekeningen zijn er nauwelijks. Wat adds, wat ors, en verder dus de floating-point berekeningen, die zoals je al aangeeft, onafhankelijk zijn van 32 of 64-bit mode.
Voor het grootste gedeelte is het tabel-index samenvoegen, en dan via die tabel-lookups de juiste data kopieren, met hier en daar een eenvoudig berekeningetje... maar gezien de cache/geheugenlatency zijn die berekeningen zo goed als 'gratis'.

Afhankelijk van omstandigheden ga je niks uit 64bit opzich kunnen halen, dan gaan we naar de processorstructuren kijken.

Wel een klein beetje, op instructieniveau. Omdat je meer registers hebt, gaat de compiler standaard fastcall gebruiken. Dat levert bij mij een klein beetje voordeel op. Ook zal hier en daar het spillen van registers op de stack verminderd worden. Het scheelt niet veel, maar in principe zou het er sneller op moeten worden, niet trager... En de Core2 en Pentium 4 worden dat ook.

Jouw programma zal voornamelijk met floatingpoints werken zodat je weinig aan 64bit hebt, dan moet je het voordeel in processorarchitectuur zoeken. Met je benchmark probeert alles in de cache te stampen om "uberhoge fps" op het scherm te tonen, daarin in Intel sterk (zeker met Core 2 Duo) en AMD delft onderspit in deze benchmark.

Ja, dat lijkt mij het geval... dan lijkt mij dat de Athlon gewoon wat tekortkomt aan cache om de 64-bit mode tot het maximum uit te buiten.

De code laten peer-reviewen blijft altijd nuttig om duidelijk te zien wat je programma met de processor doet zodat we kunnen zien of de cache-aannames wel juist zijn. En mogelijk kunnen we een omzeilmethode verzinnen om het cache-probleem te minimaliseren.

Natuurlijk, maar dat is al lang en breed gedaan door mensen die ook daadwerkelijk verstand hebben van dit soort algoritmen en grafische frameworks.
Er kan gewoon niet meer in de caches gepropt worden. De code staat zo strak als het maar kan.
Ik had alleen gedacht dat er misschien nog wat ongedocumenteerde problemen met de Athlon zouden kunnen zijn... dingen die in 64-bit stalls zouden kunnen geven, waar ik op zou moeten letten... Maar daar heb ik nog niemand over gehoord, dus dat zal dan wel niet.

[ Voor 4% gewijzigd door Verwijderd op 13-05-2007 16:47 ]

[Soultaker]

Verwijderd schreef op zondag 13 mei 2007 @ 16:29:
Weet je waarom jij dat niet kan?
Omdat jij er niets van begrijpt.

Als jij het zo goed weet, waarom heb je het dan nog niet opgelost?

Ten tweede weiger ik geen specifieke informatie te geven, ik kan alleen weinig van de sourcecode laten zien, en dat is ook niet nodig voor mensen met verstand van zaken.
Jij kunt geen gerichte vragen stellen, dus kan ik geen specifieke informatie geven.

Onzin. Jij kan je probleem zelfs mét broncode niet oplossen. Je hebt bovendien niet genoeg informatie over je algoritme gegeven om er over te redeneren zonder de exacte broncode te kennen.

Nou, succes ermee.
Wat zit er in edgeList? Tsja, daarvoor moet je het algoritme begrijpen.
Wat doet GenerateVertex? Tsja, daarvoor moet je het algoritme en mijn Direct3D-engine begrijpen.

Exact: hoe jij deze dingen hebt geïmplementeerd is uitermate relevant om de kern van de problemen te achterhalen. Daarom is het logisch dat men daar om vraagt. Je doet nu alsof de broncode niet relevant is, door het irrelevante deel van de broncode te posten.

Kortom, niet echt iets waar je even 5 seconden naar kijkt, en een antwoord voor klaar hebt.

Dat verwacht ook niemand?

Hoe moeilijk is het te begrijpen dat er enorm veel over processors en algoritmen gediscussieerd kan worden zonder daadwerkelijk specifieke code voor je neus te hebben?

Dat begrijp ik prima. Sterker nog, daar heb ik meer ervaring mee dan optimalisatie voor specifieke processoren. Dat neemt niet weg dat om de performance op een specifieke processor te begrijpen, je naar een specifieke implementatie moet kijken, en zien hoe het daar werkt met dingen als registerallocatie, grootte van stackframes, cache resident memory, etcetera.

Hoe moeilijk is het ook om te begrijpen dat niet alle algoritmen dermate triviaal zijn dat je erover mee kunt praten zonder er zelf ooit mee gestoeid te hebben?
Ik heb al veel te vaak van die zelfbenoemde 'experts' meegemaakt, die pas begrepen dat bv een Boyer-Moore algoritme sneller is dan hun met de hand in assembly geoptimaliseerde bytescanner nadat je ze met een executable om de oren sloeg. De code en uitleg van het algoritme snapten ze gewoon niet.

Dus daarom post je alleen de executable, zodat mensen die wel verstand hebben van algoritmen niets zinnigs kunnen zeggen? Huh?!

Ik ken bijvoorbeeld wel een marching cubes algoritme, maar dat is iteratief. Het is ook een algoritme waarop nogal wat variaties mogelijk zijn. Om te begrijpen waarom jouw (naar eigen zeggen) recursieve algoritme slecht performt is het relevant te weten hoe het precies werkt. Waar je vandaan haalt dat ik (of anderen) me niet in het algoritme willen verdiepen is me een raadsel; dat wil ik juist graag, maar daar is op deze manier niets zinnigs over te zeggen.

Daarentegen snapten anderen meteen bij de uitleg al dat Boyer-Moore wel efficienter moet zijn, en dat de implementatie op instructieniveau niet echt relevant is.

Voor sommige algoritmen maakt de implementatie wel ontzettend veel uit. Denk bijvoorbeeld aan allerlei augmenting-flow-algoritmes.

Mijn ervaring is dus dat er twee groepen programmeurs zijn:
1) De 'opensource'-hoek... "Geef mij de sourcecode, dan snap ik het wel"... niet dus.
2) Mensen die er kaas van gegeten hebben, en nuttige dingen kunnen zeggen, met of zonder sourcecode.

Dit is zo'n domme dichotomie dat ik er maar niet eens op in ga.

Sourcecode heeft hier ook weinig mee te maken... Waarom doet ie het in 32-bit op alle CPUs goed, en in 64-bit op 2 van de 3?
[..]
Zou toch wel heel toevallig zijn dan dat er in de sourcecode iets fundamenteel fout zit dat je er even na 1 of 2 keer lezen uit zou pikken? Bovendien hebben er door de jaren al genoeg slimme programmeurs naar gekeken, dus waren dat soort foutjes en inefficienties er al uitgepikt.

Kortom: je wil je code verbeteren, terwijl je zeker weet dat je code al 100% foutloos is. Dan nogmaals de vraag: wat is dan het doel van dit topic? Als je je code denkt te kunnen verbeteren zul je toch moeten accepteren dat die niet perfect is.

[Verwijderd]

Ik ga verder niet in op je rant... het topic lijkt me duidelijk: Wie is er al tegen performance-problemen in x64 modus op Athlon64 aangelopen? Zoals de titel al aangeeft.

PS: Als je geen recursieve MarchingCubes kent... zoek dan eens op Surface Walking (als daar al resources over zijn op het net).
Misschien vind je zelfs sourcecode!
*zucht*

[Verwijderd]

Of een andere vraag:
Wie weet waarom mijn nieuwe 64-bit executables niet meer op alle Windows x64-machines draaien?
De oude heb ik al maanden geleden gecompileerd, en ik weet niet meer hoe ik destijds de project-settings had staan, zodat het werkte...
Zou iets met embedded manifest kunnen zijn ofzo...

Maargoed, toen had ik er een 'kale' Windows XP x64-machine naast, nu heb ik alleen m'n eigen dev-bak, en daarop werkt natuurlijk altijd alles, want alles is geinstalleerd.
Testen gaat dus nu niet meer, helaas.

[ Voor 3% gewijzigd door Verwijderd op 15-05-2007 10:43 ]

[Zr40]

Wat is het uiteindelijke doel van je applicatie? Ik neem aan dat je meer wil doen dan slechts een microbenchmark. Juist optimalisaties die nuttig lijken in (micro)benchmarks kunnen averechts werken wanneer je ook andere dingen wil doen.

Hoe belangrijk zijn die paar kloktikken? Heb je zo'n krappe loop dat dat een significant verschil oplevert? Ik voorspel dat wanneer je applicatie af is, de optimalisatie waar je je nu mee bezig houdt nauwelijks winst opgeleverd heeft. Natuurlijk is het algoritme sneller, maar heeft dat nou zo'n grote invloed op het geheel?

[Verwijderd]

Dit *is* de applicatie... behalve dan dat ik nu met een random-functie een vuur-effectje simuleer ipv data uit een MRI-scanner of wat dan ook visualiseer.
Maar het gaat om het realtime visualiseren van 3d-volumedata.

Belangrijk is het niet echt, eerlijk gezegd boeien die Athlons me niet zo, Core2 is toch sneller, en daar heb je alleen maar winst in x64-modus. Maar misschien had iemand iets toe te voegen wat ik dan weer mee kan nemen in een volgende versie.
Het gaat ook niet om optimalisaties, maar om het vermijden van een mogelijk probleem specifiek aan de Athlon-architectuur. Maar aangezien het toch wel redelijk vaststaat dat het een gebrek aan cache-bandbreedte is, valt het probleem niet met aanpassingen aan de software op te lossen.

[Zr40]

Juist een voordeel van de Athlons is de ingebakken geheugencontroller. Als je zoveel data hebt zodat het toch niet in de cache past, heeft de Athlon 64 hierdoor voordeel boven de Core 2. Let wel, dit heb ik niet zelf getest.

[Verwijderd]

Geheugen is natuurlijk een stuk trager dan cache. Een snelle geheugencontroller is dus geen goed alternatief voor een te kleine/trage/inefficiente cache (afgezien daarvan vind ik die geheugencontroller dus bij de Athlon geen voordeel, omdat de extra bandbreedte niet gebruikt kan worden door de CPU, en de latency bij de Core2 al door de intelligente cache prefetching is weggepoetst).
Maar dat is hier niet het probleem, denk ik.
Als ik de testresultaten van de 2x1mb Athlons zie, dan zou alles daar wel in de cache moeten zitten. In 32-bit modus komen ze ook redelijk mee met de Core2... maar in 64-bit modus worden ze wat trager, waar de Core2 en Pentium D sneller worden.
Het scheelt niet veel, maar toch is het jammer.

[ Voor 19% gewijzigd door Verwijderd op 16-05-2007 00:40 ]

[Zr40]

Toch is dat vreemd. Juist berekeningsintensieve toepassingen hebben voordeel aan de extra registers. Doordat er meer in de registers past, hoeft het trage geheugen minder gebruikt te worden als 'kladblok'. Bedenk dat zelfs wanneer alles in de cache past, schrijfacties nog steeds naar het geheugen gaan.

[Verwijderd]

Dat weet ik allemaal wel, maar dat is het punt niet (over die registers ben ik het trouwens niet helemaal eens. Vaak worden die alleen naar de stack gezet, en die zit per definitie in de cache... wordt waarschijnlijk al weer overschreven voordat de stack uberhaupt van cache naar geheugen geschreven zou worden. Stack zal dus in veel gevallen voornamelijk L1-cache zijn, en wordt te vaak herschreven om in L2-cache of geheugen te komen, in het geval dat registers binnen een loop tijdelijk opgeslagen moeten worden).
Zoals je zelf aangeeft, de Athlon zou een voordeel moeten hebben met z'n geintegreerde controller.

In principe zouden beide CPUs evenveel naar het geheugen moeten schrijven, behalve dan misschien in het geval dat een schrijfopdracht al overschreven wordt voordat deze naar het geheugen ging.
Maar omdat ik alle data eerst schrijf voordat ik het uitlees, zou het altijd al in de cache moeten staan (ervanuitgaande dat het past, maar met 1 mb moet dat lukken), en maakt het niet zo veel uit of het al naar geheugen geschreven is of niet, het hoeft namelijk niet uit het geheugen teruggelezen te worden, want het is al gecached. Het geheugen hangt er dus eigenlijk maar een beetje bij, en wordt alleen af en toe gebruikt als er van proces gewisseld wordt, en er dus andere data in de cache komt. Maar dat verklaart niet waarom het in 64-bit trager zou zijn dan in 32-bit, want dat zou in dit geval geen verschil maken. En het verklaart ook niet waarom de Athlon er trager van wordt, en de Pentium D en Core2 Duo sneller worden.

De juiste verklaring moet iets zijn dat in de Intel-architecturen verschilt van de Athlon (de code is immers identiek, en ook het gebruikte OS is hetzelfde), en dan dus niet ten voordele van de Athlon, zoals de geheugencontroller.

[Knorrend_varken]

Verwijderd schreef op dinsdag 15 mei 2007 @ 10:42:
Of een andere vraag:
Wie weet waarom mijn nieuwe 64-bit executables niet meer op alle Windows x64-machines draaien?
De oude heb ik al maanden geleden gecompileerd, en ik weet niet meer hoe ik destijds de project-settings had staan, zodat het werkte...
Zou iets met embedded manifest kunnen zijn ofzo...

Maargoed, toen had ik er een 'kale' Windows XP x64-machine naast, nu heb ik alleen m'n eigen dev-bak, en daarop werkt natuurlijk altijd alles, want alles is geinstalleerd.
Testen gaat dus nu niet meer, helaas.

Je hebt toevalig niet Visual studio 2005 SP1 geinstalleerd en hebben die nieuwe x64 instalaties niet de nieuwe redistributables?

[Verwijderd]

Ja, dat moet het haast wel zijn.
Alvast bedankt.

[H!GHGuY]

Voor errata met AMD processoren kun je op hun site terecht.
Ik meen me te herinneren dat ik ooit eens zo'n documentje zat te lezen.

http://www.amd.com/gb-uk/...,,30_182_739_7203,00.html

Hier staat bvb heel wat toffe info waaronder:
- Software optimization guide for AMD64
- Errata: http://www.amd.com/us-en/...s_and_tech_docs/25759.pdf
- etc

Is het een mogelijkheid om je programma te strippen zodat ie bvb nog maar de helft van het geheugen gebruikt?
Is het een mogelijkheid (BIOS?) om de L2 cache uit te schakelen ?

[ Voor 18% gewijzigd door H!GHGuY op 16-05-2007 20:18 ]

[Verwijderd]

H!GHGuY schreef op woensdag 16 mei 2007 @ 20:17:
- Software optimization guide for AMD64

Deze heb ik uiteraard van voor tot achter doorgelezen... Punt is dat er nergens specifiek op 32-bit of 64-bit ingegaan wordt, dus ik neem maar aan dat alles wat daar staat algemeen geldt, en dat er in principe geen extra voor- of nadelen aan 64-bit mode zitten... voor zover AMD dat documenteert dan.
Agner Fog heeft ook wel wat info over de Athlon64 en z'n bottlenecks: http://www.agner.org/optimize/microarchitecture.pdf
Maar ook daar eigenlijk niets specifiek voor 64-bit... Instructielengte en cache zijn de enige dingen die me van toepassing lijken.

Is het een mogelijkheid om je programma te strippen zodat ie bvb nog maar de helft van het geheugen gebruikt?

Dat zou kunnen... Ik kan gewoon de resolutie verlagen (of verhogen), en kijken wat ie dan doet.
Maar voorlopig ben ik benieuwd of men de nieuwe exe's met andere compiler-opties kan draaien.
Als dat niet lukt, heeft het weinig zin om nog meer niet-bruikbare exe's de wereld in te slingeren.

[ Voor 12% gewijzigd door Verwijderd op 16-05-2007 20:46 ]