Cpu's aan gpu-benchmarks onderworpen

Het Duitse magazine PC Games heeft twee processors aan grafische benchmarks onderworpen en de resultaten vergeleken met die van twee videokaarten. Een cpu met vier kernen aan boord blijkt moeite te hebben om een gpu bij te benen.

PC Games wilde graag te weten komen of de taken van een gpu door een cpu overgenomen kunnen worden. Om hier achter te komen, werden de prestaties van een Intel Core 2 Quad Yorkfield en een Core 2 Duo Conroe aan de hand van verschillende benchmarks vergeleken met de prestaties van een Geforce 8500GT en een Geforce 8800GTX. De cpu's en gpu's werden getest in onder meer 3dMark 2001 SE, 3dMark05 en Crysis, waarbij de processors met behulp van Swiftshader dezelfde berekeningen konden uitvoeren als de videokaarten.

Swiftshader wordt door Transgaming ontwikkeld, het bedrijf dat ook verantwoordelijk is voor de ontwikkeling van Cedega. Het programma is een zogenoemde 'software rasterizer', waarmee processors als het ware de taak van gpu kunnen overnemen. Swiftshader is voorzien van een Direct3d 8- en 9-api en biedt daardoor ondersteuning voor onder meer Shader Model 2.0. Verder is het programma van sse-optimalisaties voorzien en is er ondersteuning voor multicoreprocessors aanwezig.

De eerste benchmarks die PC Games heeft gedraaid, was 3dMark 2001 SE waar de Yorkfield-cpu op getest werd. Op een resolutie van 1024 bij 768 pixels zonder fsaa/af zette de processor een score van 2432 punten neer. De Geforce 8800GTX behaalde een score van maar liefst 66.803 punten, bijna 28 keer zo veel als de cpu in zijn eentje. Het verschil tussen een cpu en een gpu wordt in Crysis kleiner: zo wist de Yorkfield een gemiddelde van 5fps in Crysis te behalen, terwijl de Geforce 8500GT 30fps renderde. Daarentegen wist de Conroe-processor net iets meer dan 2fps in Crysis neer te zetten.

Reacties (87)

[Ratpack]

Ik denk dat het het weglaten van een IGP de stroomrekening niet echt ten goede zou komen. Een goede CPU die voldoende krachtig is zal al gauw bijna steeds voor de volle 100% belast worden en alles behalve zuinig zijn. Zo'n IGP lijkt me dan toch echt iets vriendelijker voor je eindafrekening.

edit: dit had hier een reactie op moeten zijn

Inderdaad logisch. maar tegelijkertijd is een verschil van een factor 6 met een 8500GT ook weer niet zo heel dramatisch. Zeker als je bedenkt dat er heel wat computers met veel minder krachtige grafische chips worden geleverd. Waarom nog een IGP gebruiken als je CPU krachtig genoeg is om de video op een scherm te toveren zonder dat je kantoorwerk daar onder leidt?

[Reactie gewijzigd door Ratpack op 4 augustus 2024 08:14]

[Verwijderd]

Ik denk dat het het weglaten van een IGP de stroomrekening niet echt ten goede zou komen. Een goede CPU die voldoende krachtig is zal al gauw bijna steeds voor de volle 100% belast worden en alles behalve zuinig zijn. Zo'n IGP lijkt me dan toch echt iets vriendelijker voor je eindafrekening.

Voor echte gamers is het inderdaad niet echt interessant. Maar het is op dit moment vooral gericht op casual gamers. Als je 1/10 van je tijd speelt valt dat extra energieverbruik dus behoorlijk mee. Bovendien gaan vele spellen zowiezo de CPU zwaarder belasten tijdens het gamen, en verbruikt een IGP ook niet niks. Bovendien verbruikt die zelfs stroom wanneer hij idle draait.

De tijden van enorm energie-inefficiënte CPUs is ook voorbij. De traagste Core 2 Duo Penryn (op 45 nm) is vele malen sneller dan de snelste Pentium-D Prescott en ook nog eens de helft zuiniger. En Intel belooft nog veel betere prestaties per watt voor 32 nm in 2009.

[Verwijderd]

even voor de duidelijkheid, dit is dus emulatie. Door middel van een abstraction layer de instructie sets van een ander hardware platform nabootsen. Het werk naar mijn mening al verrassend snel. ook denk ik dat een amd of intel cpu wel degelijk uitmaakt als ze de software habben ontwikkeld op een van de twee, Emulatie is daar erg gevoelig voor.

[needless to say]

De ontwikkelaar gebruikt zelf een quadcore intel. Er is dus rekening gehouden met de snellere SSE-executie van de huidige intel-generatie.

[koelpasta]

Dan nog kun je ongelovelijk veel performance halen uit het aanpassen van de rendering engine.
Code geschreven om snel op een gpu te draaien is getuned op de data flow van een gpu.
Dat betekent dat er rekening wordt gehouden met de te verwachten hoeveelheid cache op verschillende plekken, hoeveelheid en type registers, etc, etc, etc..
De rendering pipeline op een gpu ziet er ook op een bepaalde manier uit en is zo gekozen op basis van een afweging tussen visuele kwaliteit en de geplande groei van de grafische chips.

