Ontwikkelaars spellen over SSE2 versus 3DNow!

VoodooExtreme heeft aan John Carmack en Tim Sweeney, de grote namen achter respectievelijk Quake en Unreal, gevraagd wat hun mening is over de processors van Intel en AMD. Vinden deze toonaangevende figuren in gamesland SSE2 beter dan 3DNow! en waarom? De antwoorden zijn echter niet in het voordeel van de ene of de andere, eerder negatief over beide. John Carmack zegt in feite dat het hem al sinds de release van de Athlon niet meer kan boeien en Sweeney nuanceert die opmerking door uit te leggen dat de uitbreidingsinstructies voor de programmeurs behoorlijk onhandig zijn en dat men veel liever dingen als vertex shaders in videokaarten ziet, omdat daar veel beter mee gewerkt kan worden:

SSE is an instruction set only a CPU architect could love -- it lacks instructions that developers use most frequently, like a simple dot product operation. To do that in SSE, you have to go through major gymnastics. The DirectX8/NV20 vertex shader instruction set is much more in line with what developers need from a SIMD instruction set -- it has dot products; arguments can be swizzled, so you can perform a cross-product in 2 instructions. That's what SSE/3DNow should evolve into in the future.

Reacties (41)

[motormuis]

Ben een beetje verbaast over deze visie van de heren programmeurs. Volgens mij was het 3D-now die het mogelijk maakte om Quake 2 minstens net zo snel op een K6-2 als op een PII te spelen en dat terwijl op FPU gebied de PII aanzienlijk beter is. Ook diverse encoders voor bv MPEG2 en DIVX lopen aanzienlijk harder als ze geoptimaliseerd zijn. Ik kan me een test herinneren waarbij de P4 met de Atlhon vergeleken werd en dat een paar uur code aanpassen een zeer grote prestatiewinst gaf. Het is maar net hoever je het wil aanpassen. Ik krijg het gevoel dat het een stuk gemakzucht is, omdat de proc's toch wel snel genoeg zijn. Het is de vraag of we nog wel snellere proc's nodig hebben of dat de software gewoon sneller en intelligenter moet worden.

[Verwijderd]

Dat software steeds inefficienter word is al lang bekend. Maar om nou te zeggen dat gamesdevelopers lui zijn. Wat die gasten kunnen mag een 'gewone' programmeur wel z'n petje voor afnemen.

Maar wat Tim Sweeney zegt zit ook wel wat in.
Als je iedere keer een zooi instructies moet uitvoeren wat in principe ook in 2 instructies zou kunnen scheelt qua performance echt behoorlijk.
En dan om alles dan naar GPU's af te schuiven werkt volgens mij ook niet zo. Dan worden die krengen nog veel duurder en is er qua innovatie ook niet zoveel uitdaging meer voor CPU op dat gebied. (d'r zijn altijd wel zat andere uitdagingen)

Misschien dat CPU's wat dat betreft wat losser om moeten kunnen gaan met de situatie waarin ze gebruikt worden. Wat de transmeta's hebben is misschien ook wel interessant. Zet je CPU in gaming mode en doettie het stukken beter. En als je aan't surfen bent staattie weer in een andere stand (zodat hij ook niet zo warm wordt)
Misschien niet zo slim om die gasten met de microcode van je CPU te laten programmeren.

[SG]

In de tijd van de K6 was de algehele situatie anders

Wat nu de T&L doet moest toen de CPU doen met zijn FPU 3Dnow/SSE was toen veel belangrijker dan nu met die GPU die had je toen nog niet in de Game kaarten

In deze tijd is de FPU kracht ook snel toegenomen door de hevige concurentie strijd is in somige gevallen de FPU kracht de T&L kracht op grafische markt voorbij gegaan bijvoorbeeld de Savage 2000 heeft ook T&L maar was te laat.

De GPU ontlast de CPU zodat die meer instructie cycles overheeft voor AI 3dsound Multyplay.
Tot op heden werd er in game reviews vaak geklaagt om domme AI tegenstanders dat zal dus in de toekomst mede hierdoor minder worden .

Daarom kan 'n KyroII zonder T&L nog goed meekomen alleen moet hier de AI code competeren met de render code

Bij sommige games kan je kiezen tussen de gewone HAL
of
HAL & T&L

Met 'n top CPU zal de gewone hal het ook goed doen
maar omdat niet iedereen 'n snelle CPU heeft is de HALT&L 'n betere keus

Daarbij maak de nieuwste T&L(Geforce 3) generatie nieuwe functies mogelijk die alleen efficient in T&L te doen zijn.

[Korn21]

