Mijn voorlopige bevindingen over multicore-processing

[Anoniem: 133470]

Wat ik bedoelde op tweakers is overigens een minibench zonder GFX impact... dus win32 console (ofzo)

Maar de graphics hebben ook weinig tot geen impact. Een E6600 scoort met een 7600GT ongeveer net zo goed (soms zelfs beter) als met een 8800 GTX, terwijl die 8800 toch echt vele malen sneller is.
De invloed is dus verwaarloosbaar.

En eigenlijk denk ik dat toch meer tweakers Linux AMD-64 hebben draaien dan WinXP-64.

Tsja, dat denk ik niet... Ik heb wel eens polls gezien op tweakers.net, over OS-gebruik... er waren maar een paar % linux-gebruikers. Zelfs al zouden die allemaal 64-bit gebruiken, dan nog is de kans groot dat er meer 64-bit Windows-gebruikers zijn.

Vandaar de keuze/verzoek voor een test op linux platform (en hint naar source.. misschien niet de volledige implementatie maar jou implementatie van algoritme (of aangepaste versie) is leuk, en wie weet wat voor leven het gaat leiden ... misschien nog optimalisaties waar je zelf (nog) niet opgekomen was... who knows???

Zie ik niet zo zitten. Ten eerste omdat het bij linux veel lastiger is om binaries te maken die op alle versies lopen, zeker met 64-bit... ten tweede omdat het zo mogelijk nog lastiger is om ook de 32-bit versies op 64-bit te laten lopen etc... dus vergelijken tussen 32-bit en 64-bit wordt helemaal lastig.
Ten derde omdat ik geen Intel-compiler voor linux heb, en die ook niet wil gaan kopen, dus dan ben ik overgeleverd aan gcc, waarvan ik uit ervaring al weet dat die een stuk trager is met dit soort code, dus zegt een benchmark dan misschien meer over de compiler dan over de CPU.
En als laatste omdat ik zelf geen linux heb geinstalleerd, en ook geen zin heb om dat te gaan installeren en m'n code te gaan herschrijven voor linux.

[MexxT]

InfinityG35 schreef op dinsdag 19 december 2006 @ 20:06:
Even mijn oude bakkie laten zweten: (bijna 4 jaar oude techniek )

Pentium 4 2.8B 'Northwood' 533 Fsb /512kb non HT @ 3150
1536Mb PC2700 @ 2.5-7-3-3
ATi Radeon X800XT

Oude Fire.32: 92.2 Fps
Niewe Fire.32: 114 Fps (min 107 max 134)

Oude Fire Multithread1: 90 Fps
Oude Fire Multithread2: 85 Fps

Nieuwe Fire32.x87 1Thread: 113 Fps (min 105 max 127)
Fire32.x87 2Thread: 92 Fps (min 89 max 101)
Fire32.x87 10Thread: 48Fps (min 47 max 52)
Fire32.x87 20Thread: 30Fps (min 28 max 32)
Fire32.x87 50Thread: 15Fps (min 14 max 16)
Fire32.x87 100Thread: CRASH

Dus pas bij 20 Threads wordt het onspeelbaar voor mijn singlecore

ik heb het even met de nieuwe generatie P4 3,2 540 1MB getest (wel @ 3,91)

die doet 103Threads en dan 17FPS (min 5 max 17)
104 is Crash

bij deze singlecore word het bij 55Threads pas onspeelbaar.

(dit is wel getest met iTunes spelend pratende/muziekverzendende dus virusscannende mensen @ msn en IE + Limewire aan )

[Anoniem: 133470]

Waarschijnlijk crasht ie bij een gegeven aantal threads omdat iedere thread een stukje videogeheugen gebruikt.
Op een gegeven moment is dat op, natuurlijk.
Er zit verder geen check op, omdat het toch niet de bedoeling is om honderden threads te gaan draaien, en als je niet genoeg videogeheugen hebt, valt er verder toch weinig anders te doen dan de applicatie af te breken, en opnieuw te beginnen met minder theads.

[Anoniem: 133470]

Nou, die 4x4 of dual Opteron-mensen laten wel op zich wachten
En ook 64-bit resultaten op AMD-processors trouwens.
Daar zit ik ook heel erg op te wachten, want ik weet nog steeds niet of Athlons sneller zijn in 64-bit, en zo ja, hoeveel.

[ Voor 58% gewijzigd door Anoniem: 133470 op 14-01-2007 16:40 ]

[Dark]

Opteron 170 DC overclocked 9x334Mhz

fire 191fps / 50% cpu, http://img401.imageshack.us/img401/3937/firejl8.jpg
firem 210fps / 80% cpu, http://img401.imageshack.us/img401/8040/firemyi3.jpg
firem2 304fps / 85% cpu, http://img119.imageshack.us/img119/9586/firem2bg7.jpg
firenew(2) 405fps / 85% cpu, http://img99.imageshack.us/img99/7734/firenew2jk5.jpg

edit:
vergat x87...

firex87 408fps / 90% cpu, http://img186.imageshack.us/img186/2716/firex87wi7.jpg

[ Voor 13% gewijzigd door Dark op 15-01-2007 01:34 ]

[begintmeta]

Anoniem: 133470 schreef op woensdag 20 december 2006 @ 19:49:
...
Ten derde omdat ik geen Intel-compiler voor linux heb, en die ook niet wil gaan kopen
...

Je andere bezwaren blijven natuurlijk staan, maar aan dit derde is misschien wel wat te doen. Je schrijft dat dit alles in het kader van een hobbyproject is, dus mogelijk kom je in aanmerking voor een niet-commerciele licentie.

[Anoniem: 146043]

mad_max234 schreef op maandag 06 november 2006 @ 17:16:
Oke nu snap ik het, wat beter door nog maar eens te lezen. dacht dat je de cpu's aan het vergelijken was. Maar je ben een speciaal stukje software aan het bench, ik ga straks ook de rest ff testen zou het ff posten misschien wel intresant voor je vergelijking.

Edit/

Zou je misschien een tabel kunnen posten met de data van je testen, kunnen we wat beter vergelijken met onze score. bvb

Je snapt het nu omdat je nu de openingspost hebt gelezen?

Ik vind het een prima verhaal, goed te volgen en vooral de uitkomst van de werking van de shared L1 cache. Natuurlijk maakt dat verschil. Zo gaat het demuxen veel sneller en werken de 2 cores dus onafhankelijk vanelkaar. Elke core moet beschikken over een eigen rowbed in de L1 ingang omdat samenwerken anders niet gaat.


Even van de wetenschap afstappen en kijken wat dat voor economische consequenties heeft:

Ik heb zelf een singlecore AMD64 3800+ en ik werk heel veel met andermans computer voor onderhoud en dergelijke. Als ik muziek afspeel en ik geef de computer een zware taak dan hapert het geluid wel eens. Kwestie van singlecore. Het eerste wat me opvalt zijn 3 treden:

1e trede: Arme mensen, traag systeem. Het grote meerendeel zit ver onder mijn systeem en ik vraag me af of deze groep voorlopig wel de dual core zal proeven? Hier hoeven de ontwerpers weinig winst te verwachten omdat bij deze mensen weinig valt te winnen. Het zijn er meer dan je lief is.

2e trede: Mensen zoals ik. Geen modaal inkomen, maar wel geld genoeg verdienen om er een netjes systeem op na te houden. Ik kom goed rond en ik sta zelden tot nooit rood, maar een vette dualcore kopen zal ik niet doen. Er moeten keuzes gemaakt worden en ik heb ook nog een woning te onderhouden en 2 fietsen die in goede staat moeten zijn en blijven.

3e trede: Modaal of hoger of mensen die nog bij hun ouders wonen en geld als water binnenbrengen. Zij hebben het nieuwste van het nieuwste. Zij zullen jouw verhaal beamen en zo'n CPU overwegen. Aangezien dit 'nu nog' een kleinere groep is zal de economie hier niet zoveel winst op boeken als ze gehoopt hadden. Echter verwacht ik wel dat deze groep nog zal groeien zodat het voor de economie alsnog aantrekkelijk begint te worden.

Je kunt dus wel een prachtige benchmark uitvoeren, maar als 80% zo'n CPU niet kan kopen wat heeft het dan voor zin? Dat is waar de computermarkt zich een beetje zorgen over maakt. Jouw verhaal zal dus heel afhankelijk zijn van hoe 'slecht' de economie regeert.

[Anoniem: 133470]

Tsja, eigenlijk interesseert de economische kant van het verhaal me niet zo.
Ik probeer vooral te kijken wat er mogelijk is met de huidige stand van technologie. Dat niet iedereen dat kan betalen, daar kan ik niks aan veranderen. Zo is het altijd al geweest, en zo zal het voorlopig nog wel blijven.

Maar aan de andere kant denk ik dat je verhaal wat overdreven is. Vooral Intel heeft al een tijdje bijzonder goedkope dualcore processors in de aanbieding, zoals de Pentium D 805.
Ik denk ook dat het niet al te lang meer duurt totdat zelfs de meest simpele low-budgetprocessors dualcore zijn, en dus iedereen die een nieuwe PC koopt, automatisch dualcore heeft.
Dan is het ook voor Jan Modaal bereikbaar.
En ook tweedehandssystemen/afdankertjes zijn al steeds vaker dualcore.
Ik denk dat de meeste dualcore processors nu al minder kosten dan wat jij destijds voor je 3800+ hebt betaald.

edit:

Ik vind het een prima verhaal, goed te volgen en vooral de uitkomst van de werking van de shared L1 cache. Natuurlijk maakt dat verschil. Zo gaat het demuxen veel sneller en werken de 2 cores dus onafhankelijk vanelkaar. Elke core moet beschikken over een eigen rowbed in de L1 ingang omdat samenwerken anders niet gaat

Je bedoelt hier L2 neem ik aan? L1 is niet geshared, en het zou waarschijnlijk ook niet slim zijn om dat te doen, omdat je dan meer overhead krijgt bij iedere toegang, om te zorgen dat de cores elkaar niet in de weg zitten. Op de L2-cache heb je nu een paar cycles extra latency, maar daar is het niet zo erg, omdat de latency toch al relatief hoog is. Op L1 wil je zo min mogelijk latency... hooguit 2 a 3 cycles.

[ Voor 35% gewijzigd door Anoniem: 133470 op 15-01-2007 12:58 ]

[The Source]

http://www.intelcapabilitiesforum.net/ISF_demo?s=a
Ice Storm Fighters Game Technology Demo

Demo om Intel dual en quad core gaming te demonstreren.

[Servor]

Ik heb sinds een paar dagen ook een dual core systeem staan (E6600 op een Bad Axe 2 met 2 GB aan PC6400 geheugen) en ik moet zeggen dat ik echt zwaar onder de indruk ben. Ik kom van een P4 3 Ghz (P4C800-E, 2GB RAM) en had deze sprong in performance niet helemaal verwacht moet ik eerlijk zeggen. Verwacht echter niet de sprong bij het internetten, het mailen of andere 'simpele' zaken. Nee, ik zat gisteren (onder Vista Ultimate) een MPEG file van 14 GB te recoden naar DVD, een 24 aflevering te kijken, er draaide een virtuele XP met 512 MB geheugen, ik had IE7, mail, msn openstaan en m'n PC gaf gewoon geen krimp. Alles voelde nog zó soepel aan, alsof er niks aan de hand was. Zo heb ik dat nog nooit meegemaakt.

Nee, ik kan niet anders dan concluderen dat Intel (en wellicht MS met Vista) een zeer puik stukje techniek heeft afgeleverd voor een zeer betaalbare prijs met de Core 2 Duo cpu's.

[Anoniem: 133470]

Excuseer mij dat ik dit wat oudere topic weer omhoog schop, maar gezien de recente prijsdalingen van de Core2 Q6600 vermoed ik dat er intussen al aardig wat tweakers zijn met een quadcore in huis.

Ik hoop daar dus wat benchmarks van op te vangen. Mensen met systemen met meerdere processors, zowel Xeons als Opterons, zijn ook nog steeds welkom.

Bij voorbaat dank.

Edit: Oh, ik herinner me net dat ik ook nog steeds geen resultaten van Athlons of Opterons in 64-bit heb gezien. Daar ben ik ook nog steeds benieuwd naar.
Het zou best wel eens kunnen dat de Athlon in 64-bit een stuk dichter bij de Core2 kan komen, net zoals de Pentium D dat blijkbaar doet.

[ Voor 28% gewijzigd door Anoniem: 133470 op 01-05-2007 21:22 ]

[Anoniem: 8819]

Anoniem: 133470 schreef op dinsdag 01 mei 2007 @ 20:38:
Excuseer mij dat ik dit wat oudere topic weer omhoog schop, maar gezien de recente prijsdalingen van de Core2 Q6600 vermoed ik dat er intussen al aardig wat tweakers zijn met een quadcore in huis.

Ik hoop daar dus wat benchmarks van op te vangen. Mensen met systemen met meerdere processors, zowel Xeons als Opterons, zijn ook nog steeds welkom.

Bij voorbaat dank.

Zal binnen kort wanneer ik de intel 930d binnen heb die boven de 4g draait.
Hier neer zetten wat hij doet.\
Ik vraag me namelijk af of deze cpu die ik voor 50euro gekocht veel verschil is met een e4000serie

[Anoniem: 133470]

De Pentium D 950 van m'n broer gaf wel aan dat de Pentium een stuk meer voordeel haalt uit de 64-bit versie dan de Core2 Duo.
Misschien dat je in 64-bit met zo'n 930 op 4 GHz zo'n E4x00 wel het nakijken kunt geven.
In 32-bit denk ik dat de C2D toch sneller zal zijn in veel gevallen.

[Anoniem: 95522]

ik heb hier een DC opteron 165 @ 2,250GHz @ 250FSB (1000HT) / GF 7900GTX èn 64bit Windows XP (met SP2 en laatste hotfixes)

ik zal wel even de testjes runnen
houdt mijn post in de gaten dan krijgen jullie allen mijn results

de results, alles @ default, drivers ook @ stock, op de achtergrond ie7+3tabs en 1 msn chat:

Fire.exe: ~170fps
Fire-Multithread.exe: ~180fps
Fire-Multithread2.exe: ~240fps
Fire32.exe: min: ~239fps avg: ~315fps max: ~322fps
Fire32-x87.exe: min: ~242fps avg: ~310fps max: ~349fps
Fire64.exe: min: ~288fps avg: ~300fps max: ~343fps

mijn conclusie is dus dat de 64bits fire dus trager is, misschien een verkeerd geconfigureerd algoritme of een algoritme dat niet in 64bit te gebruiken is vanwege een te hoge overhead?
maar dat hij een hogere min. fps haalt is misschien veel interessanter als een hoge max of avg.

als er nog andere testjes zijn die gedraait moeten worden hoor ik het graag

[ Voor 77% gewijzigd door Anoniem: 95522 op 05-05-2007 12:21 ]

[Anoniem: 133470]

Anoniem: 95522 schreef op zaterdag 05 mei 2007 @ 11:47:mijn conclusie is dus dat de 64bits fire dus trager is, misschien een verkeerd geconfigureerd algoritme of een algoritme dat niet in 64bit te gebruiken is vanwege een te hoge overhead?
maar dat hij een hogere min. fps haalt is misschien veel interessanter als een hoge max of avg.

Ah, eindelijk iemand die AMD-resultaten in 64-bit durft te posten. Ik heb er maanden op moeten wachten. Mijn vermoeden was dan ook juist, bij AMD draait de 64-bit versie trager...

Waarom dat is, weet ik niet. Bij Pentium D is de 64-bit aanzienlijk sneller, en ook de C2D sleept een aantal procenten meer snelheid eruit.
Aan het algoritme op zich ligt het dus niet. Het kan op de juiste architectuur wel degelijk een stuk sneller zijn dan de 32-bit versie.
De vraag is dus specifiek waarom het op de Pentium D en C2D-architectuur wel lukt, en op de Athlon/Opteron niet.

Ik kan wel een aantal hypotheses bedenken:
1) Pentium D en C2D hebben aanzienlijk meer cache-bandbreedte dan de Athlon. Het zou kunnen dat de Athlon net wat bandbreedte tekort komt om in 64-bit sneller te kunnen zijn.
2) De caches van Pentium D en C2D zijn een stuk groter dan van de Athlon. We zagen al dat de Athlon-variant met 2x1 mb L2 cache een stuk sneller was dan een gelijk geklokte Athlon met 2x512 kb cache. In 64-bit mode zul je nog wat meer cache nodig hebben vanwege grotere datatypen, dus wordt het nog krapper.