Als de grafische chips een andere architectuur zouden hebben dan zouden alle verhoudingen van onderdelen van de pipeline anders moeten liggen.
Dit heeft directe gevolgen voor de implementatie van de render engine en dus ook voor de vehoudingen van visuele elementen.

Die code zal dus nooit efficient op een cpu draaien en zal dus opnieuw moeten worden geschreven!. Een doorsnee CPU heeft namelijk een volkomen andere architectuur dan een GPU.

Deze hele test is dus onzin.
Er wordt hier gewoon getest hoe goed een cpu is in het uitvoeren van code geschreven voor een ander soort apparaat!

GPU's en grafische libraries (DX/OpenGL) zijn al 10 jaar hand in hand aan het groeien. GPU's implementeren features van de libraries en libraries maken gebruik van nieuwe features van gpu's. Een feature van de libraries is bijvoorbeeld dat de data zo wordt georganiseerd dat het (redelijk) efficient naar de gpu kan worden getransporteerd. Dit probleem heb je niet als je op een cpu rendert.
Daar krijg je dan wel weer andere beperkingen voor terug.

Er zouden dus hele nieuwe libraries moeten worden geschreven, specifiek voor cpu's, wil je een beetje vergelijking kunnen maken. Vervolgens krijg je daat een feature set voor terug die je in andere verhoudingen moet gebruiken om het uiterste uit de hardware te persen.

Een mooi voorbeeld is de Cell processor.
In de ps3 doet de Cell ongeveer 1/6 van de FLOPS die de GPU kan produceren.
Maar met 6 Cell's (dus ongeveer netzoveel FLOPS als de GPU) kun je wel eventjes real time ray-tracen op HD resolutie. Dat heb ik geen enkele gpu (zoals wij die kennen) zien doen in die kwaliteit, ondanks dat de gpu's net zo veel floats kunnen produceren.

http://www.alphaworks.ibm.com/tech/irt

[needless to say]

Het leuke is ook dat Swiftshader grotendeels geschreven is door 1 persoon die ook een T.net-gebruiker is

Zijn naam is c0d1f1ed en zijn gallery kan je vinden op [Verwijderde gebruiker]

Al je vragen stel je best aan hem.

Je vindt ook meer uitleg op http://vtk.ugent.be/forums/viewtopic.php?p=609591#609591 waar zij nickname Nick is.

Aangezien dit grotendeels een een-mansproject is zal er wel nog ruimte voor verbetering zijn.

Dit is ideaal voor toekomstige pc's zonder 3D-kaart of voor eenvoudige spellen die DX9 vereisen en op pc's moeten draaien zonder DX9-kaart.

Al bij al een vrij deftig resultaat, als je er aan denkt dat bij de benchmarks die we gewoonlijk zien de CPU+GPU gebruikt wordt en hier enkel de CPU.

[Reactie gewijzigd door needless to say op 4 augustus 2024 08:14]

[Yor]

Ik zat al te speuren of het de overige tweakers al was opgevallen, valt me idd een beetje tegen dat het zo lang duurde voordat iemand er wat van zei.

Maar alle lof voor je dat je de developer in the spotlight zet hier!

[Verwijderd]

Dank u!

[hexagram]

Hmm, ik vind het een knappe prestatie dat ze op deze manier hebben kunnen benchen, en het laat idd wel goed zien dat de combinatie GPU + CPU nog steeds van belang is.

Waar ik nu op hoop is dat de volgende versies van OS X / UNIX OSen / Windows een soort van schaalbaarheid krijgen. Op het moment dat je lekker aan het renderen bent dat dan alle punten van de CPU + GPU die van belang kunnen zijn in werk gesteld worden! Ben je alleen aan het renderen van een 3D object, wordt daar alle focus op gezet etc.

Ik bedoel, het werd al eerder gezegd hier, dan zou je bijv. met 2 cores het spel rennende houden, en met 2 cores de processen uit handen nemen van bijv. de GPU welke hierdoor weer meer kan doen voor de dingen die de CPU niet kan berekenen. Beetje vaag verhaal, maar als je hierdoor echt 5FPS extra zou krijgen, is dat best wel wenselijk.

Niet te vergeten, een game als Crysis hoeft alleen maar soepel te draaien, en geen 125FPS stabiel af te leveren zoals dat bij bijv. Q3/4 en Warsow etc nodig! Dus dan komt die 5FPS extra bij de ongeveer 30 die je nodig hebt best wel van pas !

[Verwijderd]

Volgens Beyond3D presteert een dual-core Penryn gelijkaardig aan een GeForce FX5600/5700 in 3DMark05.

