Mijn voorlopige bevindingen over multicore-processing

[Anoniem: 133470]

Omdat ik sinds kort een Core2 Duo heb, ben ik eens aan het optimaliseren gegaan voor multicore in 1 van m'n hobby-projecten.
Ik heb gekozen voor 1 van de zwaarste CPU-routines die ik gemaakt heb, namelijk het 3d vuur-effect, met het MarchingCubes-algoritme.

Mijn eerste poging was om het algo precies hetzelfde te laten werken als voor single-core, zodat het een optimale vertexbuffer voor de videokaart op zou leveren.
Dat had als nadeel dat de threads iets meer geheugen moesten delen.
Op de Core2 Duo zag het er goed uit, ruim 30% sneller dan de single-core versie.
Maar toen ik het op een Athlon X2 ging draaien, werd het niet sneller.
Op een Pentium D werd het zelfs iets langzamer.

Back to the drawing board dus... Een alternatief idee dat ik had was om iedere thread z'n eigen vertexbuffer te laten genereren. Dat betekende wel wat meer werk voor de GPU, maar als het de CPUs sneller kan laten werken, heft dat elkaar misschien toch weer op.
Hoewel ik het niet verwachtte, bleek dit op m'n Core2 Duo toch nog een fractie sneller te zijn, nu rond de 37-38%. Ik denk dat het hem hier vooral zit in het feit dat ik wat kopieer-operaties uitspaar, doordat ik de vertices niet meer hoef samen te voegen in 1 buffer.
En de magie begon nu ook te gebeuren op de Athlon X2 en de Pentium D.
Op een X2 4400+ ging het er zo'n 40% op vooruit.
Een Pentium D 805 ging zelfs met 47% vooruit.

Toen heb ik ook nog even een Pentium 4 HT erbij gehaald... en dat was ook interessant. Het nieuwe algoritme zorgde daar ook nog voor een paar procentjes winst. Maar vooral opvallend was dat daar de oude multithreaded versie niet trager werd. Je zou verwachten dat als twee echte cores het er lastig mee hebben, dat een enkele core met HT het nog drukker krijgt.
Wat de Pentium 4 gemeen heeft met de Core2 Duo is dat ze beiden een enkele L2-cache hebben, die voor beide threads gebruikt wordt.
Ik denk dat dat het grote voordeel is ten opzichte van de Pentium D en Athlon X2.
Eerst dacht ik dat het misschien ook met de bandbreedte te maken had... dat de singlethreaded versie al zo hongerig was dat er voor een tweede thread geen bandbreedte meer over was om nog sneller te gaan. Maar aangezien de Pentium HT niet langzamer is, lijkt me dat niet het geval... hij gebruikt inderdaad meer bandbreedte, omdat hij aan het eind de vertexbuffers samenvoegt... In principe is het multithreaded deel van het algoritme dan wel sneller, omdat dit extra werk 'gratis' is. Dus die extra bandbreedte is er.

Mijn conclusie is dus dat shared L2-cache erg belangrijk is voor efficient multithreaden. De Athlon X2 en Pentium D hebben dit niet... en hoewel de Athlon X2 op papier efficienter is dan de Pentium D, is het in de praktijk niet zo heel relevant (in dit geval tenminste). Op de Athlon is het nog dermate inefficient dat de single-threaded versie ongeveer even snel is (maar wel met 50% minder CPU-gebruik).
In dit geval kon ik eromheen programmeren, maar dat zal niet altijd kunnen. In die gevallen is de Core2 Duo dan oppermachtig, vanwege de shared L2-cache.

Dus, is de Athlon X2 een beter dualcore-ontwerp dan de Pentium D? Ja.
Is het een goed dualcore-ontwerp? Nee, het is marginaal beter dan de Pentium D in worst case, maar nog steeds niet geweldig... Er zit nog steeds een gat van 40% tussen worst case en best case. De Core2 Duo is in die worst case maar een marginaal langzamer dan in de best case, misschien 5% hooguit.
Dat betekent dus dat de Core2 veel meer mogelijkheden opent tot het optimaliseren van algoritmen voor multithreading.

Hoe ziet de nabije toekomst eruit?
De Kentsfield van Intel is een soort combinatie van Core2 Duo en Pentium D. Per 2 cores heb je dus al die shared L2-cache die in sommige gevallen een groot verschil maakt. De andere cores communiceren dan nog wel via de FSB, maar die sneller dan bij de Pentium D (die al bijna net zo goed werkte als de K8), en is minder vaak nodig.
De K8L heeft geen shared L2-cache, maar L3-cache. Dit zal het probleem van de K8 iets verlichten, maar het zal een stuk langzamer zijn dan shared L2-cache, dus ik denk dat hij het in veel gevallen tegen de Kentsfield moet gaan afleggen bij dit soort algoritmen (zeker omdat ik ook niet verwacht dat de K8L per core sneller zal zijn, omdat de Core2 een indrukwekkende IPC heeft, en ook aardig ver kan schalen qua kloksnelheid).

Tot slot nog even de drie binaries waarmee ik getest heb:
http://scali.eu.org/~bohemiq/Fire.rar

De multithread-versies gebruiken OpenMP... hiervoor moet je de VC++ redist installeren, als je die nog niet hebt:
http://go.microsoft.com/fwlink/?linkid=65127&clcid=0x409

Als iemand een systeem met meer dan 2 cores heeft, lijkt het me wel interessant om een versie te maken die daar gebruik van maakt, om te kijken hoever dit algoritme nu kan schalen (de huidige versie gebruikt maar twee threads, dus zal op een quadcore oid niet sneller zijn).

[Anoniem: 133470]

Niemand die hier iets over op te merken heeft?
Matig hoor

[jj71]

Wat een lang verhaal. Ik heb het niet helemaal gevolgd.

Ik heb nu een Core 2 Duo E6600 (2,4 GHz), en ik heb zelf eens wat zitten knutselen met een multi-threaded programmaatje in C en embedded SSE assembly instructies. Dit programmaatje draait op mijn Core 2 Duo maar liefst zeven keer zo snel als op een 3,0 GHz Pentium 4.

De Core 2 Duo is niet alleen veel sneller omdat 'ie twee threads tegelijkertijd kan uitvoeren op twee cores, maar ook omdat 'ie veel efficiënter is met SSE instructies - de Core 2 Duo kan een 128-bits SSE instructie in één kloktik uitvoeren, de Pentium deed dat in twee kloktikken.

