Mijn voorlopige bevindingen over multicore-processing

[Verwijderd]

Allereerst post je een binary zonder source code waardoor er in principe voor mensen die willen reageren er niets zinnigs valt te zeggen over jouw bevindingen.

Het algoritme lijkt me algemeen bekend... en als het je niet bekend is, kun je weinig zinnigs erover zeggen, sourcecode of geen sourcecode.
Afgezien daarvan krijg ik niet de indruk dat de gemiddelde got'er hier programmeur is.

Natuurlijk kan men hier ruwe stats posten maar dat zou een opsomtopic zijn.

Daar is het ook voor.
Ik wil graag wat informatie verzamelen over verschillende typen systemen waar ik zelf niet over beschik.
Voornamelijk nog multi-CPU systemen nu dus, en een quadcore lijkt me ook interessant om te testen, om een indruk te krijgen van hoe het algoritme schaalt naar meer dan 2 cores.

Om eerlijk te zijn heb ik je programma niet kunnen draaien omdat het niet bepaald portable/hercompileerbaar is. En als het om het algoritme gaat waarom heb je dit dan niet beschikbaar gesteld zodat wij dit kunnen bekijken?

Omdat het algoritme niet vrij is, er kan en mag dus niet naar gekeken worden, en daar ben ik ook niet in geinteresseerd. Je kunt het wel door VTune halen oid, om te zien waar de bottlenecks liggen, daar heb je de source niet voor nodig, en daar zou ik erg mee geholpen zijn.

Je wekt de indruk met je topic dat SMP (of MCP) iets is wat helemaal nieuw is terwijl ik (en vele anderen) al vele jaren een multi core systeem heb waar ik op werk.

Dan heb je het verkeerd begrepen. Wat naar mijn mening helemaal nieuw is (in ieder geval in de wereld van de 'standaard'-hardware) is een multicore CPU met shared cache (okee, technisch gezien sinds de Core Duo en niet de Core2 Duo, maar Core Duo was vanwege de beperkte prestaties niet interessant, dus die heb ik overgeslagen).

En als je het hebt over het verwerken van MRI-scans dan kunnen daar inderdaad veel optimalisaties worden gemaakt door goed gebruik te maken van de resources. Echter vraag ik me of af het echt zinvol is om bwvs 50 threads over 1 scan te laten lopen die vervolgens de helft van de tijd op elkaar staan te wachten ivm memory-access.

Ze staan helemaal niet op elkaar te wachten in de nieuwste versie. Kijk maar eens hoe bijzonder goed het schaalt tov oude singlethreaded-versie.
De eerste versie was een test om te kijken hoe ver je kon komen, aangezien er maar beperkt gebruik wordt gemaakt van shared geheugen (hoe groter de grid, hoe minder... de grid is expres nogal klein gelaten, meestal is ie een factor 2 groter, of meer).

Dan heb ik liever een zwaar quad-core systeem waar bijv. 1 core voor de GUI is, 1 voor de verwerking van de data en nog 1 voor het opbouwen van een 3D model en de rest voor de overige services van het systeem.

Lijkt me nogal onzinnig aangezien dat totaal niet in verhouding staat tot de benodigde CPU-kracht van de verschillende taken. GUI en overige services zijn sowieso verwaarloosbaar. Verwerken van data stelt ook weinig voor... je verwerkt het tijdens het scannen, en daarna ga je het bekijken. Het scannen moet toch eerst klaar zijn, anders valt er weinig te bekijken.

Misschien is het systeem met 50 cores wel sneller dan een met 8 cores, alleen het rendement zou flink af kunnen nemen als er meer cores zijn.

En dat is nou juist de vraag die ik beantwoord wil zien: In hoeverre kan dit schalen naar meerdere cores?
Ik ben op zich al tevreden over de prestaties van dualcore. 40% sneller, of soms zelfs meer. En sommige CPUs gooien er in 64-bit modus ook nog een flinke schep bovenop, da's ook aardig.
Als ik bij een quadcore nog eens 80% meer krijg dan een singlecore, zou dat fantastisch zijn.
Schaalt het niet zo enorm goed, dan kun je altijd nog kijken of het handig is om dan bv 3 van de 4 cores te gaan gebruiken voor de visualisatie, en de laatste core voor de andere taken.

[Verwijderd]

Verwijderd schreef op vrijdag 10 november 2006 @ 16:47:
[...]
...
Het algoritme lijkt me algemeen bekend... en als het je niet bekend is, kun je weinig zinnigs erover zeggen, sourcecode of geen sourcecode.
Afgezien daarvan krijg ik niet de indruk dat de gemiddelde got'er hier programmeur is.

..

offtopic:
Met deze en verschillende andere reacties ontlok je nu niet bepaald zinning input
. En ik vind vooral jou reacties agressief, als je niet tegen wat opbouwende kritiek kunt moet je niet posten.

Voor de gein wel ff gedraait

P4 2.8G @3.2 HT
Matrox G450 DH

Fire: 22fps
Fire-Multithread.exe: 28fps
Fire-Multithread2.exe: 28fps

[ Voor 8% gewijzigd door Verwijderd op 10-11-2006 17:43 ]

[DroogKloot]

Verwijderd schreef op vrijdag 10 november 2006 @ 16:47:
[...]

Het algoritme lijkt me algemeen bekend... en als het je niet bekend is, kun je weinig zinnigs erover zeggen, sourcecode of geen sourcecode.

Het gaat dus om jouw implementatie waar nu door niemand behalve jijzelf iets over te zeggen valt.

Omdat het algoritme niet vrij is, er kan en mag dus niet naar gekeken worden...

Onzin, het patent op MC is vorig jaar verstreken (aangezien het werd ingediend in 1985).

[Verwijderd]

offtopic:
Met deze en verschillende andere reacties ontlok je nu niet bepaald zinning input
. En ik vind vooral jou reacties agressief, als je niet tegen wat opbouwende kritiek kunt moet je niet posten.

Ik vind dat er daar aangestuurd word op een opensource-discussie, waar ik absoluut geen trek in heb, dus daar verzet ik me duidelijk tegen.
Verder heb ik nog nergens opbouwende kritiek gezien, alleen maar een hoop verkeerde aannamen, en 'kritiek' waar ik niets mee kan, omdat het gewoon gebaseerd is op foute informatie.
Daarom vind ik het ook zo jammer dat er helemaal geen reactie meer is nadat ik heb uitgelegd hoe het wel zit. Zeg dan op z'n minst dat je het begrijpt, of dat je het er nog steeds niet mee eens bent omdat...
Na keer op keer van die vervelende reacties raakt m'n geduld wel een beetje op ja... het topic vervuilt, en niemand schiet er wat mee op.

Voor de gein wel ff gedraait

P4 2.8G @3.2 HT
Matrox G450 DH

Fire: 22fps
Fire-Multithread.exe: 28fps
Fire-Multithread2.exe: 28fps

Inderdaad, dat is zo'n videokaart die dermate traag is dat ie WEL invloed heeft op de prestaties.
In dit geval ligt dat voornamelijk aan het ontbreken van hardware T&L, waardoor de CPU ineens veel meer rekenwerk voor z'n kiezen krijgt.

[ Voor 5% gewijzigd door Verwijderd op 10-11-2006 18:54 ]

[Verwijderd]

Het gaat dus om jouw implementatie waar nu door niemand behalve jijzelf iets over te zeggen valt.

Tuurlijk wel, ik het heb naar mijn mening duidelijk genoeg toegelicht voor mensen die bekend zijn met het algoritme in het algemeen, en zo niet, dan sta ik geheel open voor alle vragen.