Er is dus nog wat inhaalwerk nodig maar het is wel al bruikbaar. Volledigheidshalve moet wel toegevoegd worden dat een GeForce FX zo laag scoort door zeer beperkte rekenkracht voor floating-point berekeningen, terwijl software rendering vooral beperkt wordt door texture sampling. Maar dat kan in toekomstige CPUs dus verholpen worden met extra instructies zoals een 'gather'-bewerking.

[Amanoo]

Hebben ze hierbij 2 CPU's in de pc gedaan?
Anders vind ik het fout, want de CPU's moeten dan extra veel processen doen, zowel de grafische processen als die de CPU altijd regelt.

Wel fijn te weten dat ik niet per se een Geforce met een 8 als tweede getal nodig heb voor Crysis, maar dat ook een GeForce 8500 voldoet. Ik ben van plan eentje te kopen (eigenlijk ga ik hem krijgen als ik goede schoolcijfers haal) die ff wat beter is dan de GF8500, dus er is nog een kans dat ik met mijn low-end pctje toch nog Crysis kan draaien. Mijn CPU, hoewel low-end, heeft wel genoeg GHz. Iets meer RAM nog even heel vlug is nog wel verstandig.
Ik ben blij, kijk maar: Blij

[Snoitkever]

Anders vind ik het fout, want de CPU's moeten dan extra veel processen doen, zowel de grafische processen als die de CPU altijd regelt.

Dit is geen test van de CPU, zoals het artikel lijkt te beweren, maar een test van de SwiftShader 2.0 software. Dit wordt in het originele artikel duidelijker naar voren gebracht. SwiftShader heeft juist als doel mensen zonder GPU toch DX9 graphics mogelijkheden te geven. De vraag daarbij is dus hoeveel langzamer een proces is als het alleen op de CPU draait in plaats van op CPU+GPU.

[Amanoo]

Zonder GPU?
Hoe kan je dan überhaupt een monitor aansluiten?
Volgens mij houd je dan nog hooguit een supergrote mp3-speler over.

[Verwijderd]

Zonder GPU?
Hoe kan je dan überhaupt een monitor aansluiten?

Vroegere grafische kaarten hadden ook geen GPU. Ze hadden hoogstens wat geheugen om de kleurbuffer bij te houden, een zeer eenvoudig chipje om blokken uit het hoofdgeheugen te kopiëren (bliter), en een digitaal/analoog-omzetter voor de uiteindelijke uitvoer.

Tegenwoordig zou een minuscuul chipje op het moederbord volstaan, net zoals Realtek doet voor het geluid (alle verwerking gebeurt op de CPU in de driver). Of het kan in de southbridge geplaatst worden, die toch al verantwoordelijk is voor de meeste I/O. En met digitale schermen (DVI / DisplayPort), zou in principe zelfs een paar pinntjes van de CPU bijna rechtstreeks op het scherm aangesloten kunnen worden.

AMD's Geode CPU bevat zo'n ingebouwde primitieve controller.

[Kaasje123]

een 8500 kaart is niet genoeg voor crysis maar oke... Daarnaast zegt je aantal ghz niet zo heel veel natuurlijk... Mijn C2D op 2,4 ghz is sneller dan een pentium 4 op 3 ghz in crysis. Durf ik mijn hand voor in het vuur te steken.

[maxsurf]

in reactie offtopic: Ik speel crysis op een p4 2,8 ghz s478 met 2 gig ram en een radeon X1650 Pro kaart. Heb de resolutie op mijn 17 inch crt dan wel op 1024by768. Dan draait ie best lekker. Ik weet wel zeker dat ie op een goed uitgeruste C2D beter draait. Maar goed is ook appels met peren vergelijken .

Ontopic: Er waren laatst wat nieuwsberichten dat het kraken van codes beter ging met GPU's dan CPU's deze kunnen er daar volgensmij wel specifiek op worden toegescheven. Misschien is een benchmark daartussen beter. Dezelfde decoder gebruiken en kijken hoelang ze bezig zijn met kraken.
Al zal deze methode ook wat haken en ogen hebben.

[Verwijderd]

Er waren laatst wat nieuwsberichten dat het kraken van codes beter ging met GPU's dan CPU's...

Zo zijn er wel meer berichten. Maar waar vaak geen rekening mee gehouden wordt is dat dit enkel geldt voor de meest krachtige GPUs. Doorsnee GPUs moeten het vaak afleggen tegen een doornee CPU van vandaag. Kijk je naar de totale prijs dan is een quad-core vaak interessanter dan een zwakkere CPU plus een GPU (ook al omdat de CPU nog veel andere taken aankan).

In dat soort projecten gaat men vaak ook bijzonder veel moeite steken in het optimaliseren op de GPU, terwijl de CPU beoordeeld wordt op het draaien van prototype-code in C. Door gebruik te maken van SSE en dus het volle potentieel van de CPU te gebruiken komen de prestaties veel hoger te liggen.

Naar mijn ervaring is een GPU enkel beduidend sneller in grafische toepassingen, en zaken die daar rechtreeks van afgeleid zijn. Voor al de rest is de CPU tegenwoordig veelal onderschat.

[ZpAz]