Ik heb al zo veel mogelijk geprobeerd om de data in te perken, en gebruik alleen 64-bit als het echt niet anders kan (zoals functiepointers of functie-argumenten). Dit gaf namelijk in eerste instantie ook op de andere 64-bit architecturen problemen, dus dat heb ik al tot een minimum beperkt, om de maximale snelheid eruit te halen. Ik denk dat het verschil in cachegebruik tussen 32-bit en 64-bit verwaarloosbaar is.

Wat je wel ziet is dat de minimum-framerate in 64-bit een stuk hoger blijkt te liggen, en ook de max framerate is best hoog (eigenlijk zou je het allemaal meerdere keren moeten testen, omdat het vuur-effect via een random-functie gemaakt wordt, heb je niet altijd dezelfde minima en maxima, die vooral tijdens het opstarten bepaald worden, als het eenmaal draait, blijft het meestal redelijk gelijk).

Het lijkt mij dus dat 64-bit op zich sneller is, qua verwerking van instructies (het minimum ligt immers een stuk hoger)... maar dat op een gegeven moment de cache (en misschien ook de chipset?) aan de handrem trekt, en het zaakje gewoon niet harder kan.
In dat geval kan ik er in de code niet veel aan doen. Wat je misschien kunt proberen, is je HT-bus sneller te klokken in verhouding tot de rest. Dat verbetert de communicatie van cache en chipset, wat dus precies de bottleneck is die ik vermoed.