Onzin, het patent op MC is vorig jaar verstreken (aangezien het werd ingediend in 1985).

Dat algoritme misschien wel, maar dat wil niet zeggen dat hetgeen hier ook meteen vrij is omdat het er enigszins mee te maken heeft.
Sowieso wil ik het er niet over hebben. Opensource-discussies doe je maar in je eigen topic. Ik wil er hier niet op in gaan.

[LauPro]

Verwijderd schreef op vrijdag 10 november 2006 @ 16:47:
[...]
Het algoritme lijkt me algemeen bekend... en als het je niet bekend is, kun je weinig zinnigs erover zeggen, sourcecode of geen sourcecode.
Afgezien daarvan krijg ik niet de indruk dat de gemiddelde got'er hier programmeur is.

Het gaat niet om het algoritme maar om jouw implementatie ervan. Niet iedereen zal hier wat aan hebben, maar neemt niet weg dat er mensen zijn met interesse, zie ook [alg] Gebruik maken van multiple cores .

Daar is het ook voor.
Ik wil graag wat informatie verzamelen over verschillende typen systemen waar ik zelf niet over beschik.
Voornamelijk nog multi-CPU systemen nu dus, en een quadcore lijkt me ook interessant om te testen, om een indruk te krijgen van hoe het algoritme schaalt naar meer dan 2 cores.

Dat zou een opsomtopic zijn en is voor zover ik weet niet toegestaan. GoT is geven en nemen, als jij statistieken wilt nemen dan zul je er iets voor terug moeten geven.

Omdat het algoritme niet vrij is, er kan en mag dus niet naar gekeken worden, en daar ben ik ook niet in geinteresseerd. Je kunt het wel door VTune halen oid, om te zien waar de bottlenecks liggen, daar heb je de source niet voor nodig, en daar zou ik erg mee geholpen zijn.

Het algoritme is dus niet vrij maar wel algemeen bekend?

Ze staan helemaal niet op elkaar te wachten in de nieuwste versie. Kijk maar eens hoe bijzonder goed het schaalt tov oude singlethreaded-versie.
De eerste versie was een test om te kijken hoe ver je kon komen, aangezien er maar beperkt gebruik wordt gemaakt van shared geheugen (hoe groter de grid, hoe minder... de grid is expres nogal klein gelaten, meestal is ie een factor 2 groter, of meer).

Ik kan het niet controlleren, ik kan alleen ruwe stats zien er eruit komen maar dat zegt niets over de implementatie zelf.

Lijkt me nogal onzinnig aangezien dat totaal niet in verhouding staat tot de benodigde CPU-kracht van de verschillende taken. GUI en overige services zijn sowieso verwaarloosbaar. Verwerken van data stelt ook weinig voor... je verwerkt het tijdens het scannen, en daarna ga je het bekijken. Het scannen moet toch eerst klaar zijn, anders valt er weinig te bekijken.

Het zou toch een realtime systeem kunnen zijn? Dan moet er wel degelijk data worden ingelezen en daarna worden verwerkt. Afhankelijk van het type conversie kan dit veel/weinig CPU kracht nodig hebben inderdaad, maar het is naar mijn idee meest logische verdeling itt om 30+ threads aan te maken en dan te hopen dat zie goed worden verdeeld over een dual core CPU.

En dat is nou juist de vraag die ik beantwoord wil zien: In hoeverre kan dit schalen naar meerdere cores?
Ik ben op zich al tevreden over de prestaties van dualcore. 40% sneller, of soms zelfs meer. En sommige CPUs gooien er in 64-bit modus ook nog een flinke schep bovenop, da's ook aardig.
Als ik bij een quadcore nog eens 80% meer krijg dan een singlecore, zou dat fantastisch zijn.
Schaalt het niet zo enorm goed, dan kun je altijd nog kijken of het handig is om dan bv 3 van de 4 cores te gaan gebruiken voor de visualisatie, en de laatste core voor de andere taken.

Naar mijn idee zijn deze resultaten al lang duidelijk. En wat blijkt: hoe meer cores hoe meer je moet syncen (met alles erop en eraan) waardoor het meer tijd kost en dus het rendement van de cores individueel af neemt.

[Verwijderd]

Het gaat niet om het algoritme maar om jouw implementatie ervan. Niet iedereen zal hier wat aan hebben, maar neemt niet weg dat er mensen zijn met interesse, zie ook [alg] Gebruik maken van multiple cores

Zoals ik al zei, ik heb naar mijn mening voldoende informatie gegeven over de werking van mijn implementatie, en zo niet, sta ik open voor inhoudelijke vragen daarover.
Over sourcecode kun je lang en breed discussieren, maar dat is een andere discussie, en daar zullen we ongetwijfeld niet dezelfde mening over hebben.
Naar mijn mening is ontwerp, documentatie en uitleg veel belangrijker dan de sourcecode die het oplevert, en over die eerste drie ben ik volledig open, dus ik denk niet dat we die discussie hoeven voeren. Stel maar inhoudelijke vragen, dan komen we er wel uit.

Dat zou een opsomtopic zijn en is voor zover ik weet niet toegestaan. GoT is geven en nemen, als jij statistieken wilt nemen dan zul je er iets voor terug moeten geven.

Ik geef genoeg. Ik geef een aantal varianten van mijn implementatie, ik geef daarover achtergrondinformatie, en ik wil graag over de resultaten discussieren, zodat het voor ons allemaal helder wordt hoe de verschillende systemen het best presteren.

Het algoritme is dus niet vrij maar wel algemeen bekend?

Vind je dat vreemd? Het is nogal gebruikelijk om bij een patentaanvraag een duidelijke beschrijving te geven, die voor iedereen inzichtelijk is. Het is immers nogal lastig om te bepalen of iets al dan niet een patent schendt als je niet weet wat dat patent inhoudt.
Deze patenten zijn echter nooit letterlijke sourcecode, wat mijn bovenstaande punt over opensource ondersteunt.

Ik kan het niet controlleren, ik kan alleen ruwe stats zien er eruit komen maar dat zegt niets over de implementatie zelf.

Waarom stel je dan geen inhoudelijke vragen?
Ik krijg sterk de indruk dat je gewoon even gratis de sourcecode wilt scoren, in plaats van dat je oprecht geinteresseerd bent in de werking ervan.
Sourcecode ga je niet krijgen, dus dat hoef je niet te proberen. Dus stel inhoudelijke vragen, of hou erover op, ik wil verder geen discussie over opensource hier, daar open je maar je eigen topic voor. Ik beschouw dat hier als sterk offtopic.

Het zou toch een realtime systeem kunnen zijn? Dan moet er wel degelijk data worden ingelezen en daarna worden verwerkt. Afhankelijk van het type conversie kan dit veel/weinig CPU kracht nodig hebben inderdaad, maar het is naar mijn idee meest logische verdeling itt om 30+ threads aan te maken en dan te hopen dat zie goed worden verdeeld over een dual core CPU.

Het visualiseren is realtime, het scannen niet (beetje lullig als de patient iedere keer in dat apparaat moet omdat de dokter nog eens naar de scan wil kijken).
Hooguit zul je data inlezen van disk, als je een hele grote scan hebt, maar tegenwoordig is geheugen goedkoop, dus dat is niet echt een issue. Afgezien daarvan zou ik hooguit 1 core nodig hebben voor het inlezen ervan.
Hoe kom je er trouwens bij dat ik 30+ threads aan zou maken op een dualcore?
Het algoritme gebruikt evenveel threads als dat er cores zijn. Lijkt me nogal logisch... dat is echt multithreading 101, ik hoop dat je begrijpt dat dit stukje software niet geheel beginnersniveau is.