Je kan uiteraard crysis op budgetkaarten testen, als je de instellingen maar niet op het hoogste wilt hebben. Medium / Low op niet al te hoge resolutie zal prima gaan met een 8500GT.

[Chiel340]

Is volgens mij ook niet helemaal een eerlijk vergelijking... GPU's worden via software toch anders aangesproken dan een CPU? En de optimalisatie van GPU's voor grafisch werk is natuulijk ook gewoon beter...

Wel een geinige test...

[Mitsuko]

Yup:
1.) Hedendaagse GPUs hebben zeer veel shader units, vergelijkbaar met cores
2.) Hoe het met cache zit weet ik niet, maar ze hoeven niet van het relatief trage systeemgeheugen gebruik te maken
3.) Shader units beschikken over veel minder instructies dan voor x86 vereist is (en dan hebben we het nog niet eens over MMX en alle versies SSE)
4.) Ze beschikken dan wel weer over gespecialiseerde optimalisaties voor vectors
5.) GPUs werken alleen in floating point (integer is ook mogelijk maar dan via de floating point units, en met verlaagde precisie) terwijl CPUs over het algemeen sneller met integers om (moeten) kunnen gaan.

Beetje vage test dus..

[Reactie gewijzigd door Mitsuko op 4 augustus 2024 08:14]

[jmzeeman]

Wie zij dat het een eerlijke vergelijking moest zijn... de resultaten vallen me eigenlijk nog wel mee. Maar ik vindt eigenlijk dat ze ook de ander kant op een keer moeten testen: windows op een GPU . Ik denk alleen dat dit uberhaubt niet mogelijk is (geen ondersteuning van paging, threads, IPC, interupts e.d.)
De vergelijking tussen cores en shaders die veel tweakers hier maken is eigenlijk niet goed. Op elke core in een processor kan je andere code draaien terwijl alle shaders altijd tegelijkertijd dezelfde code draaien. De shaders kan je beter vergelijken met SSE of MMX maar dan op een veelvoud van registers.

(integer is ook mogelijk maar dan via de floating point units, en met verlaagde precisie)

Sorry maar wat is dit voor onzin, integer berekeningen met verlaagde precisie?!?!? Integer berekeningen hebben een inherent lage precisie(door dat je geen cijfers achter de komma hebt) als je die nog verder onprecies maakt dan heb je er niks meer aan want dan is het gewoon fout.

(en dan hebben we het nog niet eens over MMX en alle versies SSE)

Dit is waarschijnlijk het geen wat de CPU's nog een beetje gered heeft, dit kan al snel een aantal factoren schelen. De instucties op de GPU zullen meer weg hebben van de SSE en MMX instructies als van de rest van de x86 standaard.

@Sakete
Om de verwarring nog groter te maken: De niewste Intel CPU's kan je ook zien als RISC processors die een CISC processor emuleren... De meeste instructies worden omgezet in een aantal instructies uit een (redelijk kleine)basis set van instucties.

@k1n8fisher

Is het niet dat Intel en AMD beiden werken aan een alles in 1 kunner chip? Soms wordt er zelfs geclaimd dat een beetje CPU het zonder GPU ook wel kan stellen.

Beide bedrijven werken hier zoals je zegt nog aan, het gaat dan ook om een compleet GPU deel wat bij de processor in komt. De processor zal niet zijn reguliere hardware gebruiken om de GPU te emuleren zoals hier het geval was. Dus op dat gebied gaat je vergelijking mank.

@sangdrax
Wat betreft de term precisie heb je gelijk, even een oversimplificatie van mijn kant. Maar dat laat natuurlijk onverlet dat integer operaties met verlaagde precisie onzin zijn.

@Toontje_78

Integers zijn juist waarden met een gelijke interval tussen opeenvolgende bits, waar floats nu een veranderlijke interval hebben tussen opeenvolgende bits.

Ik denk wel dat ik weet wat je bedoelt maar wat je hier beweert is complete onzin. Er zitten geen gelijke intervallen tussen de waarden van bits niet bij integers en niet bij floats. Wat je waarschijnlijk bedoelt is dat een float een variabele komma heeft. Een float bestaat eigenlijk uit twee integers eentje die het getal weergeeft en eentje die aangeeft waar de komma moet staan.

[Reactie gewijzigd door jmzeeman op 4 augustus 2024 08:14]

[Verwijderd]

Sorry maar wat is dit voor onzin, integer berekeningen met verlaagde precisie?!?!? Integer berekeningen hebben een inherent lage precisie(door dat je geen cijfers achter de komma hebt) als je die nog verder onprecies maakt dan heb je er niks meer aan want dan is het gewoon fout.

Met precisie bedoelen we niet cijfers achter de komma, maar significante cijfers. Met een integer unit kan je A+B-B doen en op A uitkomen. Bij floating point is dat niet het geval, omdat A+B eerst afgerond wordt. Een 'double' kan namelijk alleen de belangrijkste 53 bits onthouden en zegt "zoveel nullen ervoor of erachter". Dit in tegenstelling tot een 64-bit integer unit van en 64-bit CPU, waarin je getallen van 64 bit in z'n geheel exact kan opslaan.