Misschien weet iemand ook nog andere verklaringen? En nog beter, mogelijkheden om eromheen te kunnen werken?

[ Voor 4% gewijzigd door Anoniem: 133470 op 05-05-2007 13:02 ]

[Anoniem: 95522]

zodra ik terug ben in enschede zal ik voor jou ff anders gaan klokken...

wat ik wel wil weten is of je de tests dan 2x wil op dezelfde clockspeed met alleen de HT bus aangepast? lijkt me wel btw...

als er nog meer tests zijn die je wil uitproberen zal ik het voor je proberen

me chipset is trouwens de uLi1695 op een ASROCK 939Dual-sata2,
het ram draait op 250MHz 3-3-3-8 1T in dualchannel en is 2x1024MB OCZ Platinum PC4000 XTC EL

en wat de tests betreft die heb ik wel meerdere malen uitgevoert met vergelijkbare resultaten

[Anoniem: 133470]

Okee, als je ze meerdere keren hebt uitgevoerd, en steeds vergelijkbare resultaten, dan kunnen we er wel vanuit gaan dat het betrouwvaar is...
Dat betekent dus dat de CPU hard begrensd wordt door iets, in 64-bit mode.

Ik zou graag tests zien met verschillende HT-settings en de rest zo veel mogelijk gelijk.
Misschien is het ook interessant om tests te doen met verschillende snelheden van geheugen, bedenk ik zojuist... Het zou namelijk kunnen dat het niet de cache zelf is, maar het geheugen dat in 64-bit net wat snelheid tekort komt.
Ik ben benieuwd welk van de twee het meeste effect heeft.
Als we dan van alle configuraties 32-bit en 64-bit naast elkaar leggen, kunnen we misschien zien dat bepaalde dingen in 32-bit meer effect hebben dan in 64-bit, of omgekeerd. Daar kunnen we misschien uit afleiden waar de bottleneck dan precies zit.