Naar mijn idee zijn deze resultaten al lang duidelijk.

Naar mijn idee dus duidelijk niet (in ieder geval niet in deze specifieke applicatie), anders had ik dit topic niet geopend.

En wat blijkt: hoe meer cores hoe meer je moet syncen (met alles erop en eraan) waardoor het meer tijd kost en dus het rendement van de cores individueel af neemt.

Ja, die open deur is al tig keer ingetrapt. Dat is misschien genoeg informatie voor een tweaker, maar ik als ontwikkelaar moet ook weten hoeveel meer tijd het kost en hoeveel het rendement afneemt, zodat ik kan bepalen waar ik de grens ga leggen.
Dat is lastig in te schatten, zeker met systemen waarop je zelf niet over beschikt, dus gaat er niets boven wat praktijktesten.

[needless to say]

Verwijderd schreef op vrijdag 10 november 2006 @ 10:18:
Waarom zijn er trouwens zo veel mensen die (onterecht) de methode in twijfel trekken?
Eerst Abaddon, dan dion_b, needless to say, etc)...
En waarom reageren ze daarna ineens niet meer?

Beetje flauw allemaal.

Het zal veeleer wegens tijdsgebrek zijn. Ik moest een project afwerken waarvoor ik een programma in C moest schrijven dat multithreaded was én via RPC aan distributed computing deed.

Ik kende het algoritme niet en had geen toegang tot jouw source. Ik dacht dat dit puur een demonstratie was en niet een programma dat professioneel ingezet ging worden. Die opmerking over: als je het algoritme niet kent, dan ben je niets met de source is imo wel misplaatst. Een algoritme is snel geleerd hoor. En in mijn laatste jaar Licentiaat Informatica doe ik niets anders dan code optimaliseren van algoritmes waar ik vroeger nooit van gehoord had.

Bij nader bekijken lijkt het inderdaad zo dat het optimaliseren voor meerdere cores met jouw algoritme "gemakkelijker" is voor een systeem met shared cache voor de verschillende cores.

Ik ben er echter van overtuigd dat bij verder optimaliseren de speedup bij de X2 de speedup bij de C2D kan benaderen.

Jouw fire32 draait nu iets van een 260fps op mijn systeem.

Je opmerking over de Windows Sheduler zal echter niet 100% juist zijn. Zoals reeds vermeld, bij jouw programma wordt maar 1 core volledig benut. De ander maar maximaal 90% (en dit wanneer ik de totale belasting van de cores bekijk, niet enkel jouw proces), afhankelijk van de gedraaide versie. Andere multithreaded programma's (winrar, DVDShrink, etc...) gebruiken steeds 100% van beide cores en genereren hierdoor een grotere speedup. DVDShrink werkt echt bijna 100% sneller bij het gebruik van beide cores. Ik ben er dan ook van overtuigd dat een perfect te paralleliseren algoritme (zoals jij beweert dat dit algoritme zou zijn) veel meer zou moeten kunnen meeschalen.

Ik heb echter nooit negatief willen zijn of negatieve kritiek willen spuien. Het was veeleer feedback die ik wou geven.

[ Voor 3% gewijzigd door needless to say op 10-11-2006 21:28 ]

[Verwijderd]

Die opmerking over: als je het algoritme niet kent, dan ben je niets met de source is imo wel misplaatst. Een algoritme is snel geleerd hoor.

Een algoritme is vast snel geleerd, maar dat wil niet zeggen dat de sourcecode een goede manier is om dat te leren.
Zeker niet in dit geval, waar de sourcecode eigenlijk alleen maar wat met tabellen met vage indexjes hannest...
Wat er precies in die tabellen zit, en waarom ie wat doet... dat kun je aan de sourcecode onmogelijk afleiden, daarvoor zul je toch het algoritme moeten kennen.
De sourcecode is in feite een niveau lager dan het algoritme zelf, en vanwege allerlei ontwerp- en implementatiekeuzes kun je niet alles meer terugvinden in de sourcecode zelf.

Verder vind ik dat het tegenwoordig wel erg trendy is om overal maar om sourcecode te zeuren.
Ik wissel al jaren ideeen, algoritmen en optimalisaties uit met vooraanstaande graphics-programmeurs over de hele wereld, en daarbij hebben we eigenlijk nog nooit een letter sourcecode gebruikt. Mijn 3d engine maakt gebruik van allerlei technieken van 3DMark03 en Doom3, zonder van beiden ook maar ooit een letter sourcecode gezien te hebben. Alles volgt vanzelf uit de artikelen die erover gepubliceerd zijn, en van uitleg van de programmeurs zelf.

Bij nader bekijken lijkt het inderdaad zo dat het optimaliseren voor meerdere cores met jouw algoritme "gemakkelijker" is voor een systeem met shared cache voor de verschillende cores.

Dat leek wel zo, maar dat bleek uiteindelijk dus toch niet. Met shared cache kun je tot een iets efficienter resultaat komen, waardoor je het werk van de GPU minimaliseert.
Maar het blijkt dat de winst op de GPU veel te klein is, en het verlies aan de CPU-zijde te groot.

Ik ben er echter van overtuigd dat bij verder optimaliseren de speedup bij de X2 de speedup bij de C2D kan benaderen.

Zover zijn we toch al? Kijk maar naar de resultaten van de 4800+. Blijkbaar zat het hem deels in de cachegrootte.

Je opmerking over de Windows Sheduler zal echter niet 100% juist zijn. Zoals reeds vermeld, bij jouw programma wordt maar 1 core volledig benut. De ander maar maximaal 90% (en dit wanneer ik de totale belasting van de cores bekijk, niet enkel jouw proces), afhankelijk van de gedraaide versie.

Zoals ik al zei, krijgt mijn thread niet altijd voorrang, dat zal er deels mee te maken hebben.
Verder is er inderdaad 10-15% van de code die niet op 2 cores loopt.
Ik dacht eerst dat het alleen de Direct3D-overhead was, en daarvoor vond ik 10-15% wel erg hoog.
Maar ik herinner me nu dat ik het vullen van de grid ook niet multithreaded had gemaakt, uiteindelijk.
Er was namelijk een probleem met de random-functie. Wanneer deze door meerdere threads op ongeveer hetzelfde tijdstip werd aangeroepen, kwam er hetzelfde resultaat uit. Dat gaf m'n vuur een wel erg symmetrisch gezicht. Omdat het destijds verder niet heel relevant voor de performance was, besloot ik het gewoon singlethreaded te laten.
Inmiddels is de rest dermate geoptimaliseerd dat het nu best wel eens 10-15% van het totaal kan zijn (tezamen met de Direct3D-calls dan, die ook op 1 core moeten). Dat zou het wel verklaren.

Andere multithreaded programma's (winrar, DVDShrink, etc...) gebruiken steeds 100% van beide cores en genereren hierdoor een grotere speedup. DVDShrink werkt echt bijna 100% sneller bij het gebruik van beide cores. Ik ben er dan ook van overtuigd dat een perfect te paralleliseren algoritme (zoals jij beweert dat dit algoritme zou zijn) veel meer zou moeten kunnen meeschalen.

Zoals net uitgelegd, zijn er dus bepaalde dingen die ik niet op 2 of meer cores kan doen (we moeten even onderscheid maken tussen het algoritme, en het omliggende framework waarmee het getest wordt). Je kunt het dus niet helemaal vergelijken met programma's waarbij dat wel kan.
Ik moet m'n resultaten sowieso altijd naar 1 videokaart sturen (ook in het geval van SLI/Crossfire is het vanuit het systeem gezien 1 videokaart). Winrar heeft het wat makkelijker, je kunt met een bestand makkelijk op meerdere plaatsen tegelijk schrijven (zeker met memmapped I/O).

