Cpu's aan gpu-benchmarks onderworpen

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!

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

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

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]

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

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!

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

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

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.

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!

[off-topic]Ik hoop niet dat je Black-Scholes voor enigszins serieus werk gebruikt. Die formule is erg simpel en er bestaan verschillende (betere) alternatieven. Kost natuurlijk meer rekenwerk maar dát is bij de huidige systemen geen probleem[/off topic]