[Anoniem: 144949]

Heb net windows 64bit eens geinstalleerd om te proberen en ik wil gerust deze test een laten lopen op men X2 4200+. Vraag is waar vind ik deze exe's om te downloaden?

Anoniem: 95522 schreef op zaterdag 05 mei 2007 @ 11:47:
Fire.exe: ~170fps
Fire-Multithread.exe: ~180fps
Fire-Multithread2.exe: ~240fps
Fire32.exe: min: ~239fps avg: ~315fps max: ~322fps
Fire32-x87.exe: min: ~242fps avg: ~310fps max: ~349fps
Fire64.exe: min: ~288fps avg: ~300fps max: ~343fps

Edit> laat maar gevonden: resultaten komen weldra

Fire32-x87 (2 threads)
Average: 253
Min: 248
Max: 277

Fire32-x87 (1 threads)
Average: 196
Min: 192
Max: 226

Fire32 (2 threads)
Average: 249
Min: 244
Max: 279

Fire32 (1 threads)
Average: 196
Min: 192
Max: 223

Fire64 (2 threads)
Average: 238
Min: 233
Max: 258

Fire64 (1 threads)
Average: 178
Min: 174
Max: 210

Voor de rest alles default zoals het stond.

[ Voor 29% gewijzigd door Anoniem: 144949 op 07-05-2007 13:32 ]