Wat leuk. Dat zou dus zeggen dat menigeen software ontwikkelaar totaal geen rekening met extra chipinstructies houdt. Kort gezegd SSE(2) en 3dNow! zitten voor niets op je CPU , op enkele (schaarse) programma's na.
Da's niet zo handig van de CPU-bouwers. Intel en AMD zouden ervoor moeten zorgen dat de software boer er meer aandacht aan besteed. Dan gaat mijn beestje tenminste een beetje harder lopen met programma's.

[Verwijderd]

Kort gezegd SSE(2) en 3dNow! zitten voor niets op je CPU , op enkele (schaarse) programma's na

opzich was dat allang duidelijk.. omdat kijk, eerst komt er MMX, ontwikkelaars maken daar software voor en als ze klaar zijn komt er opeens SSE, daar zijn ze eigenlijk nog maar net aan begonnen en dan komt opeens SSE2.....
lukt ze niet om dat bij te houden, dus kijken ze liever naar dingen die videokaarten ondersteunen...

[PuzzleSolver]

Als het goed is hoeven ze zich er niet al te druk om te maken omdat de compiler dit voor hun regelt. En sinds de 3D kaart is de taak van de CPU veel meer de complexe dingen als AI, bewegende objecten etc. i.p.v. het rasteriseren plaatjes. Lijkt me dat je dat liever niet in assembly schrijft (erg moelijk te onderhouden en slecht scaleable en de performance bottleneck zit toch meestal op de videokaart).

[Strebor]

De gameprogrammeur wil zijn 3D engine en routines zo snel mogelijk hebben. Om dit te realiseren programmeert hij grote stukken code rechtstreeks in assembly. De SSE en 3DNOW functies zal hij dus zelf direct moeten aanroepen aangezien hier geen compiler bij komt kijken,

[PuzzleSolver]

De gameprogrammeur wil zijn spel zo snel mogelijk af hebben aangezien er commerciele druk achter zit. Assembly zal hij dus alleen gaan toepassen op de plaatsen waar de bottlenecks zich voordoen. Vroeger was dit veel in de eigen 3D engine maar sinds de 3D graphische kaart wordt dit allemaal overgelaten aan de 3D kaart en de drivers en daarmee ook OpenGL en DirectX (de drivers etc. worden daarom wel vaak in grote stukken in assembly geschreven en hier heeft 3D Now, SSE etc wel zin). Aangezien de complexe 3D engine met al zijn objecten poppetjes etc allemaal vrij highlevel programmeerwerk is wat je niet zo ff 123 in assembly schrijft. En mede omdat deze code bijna nooit een bottleneck vormt zullen ze dit gewoon overlaten aan de compiler, ook zodat als er een SSE3 zou komen het gewoon een kwestie wordt van opnieuw compileren (gaat niet altijd op,maar waar nodig kun je de C code aanpassen zodat het wel optimaliseerbaar wordt).

Eigenlijk zou je dus de driver programmeurs moeten vragen naar hun mening over 3DNow en SSE. De gameprogrammeur ziet veel liever specifieke assembly voor graphics zoals vertex shaders en pixel shaders.

[edm]

<snip>
, maar dingen zoals een dot tekenen klinkt iets te simpel, tegenwoordig bestaat een pixel echt niet meer uit 1 waarde.
</snip>

Waarom wordt deze post op 3 interessant gerate??
Hieruit blijkt duidelijk dat je het niet helemaal begrijpt,
een dot product is namelijk gewoon een in product uit rekenen. Dit is een mathematische vector berekening en heeft NIETS te maken met een pixel...

[TheGhostInc]

Dus zal een 'goede' programmeur dus nooit kritiek hebben op een instructie set, hij kan er gebruik van maken, maar het hoeft niet. Het kan wel zijn dat hij/zij misschien een paar andere functionaliteiten wil, maar dingen zoals een dot tekenen klinkt iets te simpel, tegenwoordig bestaat een pixel echt niet meer uit 1 waarde.

* 786562 TheGhostInc

[Verwijderd]

(Reactie op Puzzle Solver)

Ik vindt deze voorstelling wat al te makkelijk. Het is de Game-Engine waarin veel Assembly wordt gebruikt. De engine is feitelijk een vrij laag-level stuk software, het moet alleen alle mogelijkheden van de hardware (en instructiesets) op een eenvoudigere manier aanbieden aan de programmeurs van een spel.

Het bouwen van een 3D-engine en het bouwen van een spel zijn totaal verschillende diciplines. Vaak zijn het ook verschillende teams van specialisten. Tegenwoordig wordt de Game-Engine vaak in zijn geheel gekocht door de makers van een spel. (voorbeeld: De Unreal- en de Quake-engines zijn al aan vele spelfabrikanten verkocht)