Ik heb echter nooit negatief willen zijn of negatieve kritiek willen spuien. Het was veeleer feedback die ik wou geven.

Tsja, het was nogal kortaf... Het gaat niet specifiek om jou, maar alles bij elkaar vond ik het wel een beetje te negatief en te weinig bruikbare info. Ik ben geen n00b, en deze code draait sowieso al op een zeer acceptabele snelheid, er is immers door de tijd al aardig aan gesleuteld (ik zou de opensource-versie van OpenDX er niet naast leggen, als je nog enigszins vertrouwen in de kwaliteit van opensource wilt houden).
Een beetje meer respect en wat meer inhoudelijke posts mogen dus best. Of gewoon niet reageren als je niks nuttigs te melden hebt.

Nog wat andere minder nuttige info:
Ik heb zojuist Windows XP x64 geinstalleerd op mijn PC.
Die blijkt een fractie sneller te zijn in 32-bit... Haalt nu zo'n 430 fps.
De 64-bit versie is nog steeds wat sneller, rond de 450 fps.

Even overklokken naar 3 GHz was ook wel leuk...
32-bit ging naar zo'n 530 fps, en 64-bit naar 560 fps.

Het geheugen werd nauwelijks overgeklokt (van 800 naar 833), dus voor het grootste deel zal de winst komen uit de snellere CPU, wat nog maar eens een indicatie is dat het algoritme zeer zwaar leunt op de cache, en dus behoorlijk efficient te werk gaat.
Wel grappig... toen ik begon, gebruikte ik een Athlon met 256 kb cache, daarin paste het nooit.
In de 4 mb van de Core2 past alles nu makkelijk, daarom gaat ie ook zo enorm hard.
Het verschil tussen de 4600+ en 4800+ zou kunnen zijn dat de 512 kb cache *net* niet genoeg is om altijd alles in de cache te houden, en 1 mb wel.

[ Voor 8% gewijzigd door Verwijderd op 11-11-2006 00:26 ]

[nIghtorius]

Hmm.. nu ik dit zo lees.. ben ik ook maar gaan zitten te kijken hoe je multi-threaded moet gaan programmeren.

Heb zelfs ook iets inelkaar gezet (alleen heb ik hier een single-core CPU) en kan dus het multicore effect niet testen. Dus zet ik 'm hier maar online in de hoop dat iemand met een m-core cpu dit kan gaan testen.

http://www.phibiansoft.net/files/threading.zip

als je het gaat testen liefst met een dataset grootte van 64MB (65536kB) met 100 iteraties. eerst met 1 thread daarna met 2 threads (er is ook een mogelijkheid voor 4 en 8 threads), alleen de eerste twee zijn interessant voor mij.

mijn resultaat met 100 iteraties icm van een 64MB werkset.

1 thread: 10 seconden
2 threads: 10 seconden.

alleen bij 8 threads loopt m'n tijd op naar 11 seconden. (dus toch behoorlijk efficient voor Windows XP) (hou er rekening mee dat ik een singlecore Athlon64 3500+ heb)

Dit is m'n eerste stap in meerdere threads te gebruiken om één enkele (zware) taak te vervullen. Kan zijn dat het helemaal niet werkt op een multicore. Maar dat kan ik inzien.

je kunt proberen om de werkset op 1MB te zetten (om in de cache van een core2duo te blijven zitten) met veel iteraties (1000).

[needless to say]

die 10 seconden zijn wel lang...

Op mijn 4600+ (2.4GHz ipv jouw 2.2GHz) is met 1 thread 6 seconden. Met 2 threads 5 seconden.

[Aapiethaaap]

Ik snap niet wat je deed maar dat je concludeert dat ik met mijn core 2 duo de goede keuze heb gemaakt ben ik al lang blij

[BiG-GuY]

Iemand enig idee hoe je codecs als XviD en MP3 kan forceren om meerdere cores te gebruiken bij encoding? Ik heb namelijk een AMD64 X2 4600+ maar tijdens encoding pakt die maar 50% totaal... ookal heb ik bij XviD ingesteld dat die 2 threads moet gebruiken... vergeet ik nog iets? of wordt DualCore nog niet goed ondersteund bij die codecs?

[Daan®]

AMD Athlon 3700+ @ 2700Mhz, 7900GT (560/1820)

Fire: ~185 fps
Fire Multithread: ~130 fps
Fire Multithread2: ~170 fps

De waardes vallen mij niet tegen als ik ze vergelijk met wat reeds eerder in het topic gepost is.

[Abbadon]

nIghtorius schreef op zaterdag 11 november 2006 @ 17:25:


Heb zelfs ook iets inelkaar gezet (alleen heb ik hier een single-core CPU) en kan dus het multicore effect niet testen. Dus zet ik 'm hier maar online in de hoop dat iemand met een m-core cpu dit kan gaan testen.

http://www.phibiansoft.net/files/threading.zip

als je het gaat testen liefst met een dataset grootte van 64MB (65536kB) met 100 iteraties. eerst met 1 thread daarna met 2 threads (er is ook een mogelijkheid voor 4 en 8 threads), alleen de eerste twee zijn interessant voor mij.

Wazig, met vier threads doet hij het hier in 3 seconden, met twee threads in 4 seconden

Meerdere malen gedraaid op twee Woodcrests 2.66GHz, telkens zelfde resultaat.

Als ik de thread van ddbruijn wil draaien krijg ik een foutmelding: the application failed to start because the application configuration is incorrect (Win XP x64).

[Verwijderd]

Abaddon: je moet dan de VC++ redist installeren.
Zie de link in m'n eerste post, dat is de 32-bit versie.
Onderaan die pagina staat de link naar de 64-bit versie.
Volgens mij heb je de 32-bit versie nodig als je in Windows x64 de 32-bit versies wilt draaien (alleen de laatste Fire64.exe is 64-bit, de rest niet).

[ Voor 31% gewijzigd door Verwijderd op 17-11-2006 22:55 ]

[Thandor]

Interessant om te lezen dit. Helaas ben ik geen programmeur en zullen een aantal zaken ietwat 'vaag' blijven. Ik zal hierbij resultaten geven van een Intel Pentium D 920 'ES' welke z'n werk op 2,94GHz doet met een MP van 14x:

Fire
Programma	FPS	Bevindingen in 'Task Manager'
Fire	~120	Beide cores namen ~25% voor hun rekening. Core0 lijkt iets meer te doen dan Core1)
Fire-Multithread	~115	80% á 90% CPU waarbij Core0 zwaarder belast was dan Core1.
Fire-Multithread2	~179	90% á 93%
FireNew
Fire32	~213 FPS	89% á 91% voor hun rekening. Core1 lijkt iets meer te doen dan Core0. Andersom dan bij de andere test.)

Dit alles met een ATi Radeon X800 en een ietwat gare Microsoft Windows XP SP2 installatie.
_{Enkel bij 'Fire.exe' krijg ik te zien hoeveel FPS ik had. Bij de overige heb ik ongv. het gemiddelde geschat a.d.v. de FPS in de titelbalk.}

Verwijderd schreef op woensdag 08 november 2006 @ 16:43:
Overklokken blijkt prima te werken... 12% meer kloksnelheid is ook 12% meer prestaties. Beter dan dat kan niet
MHz-mythe strikes again.