[Toontje_78]

(integer is ook mogelijk maar dan via de floating point units, en met verlaagde precisie)
Sorry maar wat is dit voor onzin, integer berekeningen met verlaagde precisie?!?!? Integer berekeningen hebben een inherent lage precisie(door dat je geen cijfers achter de komma hebt) als je die nog verder onprecies maakt dan heb je er niks meer aan want dan is het gewoon fout.

Ik ben het met deze bewering niet eens.
Integers zijn juist waarden met een gelijke interval tussen opeenvolgende bits, waar floats nu een veranderlijke interval hebben tussen opeenvolgende bits.

Als je hier mee optellen gaat, zal een integer een integer opleveren, waar een float de dichts bij de uitkomst zijnde float op zal leveren. Het voordeel van floats is wel dat het bereik tussen kleinste en grootste weergegeven getal vele malen groter is.

[Snoitkever]

De vergelijking tussen cores en shaders die veel tweakers hier maken is eigenlijk niet goed. Op elke core in een processor kan je andere code draaien terwijl alle shaders altijd tegelijkertijd dezelfde code draaien. De shaders kan je beter vergelijken met SSE of MMX maar dan op een veelvoud van registers.

Het gaat eigenlijk al fout als je het hebt over shaders. Shaders zijn namelijk de programma's die door de GPU voor elke vertex, primitieve of pixel worden uitgevoerd. Stream processors, shaders of cores zijn allemaal verkeerde termen, terwijl we het over ALU's moeten hebben. Deze ALU's (128 bij G80, 320 bij R600) zijn vervolgens gegroepeerd in clusters (8 bij G80, 4 bij R600), en elk cluster kan onafhankelijk van de anderen een programma (shader) uitvoeren. Zo je wil kan je een cluster dus een processor noemen, hoewel dat misschien ook niet eerlijk is. Er is namelijk nog een apparte thread scheduler die bepaalt welk cluster aan welke thread gaat werken, en ook de geheugencontrollers zijn losgekoppeld van de clusters.

Stream processors en cores zijn leuke marketingtermen, maar ze staan helaas heel ver van de waarheid, en zorgen voor zowel verwarring als overschatting van de mogelijkheden van G80 en R600 (en afgeleiden). Zie bijvoorbeeld onderstaande post van DikkeDouwe.

[Reactie gewijzigd door Snoitkever op 4 augustus 2024 08:14]

[TheCapK]

Zo vaag is deze test niet. Is het niet dat Intel en AMD beiden werken aan een alles in 1 kunner chip? Soms wordt er zelfs geclaimd dat een beetje CPU het zonder GPU ook wel kan stellen.
Nu weten we tenminste dat het allemaal iets moeilijker is dan soms wordt voorgesteld door o.a. Intel. De GPU is er niet voor niets en zal voorlopig nog niet uiitgerangeerd zijn!

Het zou zelfs interessant zijn om een GPU eens te testen op CPU gebied. nVidia en ATi claimen immers ook dat een GPU steeds meer op een CPU gaat lijken en daar ook taken van kan overnemen.
Door ook dat te testen krijg je een veel beter idee van hoe alles er voor staat.

Stel dat en GPU wel een CPU kan vervangen maar niet andersom, dan is er ineens een enorme concurrent bij voor AMD en Intel namelijk nVidia. Wedden dat dat de markt enorm interessant gaat maken!

[Reactie gewijzigd door TheCapK op 4 augustus 2024 08:14]

[Verwijderd]

Het zou zelfs interessant zijn om een GPU eens te testen op CPU gebied. nVidia en ATi claimen immers ook dat een GPU steeds meer op een CPU gaat lijken en daar ook taken van kan overnemen.

Je kan bepaalde werklasten door de GPU laten uitvoeren, maar niet een volledige applicatie op de GPU draaien, laat staan een besturingssysteem.

Om te beginnen is een GPU enkel geschikt voor code van beperkte lengte, terwijl een CPU met ettelijke megabytes aan code overweg kan. Verder is een GPU erg traag in het uitvoeren van een enkele thread. Het voert steeds dezelfde bewerking uit voor een 'batch' aan data. Zo duurt het dus ook tientallen klokcycli voor een spronginstructie genomen kan worden, iets waar een CPU zeer goed in is en wat ook verwacht wordt voor doorsnee applicaties. Danzij z'n caches bespaart een CPU ook zeer veel bandbreedte en latentie, terwijl een GPU voor bijna alles naar RAM-geheugen moet (wat enkel gericht is op texture sampling).

Bemerk ook dat een GPU nog steeds relatief vaak de driver nodig heeft om 'administratief' werk uit te voeren, en dat gebeurt dus op de CPU.