De instructie-sets (en assembly) is dus wel degelijk van belang voor de Game-Engine specialisten. Maar je hebt gelijk wat betreft de Spel-programmeurs, die programmeren gewoonlijk in C(++) ofzo..

[Verwijderd]

Als ik me goed herinner bevat Quake3 geen enkele regel assemblercode. Carmack was daar heel streng in, alles in ANSI-C want het moest op allerlei platforms kunnen lopen (mac, unix, etc)

[jkf]

De meeste compilers regelen slechts zeer beperkt extended instructie sets. Aanzetten of uitzetten gaat dan nog wel, maar dusdanige code genereren dat het meest efficiente gedaan wordt als het op meerdere verschillende processoren moet draaien doen compilers helaas niet. Bij closed source software zit er dus niets anders op dan
1 - voor elke processor apart geoptimaliseerde code te leveren
2 -constructies te bouwen als
case processor of
i386
code voor 386 processoren
i386 + fpu
code voor 386 processoren met math coprocessor
i486
code voor 486 processoren
i486 + fpu
code voor 486 processoren met math coprocessor of 486 DX
pentium + fpu
code voor pentium processoren
pentium + mmx + fpu
code voor pentium mmx processoren
i686 + fpu
code voor pentium pro processoren
i686 + mmx + fpu
code voor Pentium II / Celeron I
i686 + mmx + sse + fpu
code voor Pentium III / Celeron II
i786 + mmx + sse + sse2 + fpu
code voor Pentium IV
K6 + 3DNow + fpu
code voor AMD K6 met 3DNow
K7 + 3DNow + mmx + fpu
code voor Athlon / thunderbird
K8 + 3DNow2 + mmx + sse + fpu
.....
end case;
of
3 - Verschillend gecompileerde DLLs bouwen en tegen je applicatie linken

Dit houdt je code niet echt compact houdt en het geeft je de mogelijkheid zeer obscure fouten in je code te verbergen.

Voor die processor wordt helaas geen driver meegeleverd zodat ze er allemaal hetzelfde uitzien, voor de videokaarten wel,

Voor alle videokaarten met recente drivers kan een bepaalde Direct3D call worden gedaan, die driver maakt gebruik van de mogelijkheden van de videokaart zodat het bij de ene videokaart 1000 x zo snel gaat dan bij de andere, maar de instructie die de programmeur ziet is in beide gevallen dezelfde.

[Sharky K.]

Hij is wel erg tevreden over Altivech.
Is hij daar zo enthousiast over omdat het makkelijk is of omdat het zoveel extra performance levert?

Ik dacht dat 3DNow echt voor 3D was, heb er niet echt over gelezen maar de naam zou het toch moeten aangeven?

[.oisyn]

Ik dacht dat 3DNow echt voor 3D was, heb er niet echt over gelezen maar de naam zou het toch moeten aangeven?

Nee, zie ook mijn reactie ongeveer bovenaan de thread.
Wat je met 3dnow kunt is instructies op 2 waarden tegelijk laten uitvoeren, dus bijvoorbeeld A * C en B * D in 1 instructie (dit is dus SIMD, Single Instruction Multiple Data), maar wat het verder met 3d te maken heeft weet ik ook niet.
Het nuttigste vind ik nog het uitrekenen van 1/sqrt(getal) in een instructie (en de uitkomts kun je dan nog verder bewerken voor meer precisie, maar dat maakt het wel langzamer), maar dit is het enige waarmee ik de link kan leggen naar 3d.

Maar goed, verder wel een nuttige instructieset, maar wat het met 3d te maken heeft

/edit: B * D werd een B zonder spaties

[Verwijderd]

3dnow heeft het volgende met 3d te maken:

3dnow maakt het mogelijk om vectoren sneller uit te rekenen. Omdat je bij 3d altijd vectoren gebruikt...

[SG]

yep dacht dat MMX integer bewerkingen versnel door een opcode en meerdere data integer

3dnow/SSE(2) doen dat met floating_point data wat erg veel gebruikt wordt in 3D

[Beaves]

Hij is wel erg tevreden over Altivech.
Is hij daar zo enthousiast over omdat het makkelijk is of omdat het zoveel extra performance levert?

Ik denk beide, Altivec is heel krachtig en is makkelijker te implementeren in je programma dan MMX/SSE/SSE2.

Ik heb een aardige link gevonden waarin ingaan wordt op de verschillen en de technieken achter Altivec en MMX. Natuurlijk is MMX alweer verouderd, maar de besproken Altivec unit is ook al weer vervangen door een nieuwe in de G4e van Motorola. www.mackido.com/Hardware/AltiVecVsMMX.html