Let wel op: Bij het overclocken kun je geen extra onderdelen in een processor maken. Het is dus logisch dat een hogere klokfrequentie meer prestaties zal geven.

Als ik in een Intel Pentium D een 'Advanced Smart Cache' kon overclocken zou de processor zonder MHz verhoging ook sneller kunnen zijn.

[Verwijderd]

Thandor schreef op vrijdag 17 november 2006 @ 23:56:
Let wel op: Bij het overclocken kun je geen extra onderdelen in een processor maken. Het is dus logisch dat een hogere klokfrequentie meer prestaties zal geven.

Het ging me vooral om de mate waarin de prestaties toenamen. Eigenlijk exact evenredig met de toename van de kloksnelheid. Bij mijn code zorgt de tweede core duidelijk niet voor 100% extra prestaties, meer cores schalen duidelijk niet lineair.
Op jouw Pentium D haal je zo'n 50% meer prestaties uit de tweede core.
Vandaar dat het in principe nog steeds beter zou zijn als de kloksnelheid omhoog blijft gaan. Multicore is leuk, maar is zeker geen vervanging voor hoge kloksnelheden. Hooguit een toevoeging op.

[BalusC]

• Dual Xeon 3,06GHz met HyperThreading (4 threads max)
• 2GB Corsair Dual Channel PC2100 @ 2-2-2-5
• GeForce FX 5700 Ultra @ default (475/950)

Fire: 119fps, verbruikt ~25% van 4 threads.
Fire-Multithread: fluctueert tussen 90 en 100fps, verbruikt ~40% van 4 threads.
Fire-Multithread2: fluctueert erg sterk tussen 110 en 170fps, verbruikt ~40% van 4 threads.
Fire32: fluctueert erg sterk tussen 100 en 180fps, verbruikt ~40% van 4 threads.

Het lijkt erop dat de multithreaded versies deze programmaatjes geen voordeel kunnen trekken uit HyperThreading. Zijn alle threads min of meer identiek?

[Abbadon]

Verwijderd schreef op vrijdag 17 november 2006 @ 22:49:
Abaddon: je moet dan de VC++ redist installeren.
Zie de link in m'n eerste post, dat is de 32-bit versie.
Onderaan die pagina staat de link naar de 64-bit versie.
Volgens mij heb je de 32-bit versie nodig als je in Windows x64 de 32-bit versies wilt draaien (alleen de laatste Fire64.exe is 64-bit, de rest niet).

Ja, maar met VC++ krijg ik dan nog dezelfde foutmelding bij de 64bits versie. De 32bits kan ik wel draaien (uit FireNew.rar) en ik kan je een leuke ervaring delen. Wanneer ik 'm draai op m'n dual dualcore Xeon 5150 krijg ik ~240FPS, niet bijster veel dus. Maar stel ik de affiniteit in op cpu2 en cpu3 in plaats van cpu0, 1, 2 en 3 (kan on-the-fly) dan stijgt het aantal FPS naar 450! Met de affiniteit zorg ik ervoor dat het proces op dezelfde dualcore blijft draaien en hij dus niet hoeft te communiceren met de andere dualcore, dat scheelt dus behoorlijk wat en past dus ook prima in jouw verhaal.