De zogezegde enorme rekenkracht van GPUs is dus erg relatief. Hij is zeer gespecialiseerd in 3D rendering maar voor zowat alle andere dingen is de CPU beter geschikt of kan hij goed zijn mannetje staan. Met steeds meer cores en instructies die op die van een GPU lijken is de CPU dus een grotere bedreiging voor de GPU dan omgekeerd.

[Verwijderd]

112 shaders heeft de 8800GT (net opgezocht ) Dus om de berekening een beetje eerlijk te laten verlopen zou je een 112 core CPU moeten vergelijken. Dus voor de yorkfield zou dat betekenen 2432 / 4 * 112 = 68096 ter vergelijking met de 8800GT met 66.803 punten dan zou de yorkfield dus sneller zijn...

[Verwijderd]

Dus om de berekening een beetje eerlijk te laten verlopen zou je een 112 core CPU moeten vergelijken.

Fout. Een 8800 GT heeft 112 scalaire shader units, gegroepeerd in clusters van 16. Da's dus eerder 7 cores uitegerust met vectoreenheden van 16 elementen. Vergeet ook niet de kloksnelheid mee te rekenen.

Berekenen we het aantal floating-point optellingen en vermenigvuldigingen per seconde dan komt een 8800 GT op 336 GFLOPS. Een 3 GHz Core 2 Quad haalt 96 GFLOPS. Da's nauwelijks een factor 3,5 verschil!

Toekomstige CPUs zullen AVX ondersteunen, wat de SSE-vectoren uitbreidt tot 8 elementen. Aan circa 4 GHz haalt het dan 256 GFLOPS voor een quad-core, 512 GFLOPS voor een octa-core, en potentieel nog eens een verdubbeling met 'fused multiply-add' eenheden. Een biljoen floating-point berekeningen per seconde dus...

[Sakete]

Ja... als aanvulling, wellicht dat je GPU's ook onder RISC processors kan plaatsen en de Intel/AMD CPU's onder CISC processors.

[martijnvanegdom]

Nou.. ik denk dat je niet meer helemaal up to date bent.. Het verschil tussen Risc en Cisc zijn is zeker in de x86 (en x86_64) ongeveer verdwenen... Er zijn SSE instructies die vele gigabytes aan data kunnen verwerken.. Het verschil is vaag en niet defineerbaar in huidige cpu's Daarnaast.. Risc en Cisc heeft eigenlijk geen invloed op de prestaties.. Het is een hele andere architecteur en dus niet te vergelijken..

Daarnaast kun je er over ruzieen of een GPU wel in te delen in CISC of RISC..

[Darkwings]

Een beetje offtopic, maar heb je een linkje van SSE instructies de vele gigabytes aan data kunnen verwerken?

Ik ben een beetje sceptisch, maar als dat bestaat ben ik er wel benieuwd naar

[Verwijderd]

Een beetje offtopic, maar heb je een linkje van SSE instructies de vele gigabytes aan data kunnen verwerken?

Een Core 2 Quad aan 3 GHz kan per core per klokcyclus een vector van 4 elementen vermenigvuldigen en optellen. Da's dus 4 * 3.000.000.000 * 4 * 2 = 96 gigaflops. Een floating-point getal is 4 bytes dus da's gelijk aan 384 GB/s. Daarbij dient de data wel voornamelijk uit het cachegeheugen te komen (meestal het geval). De bandbreedte naar het hoofdgeheugen is 25.6 GB/s voor een 1600 MHz FSB.

Toekomstige processoren breiden de 128-bit registers van SSE uit naar 256-bit (AVX), en de bandbreedte zou tot 51 GB/s oplopen.

[Reactie gewijzigd door Verwijderd op 4 augustus 2024 08:14]

[Darkwings]

Ja, dat begrijp ik wel.

Als dit het enige is heeft martijnvanegdom z'n post niet zo goed geformuleerd volgens mij, want je hebt dus idd geen SSE instructies die direct gigabytes geheugen verwerken. De programmeur zal toch zelf nog dat geheugen naar de SSE registers moeten kopieren en weer terug.

Heeft dus eigenlijk niks met SSE te maken, op die manier kunnen normale instructies ook gigabytes verwerken, het duurt alleen langer.

[danielsrje]

Inderdaad. Het was wel leuk geweest om, als tegenhanger, WindowsXP op een 8800GTX te draaien, en daar dan weer een benchmark op. ... Kijken hoeveel MFlops er dan nog uitkomen!

[knirfie244]

Relatief traag geheugensysteem? Het geheugen op een videokaart bied bijna evenveel bandbreedte als de cache op een processor...

[Snoitkever]

Maar wel met enorme latencies. Niet dat dat erg is, want een GPU heeft honderden threads tegelijk draaiend, maar het is niet eerlijk om GPU en CPU geheugen te gaan vergelijken.

[Nemesizz]

Idd wel grappig, en idd niet helemaal eerlijk.

De GPU hoeft alleen maar spul te renderen, terwijl die CPU, ten eerste een OS moet draaien, het programma zelf, en het spul moet renderen (om het simpel te zeggen, zal wel weer wat ingewikkelder inelkaar zitten).