[Anoniem: 133470]

Okee, dus ook hier de trend dat de 64-bit versie trager is.
Interessant dat je ook met 1 thread hebt getest.
De trend zet zich hier voort, 32-bit is nog steeds sneller.

Met het geheugen zal het dan niet zo heel veel te maken hebben, denk ik. Je gebruikt nu immers maar 1 core tegelijk, die het geheugen voor zichzelf heeft.
Het probleem zal dus in de core zelf zitten.
Ik zal ook maar eens een thread in het programmeer-deel van het forum openen, eens kijken of iemand daar z'n licht erover kan laten schijnen.

[Anoniem: 133470]

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

Ben benieuwd of er een variant bij zit waar de Athlon mee uit de voeten kan. Mijn Core2 Duo iig niet, die wordt VEEL trager ervan.

[Anoniem: 95522]

ik zal direct ff testen, ben net thuis, dus mijn instellingen zijn nog steeds gelijk aan de vorige keer en ook zal ik alles weer draaien met default instelling

-EDIT-

net even geprobeert te draaien maar ze komen allemaal met de volgende melding:

C:\pad\naar\mijn\desktop\FireOpt\Fire64-(naam van exe).exe

This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem

[ Voor 122% gewijzigd door Anoniem: 95522 op 08-05-2007 11:12 ]

[Anoniem: 133470]

Hum, dan wil ie waarschijnlijk deze geinstalleerd hebben: http://www.microsoft.com/...ACABD5D13B&displaylang=en

[Anoniem: 95522]

nog steeds geens success en nog steeds dezelfde foutmelding

[Anoniem: 133470]

Ik denk dat ik het gevonden heb... de D3DX-DLL was nog van de vorige versie. Inmiddels heb ik m'n DX SDK geupdate, dus zoekt ie naar de nieuwere DLL.
Ik heb de rar-file geupdate, download hem opnieuw en probeer het nog eens?

[Anoniem: 169968]

Anoniem: 133470 schreef op dinsdag 01 mei 2007 @ 20:38:
Excuseer mij dat ik dit wat oudere topic weer omhoog schop, maar gezien de recente prijsdalingen van de Core2 Q6600 vermoed ik dat er intussen al aardig wat tweakers zijn met een quadcore in huis.

Ik hoop daar dus wat benchmarks van op te vangen. Mensen met systemen met meerdere processors, zowel Xeons als Opterons, zijn ook nog steeds welkom.

Bij voorbaat dank.

Zouden deze mensen dan ook zo vriendelijk willen zijn om wat xvid encoding benchmarks te testen ? Ben wel eens benieuwd of het effectief 2* zo snel als een dualcore of 4* zo snel als een singlecore processor zou zijn...

[Anoniem: 95522]

offtopic:
zoals degene boven mij hoort te weten krijg je met een "extra" processor effectief nooit de dubbele performance (of 4x performance in geval van SC --> QC) vanwege overhead en gedeelde bronnen...

[ONTOPIC]
nog steeds dezelfde foutmeldingen
[/ONTOPIC]