Daarnaast heb ik nog eens tweemaal Fire32.exe gestart, dit leverde in beide gevallen ~190 op. Met cpu affiniteit ingesteld (twee cpu's voor elk Fire32 proces) kwam ik op ~210 voor elk proces. De cpu load was dan maximaal 75%.

[edit]
Grafische kaart is ATI X1900XT (wel iets underclocked helaas, nml. 600/650MHz voor core/mem)

[ Voor 3% gewijzigd door Abbadon op 18-11-2006 09:43 ]

[Verwijderd]

BalusC schreef op zaterdag 18 november 2006 @ 09:36:
Het lijkt erop dat de multithreaded versies deze programmaatjes geen voordeel kunnen trekken uit HyperThreading. Zijn alle threads min of meer identiek?

Met een dubbele Xeon zal dat niet lukken nee, want hij heeft maar 2 threads.
De threads zijn min of meer identiek.
Ik zal een versie maken waar het aantal threads op te geven is. Als het goed is, moet hij met 4 threads dan een stukje harder gaan. Met een enkele P4 HT ging hij ook iets harder met de multithreaded versies.

[Verwijderd]

Ik heb de 32-bit versie geupdate: http://scali.eu.org/~bohemiq/FireNew.rar

Je kunt nu het aantal threads kiezen onderin het startscherm.
Bij het kiezen van 1 thread heb je min of meer de optimale code voor een singlecore-systeem. Deze gebruikt nu ook het laatste algoritme, en is daardoor ook nog een stukje sneller dan eerst.

Ik haal nu zo'n 250 fps met 1 thread en 415 fps met 2 threads. Met meer threads zakt het langzaam maar zeker in... Hoewel het bij een drukbezet systeem juist een voordeel blijkt. Als je veel threads gebruikt, sta je minder CPU-tijd af aan andere processen, en blijven de prestaties wat stabieler.

Ik ben benieuwd wat bovengenoemde systemen doen met 4 threads...

Ik heb ook een extra functie gemaakt om de snelheid van de videokaart te testen.
Druk op 'm' om het genereren van het volume te onderbreken. Dan tekent hij steeds het laatst berekende volume, en doet de CPU verder zo goed als niks. Dit is een aardige test om te zien hoe zwaar de videokaart het ongeveer heeft.
Ik haal zelf zo'n 1200 fps op die manier, dus de videokaart kan nog een heel stuk sneller dan de 415 fps die de CPU eruit weet te persen, en zal geen grote rol van betekenis hebben in de totale score.
1200 fps betekent dus dat de GPU minder dan een milliseconde nodig heeft om een scherm te tekenen.
Op 415 fps heeft de CPU zo'n 2.4 ms nodig om een scherm te berekenen.
Aangezien CPU en GPU elkaar ook nog deels overlappen, maakt de GPU dus niet zo heel veel uit.
Misschien dat de dual dualcore Xeon nu over de 600 fps kan komen met 4 threads, dan gaat langzaam maar zeker de GPU een grotere rol spelen.
Hoewel, ik zeg wel GPU, maar eigenlijk is het vooral de driver voor de GPU, dus eigenlijk is het ook CPU-tijd.

Ik zal ook de FPS-timer nog eens onder handen nemen, want dat kan preciezer en duidelijker.

[ Voor 48% gewijzigd door Verwijderd op 18-11-2006 12:52 ]

[MOmax]

Dit nieuwe fire werkt hier niet. P4 Northwoord HT @ 3.06 Ghz.

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

[Verwijderd]

VC++ redist installeren, zie eerste post

[Verwijderd]

Een update met betere frametellers: http://scali.eu.org/~bohemiq/FireNew.rar

Hij berekent nu de gemiddelde framerate over een halve seconde, en houdt de minimum en maximum framerate bij.
De precisie is nu een stuk beter, vooral bij hoge framerates. En het is wat makkelijker af te lezen.

[MOmax]

OK, had de posts beter moeten lezen.

De resultaten van een P4 Northwood 3,06 GHz HT icm een Quadro 900XGL:

1 thread: max 124 FPS
2 threads: max 99 FPS

Met de optie "m": is het 371 resp. 357.

[needless to say]

Ik heb die nieuwe versie eventjes gedraaid:

1 thread: ongeveer 205 fps, min: 191.3, max: 236.3
2 threads: ongeveer 265 fps, min: 249.5, max: 281.7

met de optie m: hij verspringt steeds van ongeveer 1400 naar ongeveer 1780 met als maximum 1819.

Dat is dus de 32-bit versie in XP met een X2 4600+ S939@stock.

[Verwijderd]

Okee, bij MOMax zien we tekenen dat de videokaart ook mee gaat spelen.
Dat was de reden waarom ik oorspronkelijk voor het eerste algoritme koos. Daar is het voor de videokaart niet minder efficient als je meer threads gebruikt.
Maar dat probleem treedt bij een moderne GeForce of Radeon veel minder snel op dan ik dacht.

[Verwijderd]

Maar ik zou nog steeds graag mensen zien met 2 of meer CPUs

[Verwijderd]

Een resultaat van een QX6700: zo'n 525 fps gemiddeld, 536 max, met 4 threads.
Schaalt dus nog niet zo heel geweldig door, maar toch...

[ Voor 3% gewijzigd door Verwijderd op 22-11-2006 19:34 ]

[wortelsoft]

Opteron 165 @ 2,26 GHz
Asus 7600GT
2 GB mem

fire: ~155 FPS
fire32 ~285 FPS
fire-multithread 146 FPS
fire-multithread2 ~220

[Verwijderd]

op welke resolutie moet je dat meten ?

[Verwijderd]

Gewoon standaard windowed mode.
Het is om de CPU te testen, videokaart boeit niet.

Wat wel interessant is, is het aantal threads varieren... 1 thread, 2 threads... 4 threads... Zeker voor mensen die 4 of meer cores hebben.

[Verwijderd]

test 1 153fps gemiddelt
test 2 132fps
test 3 186fps

alles zo aangeklikt zoals in rar file (niks aan gepast)
even verder testen

de proc is
amd athlon 64 x2 3800@2,4g mem bus op 166@206 clus 3 (zeer goed koop) deulchannel

[ Voor 27% gewijzigd door Verwijderd op 02-12-2006 23:19 ]

[Verwijderd]

test1 159fps
test2 144fps
test2 224fps

proc amd athlon 64 x2 3800+@ 2,5g mem op 166bus@216 clus3 deulchannel


nog een test
test1 166fps
test2 148fps
test3 232fps
test4 fire32 273pfs

proc amd athlon 64 x2 3800+@ 2,6g mem op 166bus@226bus clu3

[ Voor 44% gewijzigd door Verwijderd op 03-12-2006 00:21 ]

[Dj-sannieboy]

Fire: 112 FPS
Fire-Multithread: 73 FPS
Fire-Multithread2: 93 FPS
Fire32: Min: 136 FPS gemiddeld: 140 FPS Max: 146 FPS

Specs: AMD Atlhon 3000+ @ 1980MHz
Asus V9999/TD (400/874)

FPS zijn gemiddeld met standaard instellingen.

[ Voor 2% gewijzigd door Dj-sannieboy op 02-12-2006 23:31 . Reden: MHz iets te hoog ]

[maratropa]

1 thread 320 fps avg
2 threads 530 fps avg
3 threads 430 fps avg
4 threads 460 fps avg (lijkt weer wat hoger iig dan met 3)

Met de M optie

1 thread 1400 fps avg
2 threads 1450+ fps avg, scheelt niet heel veel. (lijkt me logisch ook toch)

Core 2 duo 6600 op 3,2ghz

[ Voor 52% gewijzigd door maratropa op 02-12-2006 23:45 ]

[Verwijderd]

Fire: 120 FPS
Fire-Multithread: 155 FPS
Fire-Multithread2: 170 FPS
Fire32 (1 thread): 145 FPS
Fire32 (2 threads): 215 FPS

Dit met een Core 2 Duo T5500 (1.66GHz)

[ Voor 13% gewijzigd door Verwijderd op 03-12-2006 00:25 ]

[Verwijderd]

gladiool schreef op zaterdag 02 december 2006 @ 23:33:
4 threads 460 fps avg (lijkt weer wat hoger iig dan met 3)

Ja, was me ook opgevallen... zal wel te maken hebben met het feit dat het lastig is om een oneven aantal threads goed te verdelen over een even aantal cores.

2 threads 1450+ fps avg, scheelt niet heel veel. (lijkt me logisch ook toch)

Eigenlijk zou het logischer zijn als 2 threads trager zijn... Iedere extra thread levert namelijk een extra mesh op, en dat is een extra teken-operatie die de GPU uit moet voeren, dus meer overhead (vandaar dat ik daar in eerste instantie vanaf wou zien... de resultaten met de Quadro geven ook aan waarom...).
Maar het zal er wel mee te maken hebben dat het allemaal nogal random is, en het hangt er dus vanaf wanneer je hem stilzet. Misschien dat er bij die versie met 2 threads toevallig weinig triangles waren, en bij de versie met 1 thread juist veel, toen je hem stilzette... Maar dat is gerommel in de marge, en is niet zo interessant. De functie dient vooral om een idee te krijgen van hoe snel de tekenopdrachten afgehandeld worden... Dan kun je zien in hoeverre de GPU invloed heeft op de totale framerate... In dit geval dus niet zo heel veel.
Je haalt ongeveer 1450 fps... dat betekent dus dat je 1000/1450 = ~0.7 ms doet over het tekenen van een frame.
Met CPU erbij is het zo'n 530 fps, dan heb je dus 1000/530 = ~1.9 ms nodig voor een frame.
Daarvan is dus zeker 1.2 ms besteed aan het multithreading algoritme. Bijna 2/3 dus.

[Verwijderd]

een kleine test

gaat over de htt bus die we bij overklokken verlagen
Deze keer word deze niet verlaagt maar vast gezet op 5x
amd x2 3800@2200mhz mem op 220mhz clus3 dualchannel

test1 141
test2 134
test3 204
test4 32 239

ik ga langzaam de bus verhogen met htt 5x
deze zet ik hier onder
amd athlon 64 x2 3800+@2,4g mem 166bus@206 clus3
htt op 5x vast
test1 156
test2 141
test3 224
test4 32 263

proc amd athlon 64 x2 3800+@ 2,5g mem op 166bus@216 clus3 deulchannel htt 4x
test1 159fps
test2 144fps
test3 224fps

zoals je kan zien is de htt bus erg belangrijk omdat gewoon 100mhz per core schilt voor de zelfde testen.

[ Voor 34% gewijzigd door Verwijderd op 03-12-2006 20:24 ]

[Verwijderd]

Is er trouwens iemand die Windows x64 draait op een Athlon X2 of FX (of Opteron voor mijn part)?
Ik zou graag zien hoeveel sneller Fire64 daar is, vergeleken met Fire32.
Op m'n E6600 merk ik nauwelijks verschil (iets van 430 om 440 fps), maar op een Pentium D 950 is het verschil behoorlijk (zo'n 360 om 420 fps).
Ik ben benieuwd of de Athlon ook zo'n grote sprong maakt in 64-bit.

[empheron]

Op mijn C2D - T7200 met X1600 (zie specs)

Fire32

1 thread 209 avg 190 min 211 max
2 threads 350 avg 329 min 358 max
3 threads 275 avg 241 min 279 max
4 threads 297 avg 289 min 304 max

Heb overigens niet de moeite genomen om achtergrond meuk uit te schakelen... Mag niet veel uitmaken.

[Verwijderd]

Kom op jongens... Iemand met een Athlon of Opteron en Windows x64? Ik weet dat jullie er zijn!
En mensen met multi-CPU-opstellingen?

Bij voorbaat dank.

[peke]

Even een opmerking over de P4.

..."Een cpu van hoge pieken en diepe dalen"...