edit:

Je kan ook eens bij www.altivec.org kijken voor wat meer info.

[WoutF]

Het is natuurlijk wel leuk dat ze hier vertellen dat het eigenlijk nogal nutteloos is, maar dat geld dus wel alleen voor games. In applicaties als Photoshop geven de SSE instructies volgens mij een behoorlijke boost

[SG]

In gevallen waar 'n applicatie voornamelijk CPU power nodig heeft heeft het zeker nut 3Dstudiomax software renderen

games hebben meer baat bij krachtigere Grafische kaaart

[JeroenB]

Wat Carmack in het stukje zegt is heel belangrijk en is helaas niet gequote hierboven: bij een snellere 3d kaart of eentje met speciale features kan je die gebruiken om de framerate op te krikken of om de graphics mooier te maken.

Bij de werkzaamheden van de CPU zoals AI en physics is dat veel moeilijker, dat moet juist *overal* hetzelfde lopen. Je kan niet zeggen bijvoorbeeld: als je een P4 hebt dan is de computerplayer slimmer, of als je een Athlon hebt dan klopt de zwaartekracht beter.

Hierdoor maken ze niet veel gebruik van deze features, omdat ze er toch niet echt veel mee kunnen winnen.

[Verwijderd]

maakt het eigenlijk nog wel uit?
zonder optimalisaties heeft programma X, laten we zeggen 0.00004 seconden nodig voor opdracht Z, terwijl met optimalisaties hetzelfde programma X maar (sic) 0.00003 seconden meer nodig heeft voor opdracht Z.
Misschien duidelijker stellen, met optimalisaties draait een game op en deftige resolutie aan pakweg 80FPS, zonder aan 70FPS
Heel mooi hoor...

[pissed en offtopic mode]
AAAAAAAAAAAAAHH, je weet pas wie je vrienden zijn als je ze nodig hebt
[/pissed en offtopic mode]

[Verwijderd]

maar ik wil nog wel een verklaring waarom Quake sneller op intel draait dan op AMD...

Het komt omdat Quake 3 Arena niet zo zeer op de processor zelf leunt maar op de "memory sub-system" dwz de snelheid van je totale geheugen doorvoer en een snelle GeForce kaart. De P4's L2 cache is superieur wat latency betreft. 9 cycles vs 11 tot 20 cycles voor de Athlon. Het is duidelijk te zien hoe belangrijk geheugen is in Quake als je hier naar kijkt, http://www.tecchannel.de/hardware/740/8.html daar is een Athlon 1.4Ghz sneller dan een P4 1,5Ghz met PC133 SDRAM.

Hardware prefetch, graphics driver met specifieke optimalisaties, 400Mhz FSB en snel geheugen zorgen ervoor dat de P4 ongeevenaard is wat Q3A betreft. Met name Hardware prefetch schijnt een belangrijk bijdrage te leveren, Athlon 4 presteert een stuk beter klok voor klok dan de TBird als het om Q3A gaat vanwege de Hardware prefetch.

Even ter aanvulling, Serious Sam bijv heeft een engine die relatief aan Q3A gezien veel meer van je processor vraagt dan van je videokaart.

[Verwijderd]

>maar ik wil nog wel een verklaring waarom Quake sneller op intel draait dan op AMD...<
Je bedoelt de P4 duidelijk, en het antwoord daarvoor is zeer simple, memory bandbreete & SSE2 ...
De instructies zijn zwaar voorzien voor SSE2 in Q3 en sinds de P4 gedesigned is voor max effect te hebben van deze functies, heeft men daarmee alleen al een verbetering. En het feit dat de P4 op 400Mhz memory draait, zal er ook wel iets aan geven sinds dat Q3 nogal zware texture heeft ...

[.oisyn]

De zwaarte van de textures hebben er niets mee te maken omdat de textures worden opgeslagen in het geheugen van je videokaart.

[Verwijderd]

toch wel, want die moete door het RAM voor ze op de videokaart raken, extra bandbreedte is dus belangrijk

[SG]

zolang alle textures in videomem passen bij 64MB of meer textures gebruik je ook de AGP bus ook voor textures

[Verwijderd]

Omdat Nvidia gek is op Intel.

Volgens mij is een P4 1,4 langzamer dan een Athlon 1,4 hoor.

[bobsnl]

Precies andersom dus...nVidia werkt meer samen met AMD dan met Intel. De eerste optimalisatie voor de GeForce 256 waren dan ook voor de Athlon en niet voor de P3.

[.oisyn]