[ Voor 12% gewijzigd door Anoniem: 95522 op 09-05-2007 08:48 ]

[rapture]

Anoniem: 133470 schreef op zaterdag 05 mei 2007 @ 12:56:
Waarom dat is, weet ik niet. Bij Pentium D is de 64-bit aanzienlijk sneller, en ook de C2D sleept een aantal procenten meer snelheid eruit.
Aan het algoritme op zich ligt het dus niet. Het kan op de juiste architectuur wel degelijk een stuk sneller zijn dan de 32-bit versie.
De vraag is dus specifiek waarom het op de Pentium D en C2D-architectuur wel lukt, en op de Athlon/Opteron niet.

Ik kan wel een aantal hypotheses bedenken:
1) Pentium D en C2D hebben aanzienlijk meer cache-bandbreedte dan de Athlon. Het zou kunnen dat de Athlon net wat bandbreedte tekort komt om in 64-bit sneller te kunnen zijn.
2) De caches van Pentium D en C2D zijn een stuk groter dan van de Athlon. We zagen al dat de Athlon-variant met 2x1 mb L2 cache een stuk sneller was dan een gelijk geklokte Athlon met 2x512 kb cache. In 64-bit mode zul je nog wat meer cache nodig hebben vanwege grotere datatypen, dus wordt het nog krapper.

Ik zou de cache verdenken, hoe groot is de "critical loop"? Core 2 Duo kan met 4MB cache, de hele "critical loop" in de cache laten draaien, dat gaat sneller dan een AMD met bv 1MB of 2MB cache. Wanneer de "critical loop" niet meer in de cache past, dan zal het geheugen intensief benaderd worden. Intel probeert het op te lossen door caches te vergroten zodat er minder kans is dat de "critical loop" buiten de cache valt. AMD kan geen monstercaches opzetten wegens plaats vreten op de wafers (beperkte productiecapaciteit en moet meer processors kunnen bakken) en zorgt ervoor dat het geheugen zo snel mogelijk benaderd kan worden. Aangezien de geheugentoegang sneller gaat, dan heeft een Athlon64 weinig baat met grote caches voor de reallifetoepassingen. Lagere latencies, bij wijze van spreken moet een Intel 200 kloktikken met de figuurlijke vingers draaien voordat eindelijk wat data uit het ram komt en een AMD moet bv slechts 50 kloktikken wachten op data uit het ram. Data uit de cache ophalen gaat nog veel sneller omdat een processor enkele kloktikken moet wachten op data. Uiteindelijk gaan we benchen met echte applicaties ipv allerlei synthetische tooltjes, in bv Sisoft Sandra kan je de mooiste grafiekjes tonen, maar dat zal niet kunnen zeggen of we sneller kunnen Photoshoppen, Xvid's encoderen of niet. Afhankelijk van je ontwerp, kan je Intel of AMD bevoordelen in de testen.

[Anoniem: 133470]

Ja, de cache zal er vast mee te maken hebben. Hierboven staan ook ergens resultaten van Athlons met 2x512 kb cache tegen Athlons met 2x1 mb cache, op grofweg dezelfde kloksnelheid.
Je ziet dan dat die extra cache hier een flink verschil maakt. Meer dan je in veel andere applicaties ziet.
Ik denk dat de cache echt tot het uiterste gepusht wordt bij de Athlon, zowel qua bandbreedte als capaciteit... Dat de rest van de code dusdanig optimaal is dat de CPU eigenlijk de hele tijd op de cache zit te wachten. Bij minder cache heb je meer cache misses, die er dan hard inhakken, omdat er weinig of geen code is om het te 'maskeren'.

Dan ligt namelijk de verklaring voor de hand dat de 64-bit code misschien wel sneller is in theorie (en in de praktijk ook op Pentium D en Core2 Duo), maar dat dat bij de Athlon alleen maar betekent dat instructies langer op de cache gaan zitten wachten, ipv dat je ook echt meer werk kunt verzetten.
Neem daarbij het feit dat sommige data in 64-bit mode ook net wat groter is, en de cache nog zwaarder belast, en dat zou dan een plausibele verklaring zijn voor het feit dat de 64-bit versie een paar procentjes trager is dan de 32-bit versie.

Of het waar is, weet ik niet. Ik ga nu af op wat cache-benchmarks tussen Core2, Pentium D en Athlon die ik oa op tweakers.net gevonden heb. Vooral de L2 was significant trager bij Athlon. En ik gebruik zeker meer dan 64k data, dus aan L1 heb ik niet genoeg.
Als ik dat dus combineer met de resultaten van de Athlons met verschillende caches, lijkt het er idd op dat de L2-cache een grote rol speelt bij deze applicatie.

Ik zou de resolutie een stuk kunnen verkleinen, dat zou iig de hoeveelheid benodigde cache verminderen, en daarmee zou je minder afhankelijk zijn van de L2-bandbreedte, en meer van de L1-bandbreedte. Misschien dat het dan omslaat.

[rapture]