Software zal in de toekomst meer en meer voor dual (of multi) core geoptimaliseerd worden, omdat over een paar jaar iedereen een multi-core processor heeft en omdat single-core processors alleen nog maar in de low-end markt verkocht zullen worden.

Maar zelfs met niet geoptimaliseerde software (die gebruikt maakt van slechts één van de twee cores) is mijn Core 2 Duo over het algemeen sneller dan de Pentium 4 waarmee ik 'm vergelijk.

[Anoniem: 133470]

Zeven keer vind ik wel erg veel hoor.
Dit programma is ongeveer 2x zo snel op mijn Core2 Duo E6600 als op de Pentium 4 3.0 GHz HT waarop ik hem getest heb (zo'n 270 fps tegenover zo'n 140 fps, voor Multithreading2).
Dan denk ik dat er toch ook wel iets scheef zit waarom de P4 zelf ook niet tot z'n optimale prestatieniveau kan komen (denormals misschien? Slechte alignment? Teveel branches?... ik noem maar wat... vaak kun je de code wel omschrijven om dat te ontlopen).

Verder is de Core2 inderdaad sneller met SSE2 per clk, maar de P4 compenseert dat natuurlijk deels door hogere kloksnelheid. In sommige tests is de P4 ook nog steeds sneller dan de Core2 (zie de Whetstone benchmark in Sandra 2007).

Verder denk ik dat de Core2 *juist* met niet-geoptimaliseerde software beter is dan de Pentium 4, omdat ie net als de Athlon een stuk vergeeflijker is. De penalties op een P4 zijn veel hoger, dus als je die niet probeert te vermijden, wordt het al gauw een drama.
De P4 is een processor van hoge pieken en diepe dalen, en dat vond ik eigenlijk ook wel de charme ervan.

[mad_max234]

Ik vind je verhaal ook een beetje langdradig, maar als ik je een beetje kan volgen dan zeg je dat een Pentium D bijna net zo snel is als een Athlon64 X2.

De benchmarks op het www zeggen toch iets heel anders.

Maar ik kan je ook verkeerd begrepen hebben want ik kon je niet altijd even goed volgen.

En wat ik nog mis is de test omgevingvan de systemen? Dat maak ook heelveel uit.

Edit/
Ik heb ook ff je software gedraait en kom met een Athlon64 3700+ @ 3000Mhz op +- 185fps, ik heb verder gewoon alles zo laten staan zoals het staat als je het programatje start.(was met Fire-Multithread2) Heb ook nog utorrent op de achtergrond draaien maar dat zal wel niet zo heel veel schelen.

[ Voor 28% gewijzigd door mad_max234 op 06-11-2006 16:28 ]

[Anoniem: 133470]

mad_max234 schreef op maandag 06 november 2006 @ 16:10:
Ik vind je verhaal ook een beetje langdradig, maar als ik je een beetje kan volgen dan zeg je dat een Pentium D bijna net zo snel is als een Athlon64 X2.

Nee, dat zeg ik niet... het gaat erom hoeveel procent winst ze kunnen halen uit het multithreaden van dit algoritme.
De Athlon X2 is in absolute zin wel sneller, maar de relatieve winst is tot nu toe het grootst gebleken bij een Pentium D 805.
Verder heb ik twee versies gemaakt van het algoritme, waarbij de ene versie op een 'echte' dualcore als de Core2 Duo wel een significante snelheidswinst behaalt, maar op een dual-CPU systeem of fysiek gescheiden cores zoals de Pentium D niet (en zelfs wat trager kan uitvallen). De andere versie boekt op alle typen dualcore/CPU een significante snelheidswinst.
Wat me hierbij dus opviel is dat de Athlon X2 het nauwelijks beter deed dan de Pentium D in het eerste geval, terwijl deze CPU toch vaak geroemd werd als 'native dualcore ontwerp', en de Pentium D een probleem zou hebben met de communicatie via de FSB.

En wat ik nog mis is de test omgevingvan de systemen? Dat maak ook heelveel uit.

Niet echt, want ik vergelijk de systemen niet onderling, ik vergelijk alleen de drie versies van het algoritme op hetzelfde systeem, en bekijk dan de relatieve winst (of verlies) ten opzichte van de singlethreaded versie.

Ik heb ook ff je software gedraait en kom met een Athlon64 3700+ @ 3000Mhz op +- 185fps, ik heb verder gewoon alles zo laten staan zoals het staat als je het programatje start.(was met Fire-Multithread2) Heb ook nog utorrent op de achtergrond draaien maar dat zal wel niet zo heel veel schelen.

Het gaat dus om het verschil... In absolute zin is de Core2 veruit de winnaar (~270 fps voor een E6400... en ook voor een E6600, blijkbaar kan het niet harder vanwege andere hardware)... mede daardoor wint hij ook niet zo veel in multithreading... het geheugen en de videokaart zijn relatief trager, dus wegen zwaarder. Maar het opvallende is dus dat de Core2 Duo als enige dualcore een ruime winst haalt uit het eerste multithreading-algoritme.

[mad_max234]

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

[ Voor 20% gewijzigd door mad_max234 op 06-11-2006 17:19 ]

[Abbadon]

Je trekt nu conclusies op basis van één bepaald proces (in hooguit twee, drie verschillende versies), daar is niks mis mee, maar betrek ze niet op de vraag welke dual core processor nu een beter of efficienter dubbelkernig design heeft

In bepaalde gevallen is een shared L2 cache efficienter, maar beide cores kunnen in gevecht met elkaar raken om de toegang tot het gedeelde L2 cache. Dit hangt ondermeer af van de hoeveelheid data die verwerkt wordt (simultaan lezen en schrijven door beide cores) en of het cache dus erg zwaar belast wordt. Daarnaast verschillen de AMD en Intel cpu's qua ontwerp met als gevolg dat bijvoorbeeld het L2 cache van de Core 2 Duo in een gegeven situatie beduidend minder efficient wordt (b.v. veel gelijktijdge reads en writes door beide core's) waardoor de praktische bandbreedte richting de helft van het maximum haalbare tuimelt terwijl, met dezelfde load/processen, de beide caches in de Athlon X2 nog over de volledige bandbreedte beschikken. De Athlon is dan efficienter, maar omdat de Core 2 Duo van meet af aan met een veel grotere bandbreedte tussen cores en cache start, kan het ook zo zijn dat ondanks de flink afgenomen efficiency de absolute prestaties van de Core 2 Duo caches alsnog beter zijn.