Dat klopt wel, en dat komt door het fundamentele slechte ontwerp van de Prescott.
Bij weinig branches (decodering bvb) een dikke performance en bij games (veel branches) een dieptepunt.
Met een 31 stappen pipeline heb je nu eenmaal een veel te grote penalty bij een branch misprediction.
De Northwoord had hier veel minder last van met een 20 stappen pipeline.
Ik vond de P4 een prima cpu tem de Northwood.

[Dj-sannieboy]

Eens kijken wat hij doet met een Opteron 170 @ 2400MHz..

Fire32-x87: Gemiddeld 290FPS
Fire32: 275FPS
Standaart instellingen, 2 treads...

hier nog even m'n oude test tevoorschijn gehaald.

Fire32: 140 FPS gemiddeld

Specs: AMD Atlhon 3000+ @ 1980MHz
Asus V9999/TD

[ Voor 32% gewijzigd door Dj-sannieboy op 18-12-2006 20:07 ]

[Verwijderd]

Volgens mij klopt dat van geen kant.
De Prescott heeft wel 31 stages, maar als ik het goed heb, heeft de Northwood er ook al 28. Dat getal van 20 is wat je krijgt als je het deel van de tracecache niet meerekent, maar dat is bij de Prescott wel gedaan, anders kom je nooit op de 31 uit.
Verder zou je zelf wel slim genoeg moeten zijn om de conclusie te trekken dat ze nooit zo veel kunnen schelen, als je benchmarks van Northwood en Prescott naast elkaar legt. De verschillen zijn erg klein. Als de pipeline echt ruim 50% langer was, zou je eerder verschillen zien als Core2 Duo vs P4.
Als je de Prescott dus fundamenteel slecht vindt, moet dat voor de Northwood ook gelden, de Prescott is immers slechts een doorontwikkeling. De basis is grotendeels gelijk, en ook het prestatieniveau.

[MexxT]

P4 (540) 3,2 @ 3,911 (1MB dus)
XFX 7600GT (XXX) @ stock 590/800(x2) = 6,6k 3dmark05

Fire: 175FPS
Fire-Multithread: 140FPS
Fire-Multithread2: 162FPS

XFX 7600GT @ 735/860(x2) = 7,5k 3dmark05

Fire: 180FPS
Fire-Multithread: 140FPS
Fire-Multithread2: 165FPS
Fire32: 220FPS
Fire32-x87: 213FPS

Grafiche kaart bepaalt dus ook nog wel wat..
Met een 8800GTX zal het verschil dan toch nog wel een enorm stuk groter zijn..

[ Voor 4% gewijzigd door MexxT op 18-12-2006 20:34 ]

[Verwijderd]

Dj-sannieboy schreef op maandag 18 december 2006 @ 20:05:
Eens kijken wat hij doet met een Opteron 170 @ 2400MHz..

Fire32-x87: Gemiddeld 290FPS
Fire32: 275FPS
Standaart instellingen, 2 treads...

Grappig... dat zou betekenen dat een Athlon/Opteron trager is met SSE dan met x87, terwijl de P4 en C2D blijkbaar sneller zijn met SSE.
Geen wonder dat Countess niets zei over z'n testresultaten... Als ras-AMD-fanboy wilde hij hier natuurlijk geen ruchtbaarheid aan geven.

[ Voor 14% gewijzigd door Verwijderd op 18-12-2006 21:08 ]

[kutkip]

dual Xeon 2.8ghz + HT 'Nocona'
x800xtpe agp8x
Windows XP 32bit

fire 32

1 tread 133 fps
2 treads 175 fps
3 treads 134 fps
4 treads 125 fps

fire 32 x87

1 tread 131 fps
2 treads 186 fps
3 treads 133 fps
4 treads 120 fps

edit -> resultaten na 3 testen

[ Voor 8% gewijzigd door kutkip op 18-12-2006 23:56 ]

[Verwijderd]

Verwijderd schreef op maandag 18 december 2006 @ 20:48:
[...]


Grappig... dat zou betekenen dat een Athlon/Opteron trager is met SSE dan met x87, terwijl de P4 en C2D blijkbaar sneller zijn met SSE.
Geen wonder dat Countess niets zei over z'n testresultaten... Als ras-AMD-fanboy wilde hij hier natuurlijk geen ruchtbaarheid aan geven.

dat is bekend dat intel sneller is met sse
weet nog een test dat een intel celeron-d bijna net zo snel was als een amd 64 versie van decoderen van audio

zal de link eens zoeken

gevonden
http://www.xbitlabs.com/a...display/sempron-3000.html

amd sempron 939
amd 64 939
intel celeron-d

[ Voor 10% gewijzigd door Verwijderd op 18-12-2006 23:53 ]

[Verwijderd]

Verwijderd schreef op maandag 18 december 2006 @ 23:51:
[...]
dat is bekend dat intel sneller is met sse

Nee, daar gaat het niet om.
Het gaat erom dat AMD trager wordt met SSE dan zonder.
Terwijl Intel sneller wordt met SSE.
Dat Intel sneller is met SSE dan AMD, staat daar los van.

Zo zie je maar weer hoe lastig het is om software te maken die op alle systemen optimaal loopt.
In dit geval neem ik het AMD enigszins kwalijk. Als je SSE aan je processor toevoegt, moet een programmeur er vanuit kunnen gaan dat die SSE dan ook zodanig degelijk is dat het ook sneller is.
Nu moet je niet alleen rekening houden met wel/geen SSE, maar ook weer met snelle/trage SSE... Doe het er dan niet op

[Verwijderd]

Verwijderd schreef op maandag 18 december 2006 @ 23:53:
[...]


Nee, daar gaat het niet om.
Het gaat erom dat AMD trager wordt met SSE dan zonder.
Terwijl Intel sneller wordt met SSE.
Dat Intel sneller is met SSE dan AMD, staat daar los van.

Zo zie je maar weer hoe lastig het is om software te maken die op alle systemen optimaal loopt.
In dit geval neem ik het AMD enigszins kwalijk. Als je SSE aan je processor toevoegt, moet een programmeur er vanuit kunnen gaan dat die SSE dan ook zodanig degelijk is dat het ook sneller is.
Nu moet je niet alleen rekening houden met wel/geen SSE, maar ook weer met snelle/trage SSE... Doe het er dan niet op

Eigelijk wel grappige
Vga drivers hebben sse 3d-now en enzz ingebakken zodat de cpu beter de vga kan aansturen.