Als ze nu bijv Windows en 3dmark (het programma zelf) en het renderen op een GPU deden zou die naar mijn idee ook niet meer zo hoog scoren.

[Verwijderd]

De GPU hoeft alleen maar spul te renderen, terwijl die CPU, ten eerste een OS moet draaien, het programma zelf, en het spul moet renderen

Ik weet niet of je ooit naar de system load gegeken hebt ten gevolge van het OS ook bij een zwaarbelaste processor. Deze is minder dan 10%.
Voor redering draait op op de GPU een programma. Als je 10% verlies meenam voor de CPU zou deze 25-26 langzamer zijn ipv 28. Is nog steeds vele malen langzamer.

Een GPU is een specialistische unit, hier zal een CPU die veel meer moet kunnen nooit aan tippen.

Zo is een ASIC ook vele malen sneller voor netwerk verkeer dan een CPU. Ieder zijn vak!

[smokalot]

Ten eerste is CPU load gedefinieerd als het aantal timeslices dat een proces moet wachten voor het aan de beurt is, en niet als het aantal procenten (dat maakt het erg onzuiver namelijk).

Ten tweede kun je onmogelijk zeggen hoeveel CPU een OS gebruikt, omdat in de CPU van het draaiende proces allemaal dingen meetellen die door het OS afgehandeld worden, en meestal worden zelfs dingen als IO latency meegenomen in de CPU, omdat de CPU in de tussentijd niks anders kan doen.

Verder heb je natuurlijk helemaal gelijk in je analyse, maar ik ben wel benieuwd in hoeverre het nou noodzakelijk is dat je voor iedere taak een andere processor moet hebben... (maarja, zolang iedereen nog vast zit aan windows en dus intel is er sowieso erg weinig ruimte om te experimenteren met architecturen).

[Verwijderd]

draai het eens om.. laat een paar dikke programma's draaien op een gpu

[Munters]

Ja, daar zijn ze serieus mee bezig.
Gaat vooral goed voor eenvoudige massief parallelle programma's.
Koetjes draaien in een razend tempo, en ook voor bijvoorbeeld photoshop filters zie ik wel een toekomst.

[g4wx3]

GPU kan berekening maar in beperkte mate terug aan de cpu / het systeem doorspelen.

GPU kan dus alleen maar de display aansturen, en daarna zijn de gegevens meteen verloren.

[lvh]

Good luck met een CPU load in percenten uit te drukken. Het is niet omdat Windows je een cijfertje geeft dat daar enige fysische betekenis achter zit.

[Verwijderd]

Het is niet omdat Windows je een cijfertje geeft dat daar enige fysische betekenis achter zit.

Ik heb het over Linux, hier kun je precies achterhalen hoe de systemload verdeeld is, welke processen, IO etc.
Ik weet niet hoe dit bij Windows werkt en of dit mogelijk is.

[SoulShot]

Volgens mij halen deze CPU's ook zo'n slechte score tegenover een GPU omdat de gebruikte GPU chips 1 core hebben en die ten volle benutten. Dit tegenover de CPU's met multicores waarvan er maar ééntje wordt gebruikt in bijvoorbeeld crysis.

Of klopt deze redenatie niet?

[ComBax]

Nee

GPU's zijn gewoon gebouwd om goed te presteren in games (DirectX wordt vb hardwarematig ondersteund) en afspelen van video (MPEG-decoding). That's it.

CPU's zijn allrounders die goed zijn in alles, maar niet perfect in 1 speciefieke taak (zoals bij GPU's het geval is).

Het was inderdaad interessant geweest om ook een office benchmark te runnen op een GPU, waarschijnlijk zou die dan ondermaats presteren tov CPU.

[Verwijderd]

Nee. GPU's bestaan eigenlijk uit een veel groter aantal cores dan CPU's (vgl de 128 unified shaders van een G80 tov de vier cores van een Qxxx) . 3D rendering maakt veelvuldig gebruik van floating point berekeningen, waar CPU's niet zo sterk in zijn.

[Verwijderd]

vgl de 128 unified shaders van een G80 tov de vier cores van een Qxxx

G80 heeft 8 cores met rekeneenheden van 16 elementen. Een Core 2 Quad heeft 4 cores met rekeneenheden van 4 elementen, en een hogere kloksnelheid. Met extra cores en AVX wordt het verschil in de toekomst nog kleiner.

Aan floating-point rekenkracht ontbreekt het een CPU nauwelijks, het is vooral het texture sampling waarin de GPU zeer veel sneller is. Waar een GPU even veel samples kan nemen in één klokcyclus als het texture units heeft, duurt het bij een CPU ruwweg een hondertal klokcycli per core om dezelfde functionaliteit te emuleren.

De situatie zou dus behoorlijk kunnen veranderen wanneer CPUs uitgebreid worden met instructies om texture sampling te versnellen. Eén zo'n instructies, die al door sommige andere CPU-architecturen ondersteund wordt, is de 'gather'- bewerking, die in parallel verschillende geheugenplaatsen kan uitlezen.