Het hangt dus naast het design ook erg af van wat je er mee doet en wat je precies meet

[mad_max234]

@Abbadon
Het gaat dus alleen om dit stukje software in dit geval.

[ Voor 7% gewijzigd door mad_max234 op 06-11-2006 17:23 ]

[Anoniem: 133470]

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

Ik heb zelf maar een paar resultaten.
Misschien dat het handig is als iedereen zijn resultaten hier post, dan kunnen we ze in een tabelletje gaan onderbrengen.
Voor mij geldt iig:
Core2 Duo E6600 (GeForce 7600GT):
Fire.exe: ~190 fps
Fire-Multithread.exe: ~230 fps
Fire-Multithread2.exe: ~270 fps

Pentium 4 HT 3.0 GHz (Radeon X300):
Fire.exe: ~135 fps
Fire-Multithread.exe: ~135 fps
Fire-Multithread2.exe: ~145 fps

[Anoniem: 133470]

Abbadon schreef op maandag 06 november 2006 @ 17:17:
Je trekt nu conclusies op basis van één bepaald proces (in hooguit twee, drie verschillende versies), daar is niks mis mee, maar betrek ze niet op de vraag welke dual core processor nu een beter of efficienter dubbelkernig design heeft

Het verschil is dus dat de ene versie een array van 256 kb deelt tussen twee cores, en de andere versie niets deelt (tenminste, niets waar geschreven wordt, alleen gelezen).
Dus een aardige testcase voor in hoeverre de communicatie tussen de cores efficient verloopt.

In bepaalde gevallen is een shared L2 cache efficienter, maar beide cores kunnen in gevecht met elkaar raken om de toegang tot het gedeelde L2 cache. Dit hangt ondermeer af van de hoeveelheid data die verwerkt wordt (simultaan lezen en schrijven door beide cores) en of het cache dus erg zwaar belast wordt.

In dat geval zou de eerste versie nooit snel kunnen zijn op een Core2 Duo. Wat dus blijkt is dat het nog steeds significant sneller is (relatief gesproken) dan op een Athlon X2 of Pentium D.
We zien wel dat je iets inlevert tov van een compleet gescheiden algoritme, maar deels is dat ook doordat er een extra kopieerslag nodig is voor het eerste algo. Het verschil is dus maar deels door de mindere efficientie van de L2-cache.

De Athlon is dan efficienter, maar omdat de Core 2 Duo van meet af aan met een veel grotere bandbreedte tussen cores en cache start, kan het ook zo zijn dat ondanks de flink afgenomen efficiency de absolute prestaties van de Core 2 Duo caches alsnog beter zijn.

Dat blijkt nergens uit, want ik heb alleen relatieve getallen genoemd. De Athlon is relatief gezien al veel minder efficient, waardoor hij in het eerste algoritme eigenlijk al helemaal geen winst kan boeken (hoewel je dus wel van 50% naar 100% CPU-gebruk gaat).
Daar komt inderdaad bij dat de Athlon ook in absolute zin een stuk trager is, maar daar ben ik nu niet zo heel erg in geinteresseerd. Het is al langer bekend dat de Core2 gewoon sneller is in bijna iedere situatie.

[dion_b]

Anoniem: 133470 schreef op maandag 06 november 2006 @ 17:31:
[...]


Het verschil is dus dat de ene versie een array van 256 kb deelt tussen twee cores, en de andere versie niets deelt (tenminste, niets waar geschreven wordt, alleen gelezen).
Dus een aardige testcase voor in hoeverre de communicatie tussen de cores efficient verloopt.

Ben je daar wel zo zeker van

256kb is zo weinig (256kb = 32kB) dat het zeker gedeeltelijk in de L1-caches zou kunnen passen , wat dan weer het gedeeld vs niet gedeeld verhaal in gedrang zou kunnen brengen

[Anoniem: 133470]

Ben je daar wel zo zeker van

256kb is zo weinig (256kb = 32kB) dat het zeker gedeeltelijk in de L1-caches zou kunnen passen , wat dan weer het gedeeld vs niet gedeeld verhaal in gedrang zou kunnen brengen