Volgens een gedateerd tabelletje heeft een Athlon 64 128-bit L2 cache bus, terwijl een Xeon 256-bit L2 cache bus. Hoe zit dat nu?

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

[Anoniem: 133470]

Als ik deze benchmark-resultaten zie, zou dat best kunnen kloppen: reviews: Intel Core 2 Extreme QX6700 review

De Core2 is ongeveer twee keer zo snel in de L2-benchmarks.
De L1-benchmarks zijn ook behoorlijk in het voordeel van de Core2, al is dat vooral bij het schrijven, en mijn applicatie leest eigenlijk alleen maar, voor zeker 80% van de tijd (het enige dat geschreven wordt, is dus de geometrische data, maar de CPU leest die niet meer terug, dat gaat naar de GPU).
Helaas staat de Pentium 4/D er niet tussen, maar gezien de hoge kloksnelheden van die architectuur lijkt het me voor de hand liggen dat die ook meer bandbreedte heeft, ook al heeft ie net als de Athlon een 128-bit bus.
Hier staan wel wat 'cachemem' benchmarks, waar de Pentium sneller is dan de Athlon, maar het is niet heel duidelijk wat er precies getest wordt (combinatie van L1, L2 en geheugen?): http://xtreview.com/review82.htm

[ Voor 12% gewijzigd door Anoniem: 133470 op 09-05-2007 11:02 ]

[Anoniem: 95522]

nog geen oplossing om de nieuwe benches te draaien?!?!

newees lemme know

[Anoniem: 133470]

Nee, helaas nog niet... Ik heb niet echt een idee waarom ie nu niet wil... De foutmelding is niet heel duidelijk.
Werken de oudere benchmarks wel nog steeds op je systeem?

[Murk]

Ik zie nou wel hee veel van die benchmarks en stuffzors, maar het is al zeer vaak gebleken dat het in het pc-gebruik anders uitpakt. Is er iemand die mij een voorbeeld kan geven die gemerkt heeft dat hij nu 2 programmas tegelijkertijd vlot kon uitvoeren, wat hij eerst niet kon met een singlecore processor?

[Anoniem: 133470]

Ligt eraan he?
Mijn broer gebruikt bv vaak Vegas om video's te bewerken.
Sinds hij een dualcore heeft, is het encoden van video's er enorm op vooruit gegaan.
Da's geen multitasking natuurlijk, maar multithreading. Vind ik persoonlijk interessanter, maargoed (vandaar ook dit stuk code, dat ook een flink stuk sneller is dan op een single-core. Daar is het mij om te doen).