idd, en dan is er nog de nForce chipset voor de Athlon

[mister X630]

[behulpzaam-modus]

Volgens mij is SSE2 wel ff iets nieuwer dan 3DNow!
Ze moesten SSE2 eens met 3DNow2! vergelijken, dan is AMD wel ff iets beter!

* 786562 mister

Je had

"...dan is AMD wel ff iets beter!"

weg moeten laten, dan was het een goede opmerking geweest. maar doordat je dat er wel bij hebt staan ben je aan het flaimen en kom je dus op een negative score uit.
[/behulpzaam-modus]

edit:

typ-foutje

[Verwijderd]

Dit zijn slechts de meningen van 2 game ontwikkelaars, en dat die liever andere snellere features geintegreerd zien in videokaarten is natuurlijk logisch.

SSE2 en 3Dnow zijn features in een processor, waar softwareontwikkelaars weer meer aan hebben, lijkt me.

Wat je ook niet moet vergeten is dat als een OS bepaalde features van een proc ondersteund, of aanvullingen op een OS (directX) en daardoor sneller loopt, de aansturing van de videokaartfeatures automatisch ook snelle rgaat, waardoor het hele spel ook weer sneller loopt

toch?

[SG]

Bench marks hebben dat aangetoond dat de er bij de Grafische kaart de meeste performance kan worden behaald dan met de CPU

Dus als je 'n snelle CPU hebt en je maak gebruik van de DirectX HAL T&L Dan zit de GPU zich uit te sloven terwijl de CPU de T&L voert met data waarbij de geheugenbandbreedte vaak belangrijker is dan de CPU zelf.

De CPU genereerd bandbreedte door data (3D world) te sturen naar de GPU die dit dan moet verwerken

Dus als je Code optimalizeerd voor de CPU heb je veel geringere performance winst dan dat je de code die de T&L aanstuurd optimalizeerd.
Code optimalizatie kost tijd en geld dus kiezen ze voor optimalizatie waar het effect het grootst is de T&L aansturing van de game code.

Ik denk dat de driver bouwers er het meeste profeit aan hebben in die game industrie daar gebruikt men die extra instruktie set.

Wat directX betreft voor de HAL maakt het niet uit want dat is vaak driver code van de hardware die is vaak ook geoptimalizeerd maar hier speel de hardware zelf de grootste rol.

Maar de HEL is software emulatie die dusgebruik maak van de CPU hier is code optimalizatie van belang met SSE(2)/3Dnow anders was de HEL aansturing extreem trager dan de HAL tov optimized HEL zoals die nu al is.

[BadRespawn]

"Bench marks hebben dat aangetoond dat de er bij de Grafische kaart de meeste performance kan worden behaald dan met de CPU."

Dat kan je niet zo algemeen stellen. Met een P3 1GHz heb je echt wel voordeel van een GF2 tov een TNT2 oid, terwijl een nog snellere CPU daar weinig uit zal maken voor de framerate. Hangt er ook van af op wat voor resolutie je draait.

-

[SG]

Ze zeggen dat de Grafische kaart met z'n features T&L belangrijker is dan de CPU.CPU's(FPU) zijn al krachtig genoeg zonder extra instuktieset die ook lastiger te implementeren en vaak niet echt nodig omdat de performance in de T&L unit wordt gehaald die voor die berekeningen efficenter is.

Vele reviews hebben al aangetoond met benches dat de grafische kaart vaak de bottleneck is.

[.oisyn]

nee eigenlijk zeggen ze dat ze geen reet aan de huidige uitbreidingen hebben en liever hadden gezien dat een soort van instructieset als bij vertex shaders op de CPU was gekomen, omdat je daar gewoon gigantisch veel mee kan

eerlijk gezegd was dit ook mijn mening toen ik voor het eerst in 3dnow! programmeerde... Hoewel ik de nieuwe instructies wel nuttig vond, zag ik er verder niet in wat er zo 3D aan was

[Verwijderd]

hmm , vergis je niet , een P4 is nog altijd sneller dan een AMD TB wat multimedia toepassingen betreft , er zijn echter 2 nadelen , de software is momenteel niet geoptimalizeerd voor de p4 en de kosten zijn het niet waard.

[SG]

Het geheugen systeem heeft 'n grote bandbreedte maar ook 'n hoge latency De CPU kan goed gebruik maken van die bandbreedte maar heeft ook 'n nadeel van de 20 stage pipeline wat grote branch mis predicties kan op leveren.

Dus de P4 paltform heeft grote voordeel maar ook met 'n grote nadeel hierdoor is ie in de ene toepassing rete goed en in een andere rete slecht en de rest zit daar ergens tussen in .