[Reactie gewijzigd door Verwijderd op 4 augustus 2024 08:14]

[Arrigi]

Eigenlijk hebben GPU's tegenwoordig honderden "cores" .. Maar die zijn compleet anders opgebouwd dan die van een CPU. Bij deze test zullen alle cores van de CPU ook wel volop gebruikt worden. Ze zijn gewoon gebouwd voor verschillende doeleinden, en presteren op hun eigen vakgebied dan ook veel beter.

[Verwijderd]

GPU's zijn geoptimaliseerd voor zulke berekeningen, terwijl een CPU toch een soort all-round (generieke) eenheid is, die van alles moet kunnen.

Een GPU zou sommige pc taken ook niet kunnen runnen, of veel langzamer dan een cpu. Anders hadden we geen CPU's in onze computers gehad!

[elleP]

Nope,

Verder is het programma van sse-optimalisaties voorzien en is er ondersteuning voor multicoreprocessors aanwezig.

Dit gaat overigens ook niet over cpu prestaties tijdens een game, maar over het renderen van het beeld op een cpu in plaats van een gpu, dus in feite in een pc zonder 3d-kaart.

Dat in beschouwing genomen vind ik het zo slecht nog niet

[Verwijderd]

Klopt. Het ondersteunt Shader Model 2.0, terwijl iedereen met nog een GeForce 4, een Radeon 8500 of een geïntegreerde chip van een klein aantal jaren geleden dat dus helemaal niet kunnen draaien in hardware.

SwiftShader is dan ook vooral bedoeld om ontwikkelaars van casual games gebruik te laten maken van Shader Model 2.0 zonder zich zorgen te maken of dat wel ondersteund wordt door de GPU. Indien wel is dat veelal de beste optie, maar indien niet draait het dus exact hetzelfde op de CPU. Het helpt dus ook QA- en supportkosten te verkleinen omdat minder hardware getest moet worden en ook falende hardwaredrivers opgelost kan worden door aan software rendering te doen.

[Verwijderd]

Een 8800GTX heeft 128 stream processors wat je ongeveer kan vergelijken met een vorm van multicore.
De CPU's halen gewoon een slecht resultaat omdat ze er niet voor zijn gemaakt, zo simpel is het. Met een GPU moet je zelfs niet denken vele applicatie in emulatie op te starten.

[drZymo]

Ik kende dat hele Swiftshader niet eens. Leuk initiatief. Vraag me af waarom ze zoiets niet met DirectX integreren. Het zou erg handig zijn als bijvoorbeeld je grafische kaart bepaalde features niet ondersteunt dat dit in DirectX automatisch via software rendering wordt gedaan. Zo zou je zonder een "DirectX 10-capable" kaart toch nog DirectX 10 applicaties kunnen draaien (ten koste van je processor load natuurlijk).

[Snoitkever]

Heb je enig idee hoe complex een GPU is en hoeveel complexer de hele software stack daar bovenop nog is? Als een enkele feature diep in de pipeline, bijvoorbeeld een niet ondersteunde shaderoperatie) niet aanwezig is zou je midden in een thread moeten stoppen, alle registers naar de CPU moeten sturen, daar de operatie uitvoeren, waarbij je mogelijk texturegegevens nodig hebt die je ook van de GPU af moet halen, om tot slot alles terug te sturen en verder te gaan. En dat dan voor makkelijk toch vijf of tien operaties per pixel, mogelijk voor elke pixel die op het scherm wordt gezet (miljarden per seconde). Dat is compleet onmogelijk.

[Janssen]

CPU: jack of all trades, master of none.

Vrij logisch allemaal dit.

[humbug]

Inderdaad logisch. maar tegelijkertijd is een verschil van een factor 6 met een 8500GT ook weer niet zo heel dramatisch. Zeker als je bedenkt dat er heel wat computers met veel minder krachtige grafische chips worden geleverd. Waarom nog een IGP gebruiken als je CPU krachtig genoeg is om de video op een scherm te toveren zonder dat je kantoorwerk daar onder leidt?

[swampy]

Ugh vergeet niet dat er een tijd was dat het kopen van videokaarten een mijnenveld was.

Bijvoorbeeld een GF 4 heeft pixel en vertex shaders maar een GF 4 MX is meer als een GF 2 met alleen maar pixel shaders.

En zelfs nu nog zien we dat het verre van uniform is op de videokaart markt. Okay directx 10 heeft dingen meer gelijk getrokken dat is zeker waar.

Maar in het Dx9 tijdperk hadden we nogsteeds fabrikanten die dingen niet op de HW konden doen dus maar via SW afhandelde! S3 is nogsteeds een bedrijf die zwakke GPU's maakt!

[johnbetonschaar]

CPU: jack of all trades, master of none.

Control-intensive code is nog altijd het domein van general purpose CPU's, code met inherent veel tests en (conditionele) branches kan je op geen enkel andere processortype sneller uitvoeren.