Ik bedoel 256 kilobyte uiteraard.
Verder klopt je logica niet. Het mag dan wel in L1 passen (sowieso ontwerp ik m'n implementatie natuurlijk zodanig dat het zo veel mogelijk van L1 gebruik kan maken), maar op het moment dat core 1 z'n cache update, betekent dat in principe dat het geheugenadres ook geupdate zou moeten zijn.
Dat betekent dus dat de L1 van core 2 ook meteen geupdate moet worden.
In het geval van de Core2 betekent het dat de cacheline via L2 teruggeschreven wordt, en daarna door de L1 van de andere core teruggelezen wordt.

In het geval van de Pentium D en Athlon X2 betekent het dat het naar L2 van de ene core gaat, en van daaraf via de 'externe' bus naar de L2 van de andere core, en uiteindelijk dus ook weer naar L1.

In feite maakt het dus niet zo veel uit of het in L1 past of niet, het moet sowieso gesynchroniseerd worden met de andere core (en zo heel vaak wordt er in mijn algoritme nou ook weer niet geschreven naar een gedeeld stuk). Het is alleen opvallend dat de Athlon X2 hier nauwelijks sneller is dan de Pentium D. De Athlon werd immers geprezen om z'n 'native' dualcore ontwerp, en de Pentium D was maar een 'hackjob'.
De Core2 Duo plaatst dat in een heel ander licht. Dit is wat een 'native' dualcore zou moeten zijn... De Athlon X2 onderscheidt zich dermate weinig van de Pentium D (en dus ook reguliere dual-CPU systemen) dat je qua algoritme-keuze in dezelfde richting moet zoeken, terwijl de Core2 nieuwe mogelijkheden biedt.

[ Voor 3% gewijzigd door Anoniem: 133470 op 06-11-2006 21:02 ]

[Rafe]

Was het niet zo dat de Athlon 64 X2 intern met de andere kern (cache) kon communiceren en dus niet over de externe bus hoefde te gaan itt tot de Pentium D? Zoiets meen ik me te herinneren iig.

Overigens is het maar net waar een architectuur goed in is: in deze review van hardware.info bijvoorbeeld (de E6400, 4200+ en D950 zijn vergelijkbaar qua prijs volgens dat artikel) geeft wisselende resultaten per benchmark, op de pagina die ik net linkte zie je dat PAL DV naar H.264 encoden wel verschil maakt, maar bij audiocompressie (wave naar MP3 met LAME) op pagina 3 zie je dat beide Intels sneller zijn dan de AMD-processor.

[Anoniem: 133470]

Rafe schreef op dinsdag 07 november 2006 @ 00:00:
Was het niet zo dat de Athlon 64 X2 intern met de andere kern (cache) kon communiceren en dus niet over de externe bus hoefde te gaan itt tot de Pentium D? Zoiets meen ik me te herinneren iig.

Dat is wel zo, maar blijkbaar is het niet significant sneller dan de FSB van de Pentium D.
Het is in ieder geval totaal niet vergelijkbaar met een shared L2-cache zoals van de Core2 Duo.
Kortom, flink door marketing opgeblazen.
Ik denk dat de meeste multithreading-algoritmen ook niet specifiek voor multicore-processors geschreven worden, maar gewoon voor multi-CPU, en dan zorg je er wel voor dat je de cache niet misbruikt door 2 of meer cores tegelijk. Het grote voordeel van een multicore-processor is in theorie nou juist dat dit wel zou kunnen, omdat de communicatie veel directer kan. Bij de Athlon komt dit alleen blijkbaar totaal niet uit de verf (AMD zal dat vast beseffen, want de K8L krijgt shared L3-cache).

Overigens is het maar net waar een architectuur goed in is: in deze review van hardware.info bijvoorbeeld (de E6400, 4200+ en D950 zijn vergelijkbaar qua prijs volgens dat artikel) geeft wisselende resultaten per benchmark, op de pagina die ik net linkte zie je dat PAL DV naar H.264 encoden wel verschil maakt, maar bij audiocompressie (wave naar MP3 met LAME) op pagina 3 zie je dat beide Intels sneller zijn dan de AMD-processor.

Dat sowieso, maar dit soort benchmarks vind ik vaak zo nietszeggend, omdat je niet precies weet hoe iets geimplementeerd is.
Je kunt dus wel zien dat de ene CPU sneller is dan de andere, maar je weet niet waarom.
Ik onderzoek dat soort dingen liever zelf, want ik wil m'n eigen code ook zo goed mogelijk laten lopen op alle processors.
Hier kwam ik er dus achter dat je alleen op de Core2 weg komt met het delen van geheugen... de Athlon is ondanks z'n interne bus bij lange na niet snel genoeg om winst te halen uit een dergelijk algoritme.

[Anoniem: 133470]

Intussen heb ik nog wat meer geoptimaliseerd, en heb ik met m'n E6600 de magische 300 fps-grens doorbroken.
Mijn vermoeden was juist, het geheugen was een beperkende factor... de stack om precies te zijn.
Ik had dit vermoeden al omdat de 64-bit versie trager was dan de 32-bit versie.
Door het stack-gebruik terug te dringen, werd het nog een stuk sneller, en is de 64-bit versie weer sneller dan de 32-bit versie, zoals ook zou moeten.
Ik vermoed dat dit stack-gebruik bij meer programma's een probleem is... het komt redelijk vaak voor dat een 64-bit versie iets trager is dan een 32-bit versie (ook bij Athlons en P4s, dus het is niet te verklaren door de micro-op fusion die niet werkt in 64-bit mode op de Core2.... ik denk sowieso dat dat niet uitmaakt, dat is vooral voor legacy-code interessant, en alle 64-bit code is per definitie nieuw).

[needless to say]

X2 4600+ S939
7900GT

fire.exe ~150fps
fire_multithread ~150fps
fire_multithread2 ~200fps

33% sneller dus. Overal de standaardinstellingen gebruikt.

[Anoniem: 133470]

Mooie resultaten die duidelijk aangeven dat de Athlon met het eerste multithreading-algo geen winst boekt. Dat is wat ik bedoel. Je vergooit in principe 50% van je CPU-kracht aan het synchroniseren van je caches. Pas als je dat vermijdt, kan de tweede core echt winst opleveren.

Heeft er ook iemand een dual Opteron of Xeon... of een Pentium D?
Dat zouden ook wel interessante resultaten zijn.

[Abbadon]

Anoniem: 133470 schreef op maandag 06 november 2006 @ 17:31:
[...]


Het verschil is dus dat de ene versie een array van 256 kb deelt tussen twee cores, en de andere versie niets deelt (tenminste, niets waar geschreven wordt, alleen gelezen).
Dus een aardige testcase voor in hoeverre de communicatie tussen de cores efficient verloopt.


[...]


In dat geval zou de eerste versie nooit snel kunnen zijn op een Core2 Duo. Wat dus blijkt is dat het nog steeds significant sneller is (relatief gesproken) dan op een Athlon X2 of Pentium D.
We zien wel dat je iets inlevert tov van een compleet gescheiden algoritme, maar deels is dat ook doordat er een extra kopieerslag nodig is voor het eerste algo. Het verschil is dus maar deels door de mindere efficientie van de L2-cache.


[...]


Dat blijkt nergens uit, want ik heb alleen relatieve getallen genoemd. De Athlon is relatief gezien al veel minder efficient, waardoor hij in het eerste algoritme eigenlijk al helemaal geen winst kan boeken (hoewel je dus wel van 50% naar 100% CPU-gebruk gaat).
Daar komt inderdaad bij dat de Athlon ook in absolute zin een stuk trager is, maar daar ben ik nu niet zo heel erg in geinteresseerd. Het is al langer bekend dat de Core2 gewoon sneller is in bijna iedere situatie.

Goed, je hebt ongetwijfeld gelijk, maar ik doelde ook niet op jouw specifieke situatie maar meer op het algemene gebruik. Ik veronderstelde dat je ook buiten jouw processen om de cpu's op efficiency beoordeelde, maar je hebt het echt over de strenge context van jouw processen

Hier overigens nog twee interessante test over de efficiency van de verschillende caches: http://www.xbitlabs.com/a...ualcore-dtr-analysis.html en http://www.digit-life.com/articles2/cpu/rmmt-l2-cache.html

edit:

Ik heb een machine met vier cores (dual Woodcrest), maar daar heb ik nu even geen Windows op draaien. Wil ik binnenkort wel installeren, dus dan wil ik wel een testje voor je draaien.

[ Voor 5% gewijzigd door Abbadon op 07-11-2006 16:13 ]

[Anoniem: 133470]

Goed, je hebt ongetwijfeld gelijk, maar ik doelde ook niet op jouw specifieke situatie maar meer op het algemene gebruik. Ik veronderstelde dat je ook buiten jouw processen om de cpu's op efficiency beoordeelde, maar je hebt het echt over de strenge context van jouw processen

Ja en nee. Het gaat natuurlijk niet om mijn proces, maar om het verschijnsel dat zich in mijn proces voordoet, en niet per definitie uniek is voor mijn proces, maar zich ook in andere processen kan en zal voordoen. De sleutel is hier dat je het bij multi-CPU systemen eigenlijk per definitie moet vermijden, waar een multi-core systeem hier in theorie goed mee weg kan komen.
In de praktijk blijkt dus dat de Core2 Duo de enige multicore processor is die dat ook enigszins doet op dit moment. Dit opent een deur naar nieuwe vormen van optimalisatie voor multithreading.

Hier overigens nog twee interessante test over de efficiency van de verschillende caches: http://www.xbitlabs.com/a...ualcore-dtr-analysis.html en http://www.digit-life.com/articles2/cpu/rmmt-l2-cache.html

X-bit Labs komt tot ongeveer dezelfde conclusies als ik... wat ze bij digit-life precies willen bewijzen, volg ik niet helemaal. Volgens mij proberen ze het van de andere kant te benaderen... Wat gebeurt er met shared cache als je niet geinteresseerd bent in het sharen?
Da's meer van toepassing op multitasking dan multithreading, da's meer voor server-achtige taken, daar ligt niet mijn interesse.
Verder lijken ze echt voor de theoretische worst-case te gaan, die in de praktijk waarschijnlijk zelden of nooit voorkomt.
(Even voor de duidelijkheid: ik ben hier zeker niet voor de worst-case gegaan... ik dacht alleen dat m'n data klein genoeg was, en de shared writes zeldzaam genoeg zouden zijn om er op een dualcore mee weg te kunnen komen... maar dat bleek dus nog tegen te vallen, dat gaat hopelijk in volgende generaties multicore nog verbeteren).

[ Voor 26% gewijzigd door Anoniem: 133470 op 07-11-2006 16:57 ]

[needless to say]

needless to say schreef op dinsdag 07 november 2006 @ 14:54:
X2 4600+ S939
7900GT

fire.exe ~150fps
fire_multithread ~150fps
fire_multithread2 ~200fps

33% sneller dus. Overal de standaardinstellingen gebruikt.

Ik heb het nog eens gedraaid en gekeken naar task manager.

Bij fire.exe draait 1 core op 100%, de ander doet niets.
Bij fire-multithread.exe draait 1 core op 100% en de ander op 25-50%.
Bij fire-multithread2.exe draait core 1 op 100% en de ander op 50-60%.

Het is dus wel niet dat het programma je 2 cores volledig belast zonder (degelijke) performantiewinst.

Dit bewijst dus dat de X2-processor vooral goed is voor proces load-balancing en inderdaad minder goed is om 1 zeer specifiek proces met gedeeld geheugen degelijk te versnellen.

Nu, ik denk dat irl proces load-balancing veel meer voorkomt. In jouw specifiek geval wordt de processor gevraagd om 1 zeer specifiek rekenintensief stukje code uit te voeren, waarbij je steeds afhangt van je vorige state (je zou het een soort Markov-proces kunnen noemen). Je moet dus constant direct terugkijken naar de zojuist gegenereerde gegevens. En dit wil je multithreaden. Je moet dus steeds direct de uitkomst hebben van de resultaten van beide cores. In de praktijk komt dit echter bitter weinig voor. De meeste rekenintensieve taken voor een computer zijn een pak beter paralleliseerbaar en hangen iets minder sterk af van zojuist gegenereerde resultaten.

Je benchmark is leuk en goed gevonden, maar ik denk dat het enkel een academische waarde heeft.

[Anoniem: 133470]

Het is dus wel niet dat het programma je 2 cores volledig belast zonder (degelijke) performantiewinst.

Had je ook achtergrond-processen draaien?
Ik heb gemerkt dat de Windows-scheduler anders omgaat met een enkele high-performance thread in een proces dan met twee.
Als ik op de achtergrond bv een distributed client draai, met idle priority, dan krijgt die toch voorrang op de tweede thread (met normale priority), wat enorm scheelt in de performance.
Hij gaat op m'n Core2 ook niet helemaal naar de 100% op beide cores, maar toch wel 85-90%, als er verder niets boeiends in de achtergrond draait.

Windows meet overigens alleen hoeveel tijd hij aan een bepaalde thread geeft. Of de CPU in die thread nuttige dingen doet of loopt te wachten, kun je daar niet aan afzien. De load-balancing heeft dus niets met de CPU te maken, en alles met de scheduler van Windows.

In jouw specifiek geval wordt de processor gevraagd om 1 zeer specifiek rekenintensief stukje code uit te voeren, waarbij je steeds afhangt van je vorige state (je zou het een soort Markov-proces kunnen noemen). Je moet dus constant direct terugkijken naar de zojuist gegenereerde gegevens. En dit wil je multithreaden. Je moet dus steeds direct de uitkomst hebben van de resultaten van beide cores. In de praktijk komt dit echter bitter weinig voor. De meeste rekenintensieve taken voor een computer zijn een pak beter paralleliseerbaar en hangen iets minder sterk af van zojuist gegenereerde resultaten.

Onzin, je begrijpt blijkbaar totaal niet hoe dit algoritme werkt.
Ik heb helemaal niet meteen de zojuist gegenereerde gegevens nodig, in het algemene geval. Het effect is gebaseerd op een 3d-grid, en die deel ik in 2 stukken op. Iedere thread bewerkt z'n eigen deel van de grid, en is daarin compleet onafhankelijk van de ander, en ook van eerder gegenereerde resultaten. Prima paralleliseerbaar dus.
De enige uitzondering is dat ik dus in de eerste versie een globale vertexcache bijhield, waarbij het af en toe (maar veel vaker niet dan wel) voorkomt dat beide threads in hetzelfde deel van de vertexcache moeten lezen of schrijven (ze werken immers op andere delen in de grid, dus normaal gesproken zitten ze niet bij elkaar in de buurt te cachen).
Bij de tweede versie heb ik voor iedere thread een eigen cache, en heb ik dus de kans dat er dubbele vertices gegenereerd worden... maar de winst op de CPU maakt dit verlies op de GPU meer dan goed.
Als ik echt constant de resultaten met een andere core zou teruglezen zou het gigantisch traag worden, zelfs op een Core2 Duo, omdat de L1-cachehit-ratio naar 0 zou gaan.

Je benchmark is leuk en goed gevonden, maar ik denk dat het enkel een academische waarde heeft.

Het is niet 'leuk gevonden', het is een algemeen bekend en veelgebruikt visualisatie-algoritme (vooral bij MRI-scans erg populair), wat ik enkele jaren geleden al geoptimaliseerd had voor singlecore, en waar ik nu de stap maar multicore gemaakt heb.
Het heeft ook niet enkel academische waarde, ik ga dit algo nog veelvuldig toepassen. Nu het nog een stuk sneller is dan destijds met singlecore (de Athlon XP1800+ waarop ik het destijds geoptimaliseerd had, klokte zo'n 70 fps, ik zit nu dus een factor 4 hoger), is er nog veel meer mogelijk qua visualisatie.
Het was ook niet als benchmark bedoeld, ik merkte slechts wat op bij het testen van m'n implementatie, wat ik opmerkelijk genoeg vond om te delen met anderen.

[PowerUp]

A64 3200+ @ 3800+ S939
X800 GTO

Fire: 170 fps
Fire Multithread: 105 fps
Fire Multithread 2: 130 fps

Beetje raar dat dal in Multithread 1. Gewoon de standaardinstellingen gebruikt.

[ Voor 14% gewijzigd door PowerUp op 07-11-2006 20:45 ]

[Anoniem: 133470]

Een 3200+ is toch singlecore?
Die zal alleen maar nadeel ervaren van de extra overhead van 2 threads.

[PowerUp]

Anoniem: 133470 schreef op dinsdag 07 november 2006 @ 20:47:
Een 3200+ is toch singlecore?
Die zal alleen maar nadeel ervaren van de extra overhead van 2 threads.

Dat wel, maar dat multicore 1 trager gaat dan multicore 2, ik had ze gelijk verwacht...

[Anoniem: 133470]

Intussen de 350 fps gepasseerd in de 64-bit versie... ook de 32-bit versie rond de 340 fps nu:
http://scali.eu.org/~bohemiq/FireNew.rar

Dat wel, maar dat multicore 1 trager gaat dan multicore 2, ik had ze gelijk verwacht...

Nee, het eerste algoritme moet iets meer werk doen. Iedere thread genereert een set vertices, en die worden samengevoegd tot 1 vertexbuffer.
Het tweede algoritme heeft een vertexbuffer per thread, dus is meteen klaar. Daarentegen moet de GPU dus meerdere vertexbuffers verwerken. Maar dat is blijkbaar altijd sneller.
Daarom is het eigenlijk nog best opmerkelijk dat de Pentium 4 HT het nog zo goed doet.
Met de laatste versie zit de P4 zelfs tegen de 180 fps aan.

[ Voor 11% gewijzigd door Anoniem: 133470 op 07-11-2006 21:29 ]

[Anoniem: 125834]

Bij deze laatste versie (32-bit) haal ik 420 fps

eerdere versie:

Fire.exe ~ 200 fps

Fire-Multithread.exe ~ 270 fps

Fire-Multithread2.exe ~ 310 fps

C2D e6600 met 7950 gt

[Anoniem: 133470]

Zo, da's nog een stukkie sneller dan mijn E6600... Wat zijn die Core2 Duos toch schandalig snel.
Ben benieuwd in hoeverre jouw 7950GT tov mijn 7600GT daar verantwoordelijk voor is (ik denk dat we met deze snelheden langzaam maar zeker ook de limieten van de GPU op gaan zoeken, niet alleen de CPU meer).
Afgezien daarvan draai ik in Vista RC1 x64 met een beta-driver van nVidia, misschien dat dat ook nog wat snelheid kost.
Of had je hem ook nog overgeklokt?

Ik zal trouwens de telling wat verbeteren, bij dergelijke hoge snelheden laat de precisie nogal te wensen over, het gaat steeds wilder verspringen.
Ik zal een gemiddelde per seconde berekenen, en verder de laagste en hoogste framerate bijhouden.

[ Voor 35% gewijzigd door Anoniem: 133470 op 08-11-2006 09:18 ]

[Anoniem: 128111]

Core2 Duo E6600 (GeForce 6800GT):
Fire.exe: ~200 fps
Fire-Multithread.exe: ~270 fps
Fire-Multithread2.exe: ~305 fps

Beide @ stock speeds zou het veel schelen als er gaat overclocked worden ?

Wat mij trouwens opgevallen is tijdens het runnen is dat de totale cpu load schommelt tussen de 85 en de 90% de cpu bereikt nooit een load boven de 90%. Iemand hier enige verklaring voor?

[ Voor 32% gewijzigd door Anoniem: 128111 op 08-11-2006 13:46 ]

[Anoniem: 133470]

Overklokken heeft waarschijnlijk aardig wat nut...
Ik heb mijn E6600 een tijdje terug eens op 3.0 GHz geprobeerd, en toen haalde ik met de singlethreaded versie al iets van 230 fps ipv 190, en met de eerste multithread haalde ik zo'n 270 ipv 220-230.
Het overklokken van het geheugen speelt hier ook een aardige rol in. Mijn geheugen draaide toen 833 MHz, 4-4-4-12 timings.

Waarom Windows niet helemaal naar 100% gaat, weet ik niet.
Ik vermoed dat ze de scheduler zodanig hebben gemaakt dat hij bij meerdere cores altijd wat ruimte vrijlaat op minimaal 1 core om toch nog snel te reageren op user-input of andere processen, zodat een multicore-systeem altijd een redelijke respons zal hebben (het blijft immers irritant als een applicatie de geest geeft, en je kunt amper je task manager inkomen). Zoals ik al eerder aangaf, een (singlethreaded) proces met idle priority lijkt ook zelfs nog voorrang te krijgen met meerdere cores en threads.
Ik ben benieuwd wat een systeem met 4 of meer cores doet. Misschien dat daar ook alleen de 'laatste' core altijd wat minder werkt.
Misschien ook dat dat niet meer opgaat als je de prioriteit van het proces hoger zet. Dat is wel te proberen.

Een andere verklaring kan zijn dat het met de rendering te maken heeft... maar ik vraag me af of je dat kunt zien. Het renderen gaat namelijk met 1 core, en het berekenen met 2 cores.
Maar dat zou dan betekenen dat het renderen zo'n 10-15% van de totale tijd inneemt... zou kunnen, maar dat lijkt me wat veel. Ik weet ook niet of je dat uberhaupt nog zou kunnen zien, omdat het hele proces dus zo'n 300 keer per seconde doorlopen wordt. Zijn die metertjes zo nauwkeurig? Ik zou verwachten van niet.

[ Voor 27% gewijzigd door Anoniem: 133470 op 08-11-2006 14:01 ]

[BeachPatroller]

@2.4
AMD 4800 X2 939 (stock speed)
DDR 400mhz
Asus 7800gt
Fire ~155 100%
Fire MT ~165 110%
Fire MT2 ~250 166%
Fire32 ~320 213%

@2.7 T.o.v. Stock
Fire ~170 ~113%
Fire MT ~185 ~112%
Fire MT2 ~280 ~112%
Fire32 ~345 ~112%

1 core constant op 100% andere rond de 70%
1 thread die blijkbaar afhankelijk is van de ander

[ Voor 54% gewijzigd door BeachPatroller op 08-11-2006 16:39 ]

[Anoniem: 133470]

Aparte resultaten, dit.
De single-threaded versie is amper sneller dan de eerdere 4600+ resultaten.
Bij de eerste mt haalt ie al iets winst (waarschijnlijk omdat de kloksnelheid van de cache nu ook wat hoger ligt, waardoor die communicatie wat sneller verloopt), en bij de tweede versie gaat het ineens bijzonder hard.

Overklokken blijkt prima te werken... 12% meer kloksnelheid is ook 12% meer prestaties. Beter dan dat kan niet
MHz-mythe strikes again.

[BeachPatroller]

De 4600 heeft een 7900gt die een stukkie sneller is dan mijn 7800gt
Verder had ik alle opties op default laten staan en de nieuwste whql drivers gebruikt.

Mobo is Asus A8n-SLI
overclock alleen de bus omhoog geschroeft naar 225 incl. bus en geheugen dus.
Misschien omdat de 4600 512 kb cache heeft per core en de 4800 1mb?

Doet me toch deugt dat ik nog even snel een 4800 heb bemachtigd, ik had nog getwijfeld tussen 4600 en 4800 maar nu zie ik dat 1mb wel degelijk invloed heeft. kloksnelheid 4600 en 4800 is immers gelijk.

[ Voor 23% gewijzigd door BeachPatroller op 08-11-2006 17:17 ]

[Anoniem: 133470]

Ik denk dat de snelheid van de videokaart niet echt van invloed is.
Ik heb zelf maar een 7600GT, en ik haal ook meer dan 350 fps. Zefls als ik 4xAA aanzet, wordt ie nauwelijks trager.
Driver zou wel invloed kunnen hebben, vooral aan CPU-zijde dan... sneller afhandelen van tekenopdrachten.

Een verschil in cachegrootte zou wel een en ander kunnen verklaren inderdaad... maar op welke manier, weet ik nog niet.
Mt2 is in feite hetzelfde als de single-threaded versie, maar dan dus iedere core de helft van het werk.
Meer cache zou dan zowel bij de single-threaded als bij mt2 een stuk sneller dan de 4600+ moeten zijn. Behalve dan als het toevallig voor het cache-algoritme in de Athlon slecht uitkomt.
Maarja, misschien zit er ook wel een verschil in het gebruikte geheugen... of draaide er op de 4600+ een proces in de achtergrond, waardoor de tweede thread niet zo efficient draait.
Als we aannemen dat de 4600+ ook optimaal draaide, dan is de cache van de 4800+ inderdaad de moeite meer dan waard.

[ Voor 17% gewijzigd door Anoniem: 133470 op 08-11-2006 17:26 ]

[Anoniem: 133470]

Nog een leuk resultaat...
Pentium-D 950 @ 4.5 GHz (X1900XTX) haalt met Fire32.exe zo'n 365 fps.
En met Fire64.exe @ 4.63 GHz zo'n 432 fps.

Het kost even wat moeite (vooral de kerncentrale bouwen was even lastig), maar dan heb je ook wat
Blijkbaar gaat de Pentium D heel erg hard vooruit met 64-bit code, in dit geval tenminste.

64-bit resultaten van Athlon/Opteron zijn ook welkom, evenals dual-CPU... ben benieuwd hoe dit alles zich verhoudt.
Verder is het wel de uitdaging om deze Pentium D nu te verslaan

[ Voor 21% gewijzigd door Anoniem: 133470 op 09-11-2006 23:19 ]

[maratropa]

Is het niet vreemd om dingen over je cpu te zeggen terwijl je ook de videokaart in de vergelijking betrekt?

[Anoniem: 133470]

Nee, want de videokaart heeft nauwelijks effect op de prestaties (behalve dan bij onboard video, of een hele oude/slechte kaart misschien).
Je ziet duidelijk aan hoe makkelijk de framerate omhoog gaat bij het overklokken van de CPU, dat de videokaart geen rol speelt.
Ik heb op m'n 7600GT getest hoe snel het renderen ging, zonder dat de CPU de animatie iedere seconde update... ik kwam rond de 1000 fps uit.
Je kunt ook testen door het window te resizen of door AA aan te zetten.
Dat heeft bij mij ook nauwelijks effect op de framerate.
Bij het kleine standaard-window en geen AA is de videokaart een verwaarloosbare factor.
Alle andere geteste computers hier hadden een veel snellere videokaart, dus die zal nog minder effect hebben.

[Anoniem: 133470]

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.

[Anoniem: 133470]

Ik had inderdaad gelijk wat betreft Vista, het is een stuk langzamer, waarschijnlijk vanwege de videodrivers...
Ik heb hem nu in Windows XP 32-bit geprobeerd op dezelfde PC (E6600 + 7600GT), en nu zit ik rond de 400 fps met Fire32, veel dichter bij de resultaten van SleepingSebbe en speedfreak911.
In dat geval ben ik benieuwd wat ik wel niet haal met XP x64... dat is ook wat gebruikt werd op de Pentium D.

[LauPro]

Het is een tamelijk complex onderwerp waarvan je denk ik niet van iedereen kan verwachten dat men er even diep in zit. Heel kort door de bocht genomen is SMP in principe sneller t.o.v. single core, echter ligt het heel erg aan de architectuur. Zodra er memorybussen gedeeld gaat worden ben je de meeste gevallen zeer veel tijd kwijt met syncen.

Ik kan het hier helaas niet draaien vanwege DirectX maar denk ik ook dat je zo'n enkel effect niet echt de moeite moet nemen om dat MT te maken. MCP/SMP moet je vooral zien dat je meerdere activiteiten naast elkaar kan draaien. Bijvoorbeeld jouw mooie Fire op 1 core en op de andere core een virusscanner of misschien wel de audio. Specifiek voor 1 scope MT in te zetten is imo waanzin.

[Anoniem: 133470]

Het is een tamelijk complex onderwerp waarvan je denk ik niet van iedereen kan verwachten dat men er even diep in zit.

Okee, maar je hoeft niet te reageren als je er niets zinngs over kunt zeggen.
Nu krijg je een paar reacties die eigenlijk nergens op slaan, en naar mijn mening een beetje een aggressieve toon hebben (misschien omdat het verkeerde merk processor de betere/mindere resultaten boekt?).

maar denk ik ook dat je zo'n enkel effect niet echt de moeite moet nemen om dat MT te maken. MCP/SMP moet je vooral zien dat je meerdere activiteiten naast elkaar kan draaien. Bijvoorbeeld jouw mooie Fire op 1 core en op de andere core een virusscanner of misschien wel de audio. Specifiek voor 1 scope MT in te zetten is imo waanzin.

Ben ik het absoluut niet mee eens.
Het gaat niet om het effectje (dat is er maar ff snel ingeklust), het gaat om het algoritme. Dat algoritme visualiseert dus 3d-volumedata. Dit wordt veel toegepast in de medische wereld, bij MRI-scans bv: http://www.ablesw.com/3d-doctor/images.html
Door het te multithreaden kan ik een aanzienlijke snelheidswinst boeken tov 1 core. Dit houdt in dat je een hogere resolutie kunt gebruiken, terwijl je nog steeds interactief door de scan van de patient heen kunt navigeren.
Op dergelijke systemen zul je trouwens geen virusscanners of audio tegenkomen, en meerdere activiteiten komen ook niet voor, het zijn immers dedicated systemen.

Ik vind het dus juist heel nuttig om specifiek voor 1 taak MT in te zetten, wanneer dat significante verbeteringen met zich meebrengt. Ik denk ook dat de meeste multicore/CPU systemen juist voor specifieke taken worden ingezet (renderfarms, wetenschappelijke analyses, serversystemen etc), en juist niet om zo veel mogelijk verschillende dingen tegelijk te draaien.

[ Voor 13% gewijzigd door Anoniem: 133470 op 10-11-2006 15:02 ]

[R-O-Y]

op een E6300 met een 1900GT haal ik dit:

fire: 175 fps
multi: 190 fps
multi2: 215 fps
hoop dat je er wat mee kan

Ik heb in deze pc nog 1GB 533mhz geheugen zitten. Dat is niet echt mooi spul voor deze cpu. Als dat is vervangen post ik nog wel een keer

[ Voor 37% gewijzigd door R-O-Y op 10-11-2006 15:41 ]

[LauPro]

Anoniem: 133470 schreef op vrijdag 10 november 2006 @ 14:52:
[...]
Okee, maar je hoeft niet te reageren als je er niets zinngs over kunt zeggen.
Nu krijg je een paar reacties die eigenlijk nergens op slaan, en naar mijn mening een beetje een aggressieve toon hebben (misschien omdat het verkeerde merk processor de betere/mindere resultaten boekt?).

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. Natuurlijk kan men hier ruwe stats posten maar dat zou een opsomtopic zijn.

Ben ik het absoluut niet mee eens.
Het gaat niet om het effectje (dat is er maar ff snel ingeklust), het gaat om het algoritme. Dat algoritme visualiseert dus 3d-volumedata. Dit wordt veel toegepast in de medische wereld, bij MRI-scans bv: http://www.ablesw.com/3d-doctor/images.html
Door het te multithreaden kan ik een aanzienlijke snelheidswinst boeken tov 1 core. Dit houdt in dat je een hogere resolutie kunt gebruiken, terwijl je nog steeds interactief door de scan van de patient heen kunt navigeren.
Op dergelijke systemen zul je trouwens geen virusscanners of audio tegenkomen, en meerdere activiteiten komen ook niet voor, het zijn immers dedicated systemen.

Ik vind het dus juist heel nuttig om specifiek voor 1 taak MT in te zetten, wanneer dat significante verbeteringen met zich meebrengt. Ik denk ook dat de meeste multicore/CPU systemen juist voor specifieke taken worden ingezet (renderfarms, wetenschappelijke analyses, serversystemen etc), en juist niet om zo veel mogelijk verschillende dingen tegelijk te draaien.

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

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

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.

[Anoniem: 133470]

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.

[Anoniem: 78877]

Anoniem: 133470 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 Anoniem: 78877 op 10-11-2006 17:43 ]

[DroogKloot]

Anoniem: 133470 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).

[Anoniem: 133470]

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 Anoniem: 133470 op 10-11-2006 18:54 ]