Helaas was bij ati kaarten sse uitgeschakelt op amd hardware.
Je zal zeggen dat ati het wist? (eerste amd-xp proc's)

[Verwijderd]

Ja... en volgens Countess werd alles met SSE 2 tot 5 keer sneller dan zonder
Sommige mensen geloven ook ieder marketingpraatje.

Maar het is wel een reeel probleem... Ik heb zelf alleen Intel-systemen met SSE2 thuis staan (Celeron, Pentium 4 en Core2 Duo), en ik was in de veronderstelling dat SSE gewoon altijd sneller was voor mijn programma, omdat dat op al mijn systemen zo was.
Ik had die x87-versie alleen gemaakt om Countess te laten zien dat SSE niet zo enorm veel sneller is... Maar dat het op Athlons en Opterons zelfs trager is, had ik niet verwacht... daar kom ik nu bij toeval achter.
Tsja, echt dramatisch is het ook weer niet... Het gat met de Core2 Duo is nog steeds gigantisch groot. Maar ik weet nu dus wel dat ik niet zomaar een enkele binary kan maken met SSE/SSE2-support, omdat ik weet dat dat op een AMD-systeem niet sneller is.
Jammer voor AMD-gebruikers, maar er is voor mij geen eenvoudige oplossing voor dit probleem. De compiler kan wel x87 en SSE-code in 1 binary stoppen, maar hij zal dan altijd voor de SSE-versie kiezen op een systeem dat dat ondersteunt, omdat ook de compiler ervanuitgaat dat dat sneller is.
Het is niet mogelijk om de gebruiker die keuze te laten maken.
Ik ben niet van plan om dat zelf in te gaan bouwen.

[needless to say]

Ik heb die x87-versie ook eens geprobeerd. Eerlijk gezegd vind ik niet echt verschillen tov de SSE-versie. Het fluctueert op zich te veel om eenduidig te kunnen zeggen dat de ene versie sneller is dan de ander.

Ik heb hier een paar mooie C-programma's die geoptimaliseerd zijn voor een Itanium-server met 4 processoren en die bijna 100% meeschalen. Zo is er een programma om 2 grote matrices te vermenigvuldigen. Met de 4 CPU's in gebruik gaf dit een speedup van ongeveer 3,91 tov 1 CPU.(enkel optimalisatie van het programma aan de grootte van de cache bij gebruik van 1 CPU gaf wel een leuke speedup van 10,89) Ik zou die programma's wel moeten aanpassen om op X86 te kunnen draaien en heb nu even geen tijd hiervoor (thesis + examens). Wanneer ik na dit alles mij deze thread nog herinner, dan zal ik proberen deze versies aan te passen en online te plaatsen.

Als je wil dat je programma goed opschaalt met meerdere cores, moet je wel rekening houden met de cache-grootte per core.

[ Voor 67% gewijzigd door needless to say op 19-12-2006 01:32 ]

[Verwijderd]

needless to say schreef op dinsdag 19 december 2006 @ 01:23:
Ik heb die x87-versie ook eens geprobeerd. Eerlijk gezegd vind ik niet echt verschillen tov de SSE-versie. Het fluctueert op zich te veel om eenduidig te kunnen zeggen dat de ene versie sneller is dan de ander.

Als ik gemiddelden van 290 vs 275 zie, is er toch duidelijk een verschil... en zeker niet ten gunste van SSE.

Als je wil dat je programma goed opschaalt met meerdere cores, moet je wel rekening houden met de cache-grootte per core.

Tsja, zo simpel ligt het natuurlijk niet altijd. Dit algoritme leent zich er niet voor om zomaar rekening te houden met de cachegrootte. De hoeveelheid geheugen die je nodig hebt, hangt af van de grootte van de grid die je gebruikt. Je kunt wel een kleinere grid nemen, maar dan is dus de resolutie lager, en heb je niet meer hetzelfde resultaat.
Dit is dus geen triviaal algoritme om efficient te multithreaden, zoals dat voor zoveel algoritmen geldt. 100% schalen is dus een utopie.

De moeilijkheid zit hem er deels in dat er veel te winnen valt door gebruik te maken van eerder berekende resultaten. Veel triangles in de mesh gebruiken immers dezelfde vertices, en ook de normaalvectors kunnen aan de hand van dezelfde tussenresultaten berekend worden.
Waarschijnlijk is er een punt waarbij je dit idee beter los kunt laten, en in plaats daarvan de cores gewoon alles apart te laten berekenen. Maar waar dat omslagpunt ligt, is lastig te bepalen.
Ik kan wel eens een versie maken waarbij die optimalisaties er compleet uit zijn, zodat de cores elkaar helemaal niet meer in de weg zitten.
Eens kijken of het dan beter schaalt... en zo ja, wanneer dit algoritme ongeveer het huidige algoritme in zou kunnen gaan halen.

Edit: Nu ik naar de code kijk, zie ik dat ik de code van de normaalvectors toch al uitgezet had, en de caching van vertices per-thread heb gemaakt... Dus de cores zouden elkaar toch al helemaal niet meer in de weg moeten zitten. Al het gedeelde geheugen is read-only.
Dan denk ik eigenlijk niet dat het nog nut heeft om die andere caching eruit te halen.
Op mijn Core2 Duo is het iig een waardeloos idee
Framerate zakt meteen van zo'n 430 fps naar 205 fps zonder het caching-algoritme.

Ik vermoed dat het op een quadcore niet zo goed schaalt omdat de limieten van geheugen of PCI-e bus een rol gaan spelen. Misschien dat het daar interessant is om met overklokken van videogeheugen en GPU te experimenteren.

Zo te zien schaalt het op die dual Xeon wel gewoon netjes... Het ligt dus niet zozeer aan het feit dat het alleen op een single-die CPU efficient is.

[ Voor 19% gewijzigd door Verwijderd op 19-12-2006 09:11 ]

[InfinityG35]

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

[ Voor 30% gewijzigd door InfinityG35 op 19-12-2006 20:13 ]

[Atmosphere]

FIRE: rond de 142fps met een A64 3700+ @ 2,3Ghz (1MB l2-cache) en Ati X800 XT (std)

Wat ik bedoelde op tweakers is overigens een minibench zonder GFX impact... dus win32 console (ofzo)
Dit scheelt je een hoop overhead. (oh jah en moest gewoon vriendelijk blijven )

En eigenlijk denk ik dat toch meer tweakers Linux AMD-64 hebben draaien dan WinXP-64. 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???

Misschien dat het je nu wat duidelijker is wat ik bedoel
Hoe dan ook gewoon testen was de bedoeling toch ... eigenlijk moet je niet in gaan op discussies rond wel geen SSE .. sommige routines lenen zich niet voor scalablity, dit zijn vaak routines die gebonden zijn aan het resultaat van zijn voorganger... Er kan dus eigenlijk niet voorspeld worden wat de uitkomst is... In dit geval is het gebruik van SSE en of multicore binnen die routine niet goed mogelijk.
Kom op: just ignore... Leuke gepraat maar iedereen is bezig met zout op kleine misverstanden leggen (evenals jij) schiet niet op de tweaker.

Verders .. leuke proggie maar een gamma insteling would be nice en FPS-stats in fullscreen eigenlijk ook

[Verwijderd]

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 )

[Verwijderd]

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.

[Verwijderd]

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 Verwijderd 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]

Verwijderd 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.

[Verwijderd]

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.

[Verwijderd]

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 Verwijderd 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.

[Verwijderd]

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 Verwijderd op 01-05-2007 21:22 ]

[Verwijderd]

Verwijderd 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

[Verwijderd]

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.

[Verwijderd]

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 Verwijderd op 05-05-2007 12:21 ]

[Verwijderd]

Verwijderd 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 Verwijderd op 05-05-2007 13:02 ]

[Verwijderd]

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

[Verwijderd]

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.

[Verwijderd]

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?

Verwijderd 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 Verwijderd op 07-05-2007 13:32 ]

[Verwijderd]

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.

[Verwijderd]

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.

[Verwijderd]

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 Verwijderd op 08-05-2007 11:12 ]

[Verwijderd]

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

[Verwijderd]

nog steeds geens success en nog steeds dezelfde foutmelding

[Verwijderd]

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?

[Verwijderd]

Verwijderd 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...

[Verwijderd]

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 Verwijderd op 09-05-2007 08:48 ]

[rapture]

Verwijderd 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.

[Verwijderd]

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

[Verwijderd]

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 Verwijderd op 09-05-2007 11:02 ]

[Verwijderd]

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

newees lemme know

[Verwijderd]

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?

[Verwijderd]

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 Verwijderd 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.

[Verwijderd]

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.

[Verwijderd]

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