Multitasking vond ik over het algemeen toch al erg goed gaan in Windows... Al moest je in sommige gevallen zelf even de prioteiten van bepaalde processen aanpassen voordat het werkte zoals je zou willen. Zo moest ik bv de prioriteit van PowerDVD op hoog zetten, anders sloeg het beeld en geluid nogal gauw over als je even wat ging websurfen ofzo. Nu hoeft dat niet meer.
Verder multitask ik weinig. Tenminste, ik beschouw 'applicaties/windows open hebben' niet als multitasken, zolang die applicaties/windows niets doen. Ik zit meestal maar in 1 applicatie tegelijk te werken, en andere windows stellen vaak zo weinig voor qua resources, dat het geen invloed heeft op de prestaties (webbrowsertje open, notepad, calc, MSN, Outlook... dat soort dingen... als je maar geheugen hebt, draait het wel, geen programma's die minutenlang je CPU bezig houden).
Op mijn vorige PC (XP1800+) was een dvd kijken zo ongeveer het zwaarste dat ik 'in de achtergrond' deed. Aan de andere kant is m'n nieuwe PC dusdanig snel dat DVD kijken misschien ook de CPU nauwelijks meer belast.

[ Voor 31% gewijzigd door Anoniem: 133470 op 09-05-2007 16:39 ]

[rapture]

Murk schreef op woensdag 09 mei 2007 @ 16:27:
Ik zie nou wel hee veel van die benchmarks en stuffzors, maar het is al zeer vaak gebleken dat het in het pc-gebruik anders uitpakt. Is er iemand die mij een voorbeeld kan geven die gemerkt heeft dat hij nu 2 programmas tegelijkertijd vlot kon uitvoeren, wat hij eerst niet kon met een singlecore processor?

Mijn Photoshop-gedrag, ik selecteer ergens 100 of meer raw's, dump deze in Photoshop, de raw's worden Camera Raw module bekijken/ingesteld, dan alle bestanden omzetten naar jpeg met de nodige nabewerking. Dan zit een core @ full load te draaien en ik kan op een andere core doorwerken, bv verslag typen ipv vroeger wachten totdat Photoshop gedaan is. Of de combinatie van XviD-encoding/videobewerking-batches en gamen.

[Abbadon]

rapture schreef op woensdag 09 mei 2007 @ 10:47:
Volgens een gedateerd tabelletje heeft een Athlon 64 128-bit L2 cache bus, terwijl een Xeon 256-bit L2 cache bus. Hoe zit dat nu?

[...]

Dat klopt. Intel heeft al sinds de P!!! met on-die L2 cache (Advanced Transfer Cache) 256bit brede bussen met het L2 cache, de huidige Core cpu's hebben dit ook. AMD heeft altijd al achter gelopen met L2 cache snelheid; de eerste Athlon's met on-die cache (Thunderbird) had maar een 64bit brede bus, dit werd later met de AMD 64 cpu's verhoogd naar 128bit. Daarnaast hebben de L2 caches van Intel ook altijd een lagere latency gekend dan die van AMD, dit in combinatie met de bredere bus maakt de Intel L2 caches een stuk sneller.

[Anoniem: 95522]

ja de oude tests werken nog wel

[Murk]

rapture schreef op woensdag 09 mei 2007 @ 16:34:
[...]
Mijn Photoshop-gedrag, ik selecteer ergens 100 of meer raw's, dump deze in Photoshop, de raw's worden Camera Raw module bekijken/ingesteld, dan alle bestanden omzetten naar jpeg met de nodige nabewerking. Dan zit een core @ full load te draaien en ik kan op een andere core doorwerken, bv verslag typen ipv vroeger wachten totdat Photoshop gedaan is. Of de combinatie van XviD-encoding/videobewerking-batches en gamen.

En zoiets gaat volautomatisch? (core-switchen)

[rapture]

Murk schreef op donderdag 10 mei 2007 @ 09:36:
En zoiets gaat volautomatisch? (core-switchen)

Windows XP deelt de processen automatisch over de cores. Een singlethreaded proces kan max een core volledig bezetten. Tja, dan moet de rest wel op een andere core draaien. Je kan ook manueel afdwingen dat een bepaald proces op een bepaalde core moet draaien.

[Anoniem: 133470]

Ik denk dat ik het probleem gevonden heb...
Hoewel, Knorrend_varken heeft het gevonden, lijkt het.

De link die ik hierboven had gezet voor de VC++ redist is de oude versie.
Microsoft heeft deze nooit geupdate, maar heeft de nieuwe ergens anders geplaatst. Ik heb sinds de eerste versie SP1 van VS2005 geinstalleerd, dus zul je waarschijnlijk ook de SP1-variant van de VC++ redist moeten installeren.
Hier vind je de versie voor x86: http://www.microsoft.com/...9C36F85647&displaylang=en
En hier is de variant voor x64: http://www.microsoft.com/...BD44DA%26displaylang%3den

Ik hoop dat dat ervoor zorgt dat de nieuwe versies ook weer bij iedereen werken.

[FireFoz]

ik heb inmiddels een Q6600, dus als ik nog iets moet testen...?

[needless to say]

ik weet dat het lang geleden is, maar ik heb na lange tijd nog eens windows xp 64-bit geïnstalleerd. Ik heb dan ook de laatste versie van je test gedownload.

Blijkbaar zit er alleen nog maar een 64-bits versie in de rar? Ik heb dus enkel in 64-bit kunnen testen.

Alle instellingen zijn standaard.

Mijn specs zijn:
AMD Athlon64 X2 4600+ Manchester 2,4 GHz S939 2x 512kiB L2 cache @stock
2 GiB DDR400 RAM@stock (400 MHz, 2-3-2-5)
nVidia Geforce 7900 GT @stock (allez, zelfde speeds als degene waarmee ik hem gekocht heb: 470MHz core en 685MHz memory)

In volgorde van snelheid:
Fire64-MinimizeSize: min: 165, Max: 219, Avg: 183
Fire64-FavorSmallCode: min: 165, Max: 225, Avg: 190
Fire64-FavorFastCode: min: 234, Max: 281, Avg: 260
Fire64-Neither: min: 232, Max: 284, Avg: 260

[silentsnake]

Ik heb het topic al een tijdje gevolgd maar ik heb toch even een vraagje voor de TS.

Je hebt het in het verleden erover gehad dat je een Intel compiler voor Windows gebruikt (althans, je zegt dat je geen Intel compiler hebt voor Linux). Dan lijkt het mij toch ook aannemelijk dat de compiler optimaliseerd voor de Intel architectuur en geen standaard i686 code produceert. Kan de 64bit performance van AMD daardoor ook niet beinvloed zijn? Misschien denk ik wel te simpel, maar het lijkt mij dat compiler optimalisaties wel degelijk invloed kunnen hebben op de performance.

Anders pak je eens GCC voor zowel Windows als Linux en vergelijk de resultaten op die manier? Ik zag dat je er al minder positieve ervaringen mee had, maar als het puur om vergelijking gaat en je gewoond standaard compiler flags houdt lijkt mij toch wel dat je op die manier wel min of meer kan bevestigen of de 64bit performance van AMD inderdaad minder is.

Nogmaals, wellicht denk ik veel te simpel hoor. Ik ben ook zeker geen ster in dit soort dingen