[Anoniem: 133470]

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]

Anoniem: 133470 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.

[Anoniem: 133470]

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]

Anoniem: 133470 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 ]

[Anoniem: 133470]

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 Anoniem: 133470 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).

[Anoniem: 133470]

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 Anoniem: 133470 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.}

Anoniem: 133470 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.

[Anoniem: 133470]

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]

Anoniem: 133470 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 ]

[Anoniem: 133470]

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.

[Anoniem: 133470]

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 Anoniem: 133470 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.

[Anoniem: 133470]

VC++ redist installeren, zie eerste post

[Anoniem: 133470]

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.

[Anoniem: 133470]

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.

[Anoniem: 133470]

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

[Anoniem: 133470]

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 Anoniem: 133470 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

[Anoniem: 187449]

op welke resolutie moet je dat meten ?

[Anoniem: 133470]

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.

[Anoniem: 8819]

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 Anoniem: 8819 op 02-12-2006 23:19 ]

[Anoniem: 8819]

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 Anoniem: 8819 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 ]

[Anoniem: 147126]

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 Anoniem: 147126 op 03-12-2006 00:25 ]

[Anoniem: 133470]

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.

[Anoniem: 8819]

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 Anoniem: 8819 op 03-12-2006 20:24 ]

[Anoniem: 133470]

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.

[Anoniem: 133470]

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 ]

[Anoniem: 133470]

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 ]

[Anoniem: 133470]

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 Anoniem: 133470 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 ]

[Anoniem: 8819]

Anoniem: 133470 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 Anoniem: 8819 op 18-12-2006 23:53 ]

[Anoniem: 133470]

Anoniem: 8819 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

[Anoniem: 8819]

Anoniem: 133470 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)

[Anoniem: 133470]

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 ]

[Anoniem: 133470]

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 Anoniem: 133470 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