Nvidia's Cuda-systeem nader bekeken

Ruim een week geleden gaf nVidia de publieke bèta van zijn gpgpu-systeem Cuda voor de G80-core vrij. De mogelijkheden van dit systeem van de graphicsfabrikant zijn door programmeur Bryan O'Sullivan nader bekeken.

O'Sullivan heeft zelf gewerkt aan een compiler waarop nvcc - de compiler van Cuda - is gebaseerd. Zijn voornaamste conclusie is dat het programmeren voor de gpu ontzettend complex is. Nvidia heeft een set extensies op de C-programmeertaal uitgebracht om de programmeur te ondersteunen bij het programmeren voor de gpu. Deze extensies zijn voornamelijk bedoeld om het geheugenbeheer te vereenvoudigen. De uitbreidingen zijn volgens O'Sullivan echter minimaal. Het betreft hoofdzakelijk commando's om te bepalen op welke locatie in het geheugen variabelen een plaatsje moeten vinden. Enkele andere onderdelen van de nVidia-extensies zijn extra OpenGL-achtige vectortypes en een aantal keywords die functies definiëren.

Een gpu is vooral geschikt om rekenintensieve code uit te voeren. De kracht ligt in het feit dat de grafische processor uitermate geschikt is om code parallel uit te voeren; de gpu op de GeForce 8800 GTX heeft 128 cores, of eigenlijk streamprocessors, ter beschikking. Het uitvoeren van code op de gpu gebeurt in verschillende threads. Deze threads zijn weer gegroepeerd in blokken en meerdere blokken vormen ten slotte een grid. Iedere thread heeft een eigen stuk geheugen en alle threads in een blok delen een gedeelte van het geheugen. Via het gedeelde geheugen worden de threads binnen een blok gesynchroniseerd. Een thread heeft ook toegang tot het globale geheugen van de gpu, maar kan slechts via het gedeelde geheugen van een blok synchroniseren.

nVidia gpu architectuur (klik voor groter)

De complexe indeling van het geheugen zal menig programmeur slapeloze nachten bezorgen. Ten eerste zorgt het globale geheugen voor een aantal obstakels. Er is niet slechts één type globaal geheugen maar drie verschillende soorten. Het gewone lees- en schrijfgeheugen, global memory, is het eerste type. Het aanspreken van dit geheugen kan niet gecached worden en de programmeur moet er zorg voor dragen dat het gebruik ervan door een blok threads op exact de juiste manier gebeurt. Afwijken van het formaat zal de verwerkingssnelheid niet ten goede komen. Het tweede type geheugen, constant memory, is read-only en de toegang kan gecached worden. Ook bij dit type geheugen moeten strikte richtlijnen worden gevolgd. Het laatste soort globale geheugen is texture memory, wederom read-only en met mogelijkheden tot caching. Dit geheugen is het meest geschikt voor het opslaan van 2d-textures.

nVidia gpu geheugenmodel (klik voor groter)

Het geheugen dat door een blok gedeeld wordt heeft ook een aantal eigenaardigheden die de snelheid kunnen beïnvloeden. Het is over meerdere banken verdeeld zodat het parallel aangesproken kan worden: n threads kunnen n geheugenbanken aanspreken binnen een kloktik. De toegang tot een enkele bank door verschillende threads zal echter serieel plaatsvinden. Dat betekent dat als n threads een bank aanspreken het n kloktikken zal kosten om alle data te verwerken. De verschillende typen geheugen, met elk hun eigenaardigheden, zorgen ervoor dat de programmeur erg goed het geheugenbeheer van de gpu onder de knie moet hebben.

Gezien dit complexe geheugenbeheer zou een goede compiler veel kunnen betekenen voor de snelheid van een applicatie. De nvcc-compiler is gebaseerd op EkoPath, een compiler die onder andere veel gebruikt is om benchmarkapplicaties voor het AMD64-platform te compileren. De Ekopath-compiler is weer gebaseerd op de Open64-compiler van SGI. De voorouders van de nvcc-compiler beschikken over groot aantal geavanceerde functies om het geheugenbeheer te optimaliseren. Gezien de controle die een programmeur over het geheugen heeft vermoedt O'Sullivan echter dat op dit moment weinig van die optimalisaties hun weg naar de compiler van nVidia hebben gevonden. Ook het feit dat de handleiding uitgebreid ingaat op conflicten die kunnen optreden bij het aanspreken van verschillende geheugenbanken sterkt hem in dit vermoeden.

De gpu biedt in theorie een grote rekenkracht, vooral voor hele specifieke applicaties waarbij pure rekenkracht nodig is. O'Sullivan denkt echter dat de complexiteit een volledige benutting van de capaciteit moeilijk zal maken. Hoewel een enkele bezoeker van het blog kritisch tegenover deze gevolgtrekking staat lijkt de conclusie dat het programmeren voor de gpu in dit stadium niet voor iedereen weggelegd is te rechtvaardigen. Toch is de toekomst wel rooskleurig voor deze techniek. Verschillende bedrijven die baat hebben bij veel brute rekenkracht, bijvoorbeeld op het gebied van cryptoanalyse, zullen ook wel de middelen en tijd hebben om te investeren in het ontwikkelen op de grafische processor.

Reacties (33)

[Verwijderd]

Wat een ongeloflijk interessant artikel. Dank U wel Tweakers .
Wat men alleen wel vergeet is dat _hun_ compiler nu misschien erg ingewikkeld en onhandig is, maar dat het in de software development niet ongebruikelijk is om dat een compiler te hebben die weer een andere, lagere, programmeertaal output.

Iemand die dus heel veel met cryptocrafie wilt doen, zal dus vermoedelijk een DSL'tje ontwikkelen daarvoor.(domain-specific-language).

De output van die DSL compiler zou dan weer de input zijn van deze NVCC compiler. Al je dit vergezocht vindt, besef dat dan op je linux-bak de helft van de ondersteunde programmeertalen naar C compileert om dat dan weer door gcc naar machiene code om te laten zetten. Op die manier kan je door alleen gcc compiler te schrijven een nieuw stukje hardware ondersteunen.

Misschien dat we een aantal intressante declaratieve talen gaan zien die hier gebruik van gaan maken.

In zoverre denk ik dan ook dat O'Sullivan een grote denk fout heeft gemaakt. De taal is waarschijnlijk niet bedoeld om direct in te programmeren, tenzij je veel gebruik maakt van template-programming. De doelstelling van deze taal lijkt mij toch echt om totale controle over performance en gedrag te krijgen. Niet om een maintainable programma te schrijven. Het is gewoon de onderste schakel van de compiler-tool-chain. NVidia levert die en de markt, academici en hobbyisten zullen de rest van de toolchain wel gaan leveren.

Wat niet wegneemt dat er geheid mensen zijn die een maintainable programma erin kunnen ontwikkelen en dat zullen gaan doen. Mensen doen dat al jaren in C. Terwijl ook dat niet meer dan een assembler on steroids is. Met disicpline kan je een trui met de hand breien, of het verstandig is, is een andere vraag.

[Punkie]

Theoretisch mogelijk. Ik denk echter dat de ontwikkeling van een hogere orde taal/tool die CUDA code genereert, onwenselijk is. En dit wel omdat C de taal is waarop dergelijk geheugenbeheer al op beschikbaar kan zijn. Hoe lager in de chain je dergelijke dingen plaatst, hoe performanter je kan schrijven. Een heel aantal optimisaties mbt geheugenbeheer zijn tenslotte geen highlevel features en zijn reeds in C aanwezig.

De maintanability van code voor een verder ontwikkelde CUDA compiler zou hierdoor veel groter worden. En ja, mensen WILLEN hiervoor coderen want tenslotte spreken we hier over nvidia die zelf wel de laatste druppel wilt eruit knijpen. Het is heus niet uitzonderlijk van een algoritme nog eens te herschrijven om meer uit een nieuwe architectuur te persen. Die mensen gaan heus niet veel performantie opofferen omdat ze een hogere orde beschrijving kunnen gebruiken. Voor hen is een verbeterde CUDA wel wenselijk.

[Verwijderd]

"Een heel aantal optimisaties mbt geheugenbeheer zijn tenslotte geen highlevel features en zijn reeds in C aanwezig."

Je vergeet twee dingen..

1. die optimalisaties zijn niet meer van toepassing.

Juist het geheugenbeheer is totaal anders. Daarnaast is de optimalisatie in de hardware. Geloof het of niet, de serieuze 3d engines hebben amper optimalisaties. Misschien op 10 specifieke plekken. In de Unreal engine komt bijvoorbeeld geen ASM kijken. Omdat maintainability belangrijker is, en performance vooral afhangt van hardware en algoritmische complexiteit. Beide soorten performance behaal je gemakkelijker met een iets vriendelijkere programmeertaal.

2. het leeuwendeel van de hogere programmeertalen heeft een compiler met een C backend.

Het maken van een C compiler is de manier om een stuk hardware te ondersteunen. Het is zeg maar de bottom van de tool-chain. De python interpreter bijvoorbeeld is in C geschreven. Haskell interpreters zijn in C geschreven. Perl is een C geschreven.

Als men Linux poort naar een nieuwe chip, dan begint men ook altijd met GCC. Daarna is het vooral een kwestie van alle andere development tools compileren met die compiler. Je bootstrapt dan als het ware het systeem vanaf daar.

NVidia's bedoeling is dus wel zeker dat de grafische chip de status te geven van een generieke proccesor, door met hun getweakde C compiler een bootstrapping mogelijkheid te bieden.

[Verwijderd]

Zoals ik het nu zie (en als ik de post goed gelezen heb) gebruikt men dus C++ en dergelijke code om de gpu aan te sturen. kan iemand dat iets duidelijker vertellen want wat er in die post staat is beetje onduidelijk (ben beetje leek met scripting )

@reacties
ja geen idee wat dat precies betekend, ik dacht dat ze doelden op C++ wist niet eens dat er programmeertaal bestand dat gewoon C heette maar tog bedankt, verdere uitleg is misschien wel makkelijk, ik denk dat er wel meer mensen zoals ik naar deze post kijken en denken: waar de n**k gaat dat over...

@knettergek
ja dat maakt het wel wat duidelijker das tenminste taal waar je wat van begrijpt. thnx dude... modereer die man ff behulpzaam

[Verwijderd]

Volgens O'Sullivan is het zo dat ondanks de brute rekenkracht die je ter beschikking gesteld wordt door een GPU, de complexiteit het op dit moment hartstikke moeilijk maakt applicaties hiervoor te schrijven, zelfs voor doorgewinterde programmeurs.

Gezien hoe complex dit memory management wordt (als je nie top precies de juiste kloktik vanuit precies het juiste process het juiste geheugenbankje weet te raken wordt het proces langzamer) is het nodig dat er eerst nog flink ontwikkeld wordt aan de compilers voor de programmeertaal.

De compiler is het programma waar je je programma-code (in bijvoorbeeld C of C++ of Visual Basic) door laat omzetten naar de machinetaal relevant voor waar je voor programmeert, in dit geval dus de machinetaal voor de nVidia chip die op je GPU zit. Als dat programma jouw code goed leest en zó optimaliseert dat het geheugenbeheer zo goed mogelijk gedaan wordt wordt het eenvoudiger om je programma's goed te laten werken.
Immers, als jij je bezig moet houden met welke nullen en éénen wanneer waar weggezet worden, ben je op een veel lager niveau, dus in veel dieper detail, bezig met wat je programma moet doen, en is het dús complexer.
Het is bijvoorbeeld dood simpel om even www.tweakers.net te openen in Firefox en een artikeltje te lezen. als je echter zelf met de hand de TCP/IP pakketjes moet schrijven om eerst het IP van www.tweakers.net op te vragen en vervolgens met de hand alle pakketjes moet schrijven om de pagina op te vragen dan wordt het even wat anders. Een goede compiler maakt dat jij als het ware kunt zeggen "open www.tweakers.net in Internet Explorer", geen goeie compiler maakt dat je meer dingen met de hand moet doen. Omdat de dingen die je met de hand moet doen vrij snel vrij technisch worden wordt het heel snel veel te complex voor normaal gebruik door normale mensen.

Helpt dit?

[borft]

tegelijkertijd is het ook weer zo, dat als jij zelf met de hand alle geheugen management doet, je wel veel meer kunt optimaliseren, omdat je meer aannames kunt doen dan de compiler! (zoals bijvoorbeeld bij asm ed)

[The Merovingian]

Je kúnt met de hand in assembler snellere code schrijven, maar dan moet je ontzettend goed weten wat de processor doet! De gemiddelde compiler is ontzettend goed geoptimaliseerd en in assembler werken heeft dan helemaal geen zin. Een vriend van mij heeft tests uitgevoerd en het bleek dat de assembler code die hij op zijn best schreef toch nog langzamer was dan wat een gemiddelde compiler ervan maakte.

Neem dus niet zonder meer aan dat je code sneller is als je het in assembler schrijft.

Het is wel zo dat je er vanwege die ingewikkelde geheugentoegang haast op kan rekenen dat de compiler hier fouten gaat maken, dus de kans bestaat dat assemblercode in dit geval wel sneller is. Maar de compiler zal snel genoeg geoptimaliseerd worden en dan zal het voordeel van assembler nog maar minimaal zijn.

[gumkop]

Een vriend van mij heeft tests uitgevoerd en het bleek dat de assembler code die hij op zijn best schreef toch nog langzamer was dan wat een gemiddelde compiler ervan maakte.

Hier zet ik echt mijn vraagtekens bij, direct in assembly geschreven code is het snelste wat je maar kunt maken. Probeer deze deze eens en sta versteld.

[Verwijderd]

Bijkomend kan je er dus enkel 32 bit floating point berekeningen mee doen, niet 64 bit. Voor een aantal applicaties is dit onvoldoende.

[TheekAzzaBreek]

Even de bronnen nakijken: plain C, dus.

Edit: het verschil tussen C en C++ is wel erg offtopic, en heel Googlebaar, maar vooruit: C is een 3e generatie programmeertaal uit de jaren 60. Midden '70 is daar een object-georienteerde variant uit ontwikkeld, die sindsdien model heeft gestaan voor een hele berg andere OO talen.

[Sebazzz]

Waarschijnlijk een pain in the *ss voor Microsoft met hun C#

[bbob]

De beperkende factor in het toenemen van snelheid is dus niet langer meer de cpu of gpu maar gewoon software.

Ook bij cpu gaat men naar 4 of in de toekomst meer cpu's op 1 chip. Veel software ondersteund dat nu al niet echt goed.

De nieuwe weg naar echte snelheidsverbetering zal dus liggen in goede software.

[Zwartoog]

De beperkende factor in het toenemen van snelheid is dus niet langer meer de cpu of gpu maar gewoon software.

Dat is altijd zo. Je hebt altijd software nodig hebt om de hardware aan te sturen, en software altijd voor verbetering vatbaar is (danwel de implementatie, danwel gebruik van betere algorithmen (die misschien nog niet ontdekt zijn)).

Stel je wilt 2+6 uitrekenen door 6 keer 1 bij 2 op te tellen. Dan benut je de processor dus niet optimaal.

Of je wilt (5+2)*(6+3) uitrekenen. Kun je 'slim' met 3 operaties (twee keer optellen en dan vermenigvuldigen). Je kunt er ook voor kiezen om het uit te schrijven naar: 5*6+2*6+5*3+2*3 en dus 7 operaties gebruiken.

Nu zeg je 'Jah, makkelijk', maar neem bijvoorbeeld een rekenintensief polynoom met een variabele:

x^5+x^4+x^3+x^2+x+1

en neem even aan dat de processor niet kan machtsverheffen, dus elke x moet een aantal keer vermenigvuldigt worden (5+4+3+2 operaties) en optellen (5 keer), dus in totaal 19 operaties. Dit kun je 'slim' implementeren door:

1+x*(1+x*(1+x*(1+x*(x+1))))

en dit kost je 4 vermenigvuldigingen en 5 optellingen, dus bijna de helft van wat je eerst nodig had.

Ok, lange reactie, maar ik probeer duidelijk te maken dat software dus bijna altijd voor verbetering vatbaar is, alleen zijn wij te dom om het slimmer te doen

[Verwijderd]

de gpu op de GeForce 8800 GTX heeft 128 cores ter beschikking.

128 unified shaders zijn geen 128 cores.

[SnakeMind]

Beter opletten, uit het vorige bericht:

Dit is te danken aan het feit dat programmeurs de unified shaders van de gpu als onafhankelijke rekenaars kunnen benaderen. Met de GeForce 8800 GTX komen zo 128 1,1GHz-cores beschikbaar, waarmee parallele problemen aanzienlijk sneller kunnen worden opgelost.

[Verwijderd]

Juist, maar dan is ook dat bericht met een zwaar korreltje zout te nemen.

Een gewone single core CPU heeft ook meerdere ALU's waarmee hij - als je programma het gebruikt - meerdere optellingen en vermenigvuldigingen tegelijk kan uitvoeren.

Hier worden de 128 unified shaders als ALU's gebruikt, maar je kan dat dus bezwaarlijk als 128 cores bestempelen, tenminste als je het enigszins eerlijk wil vergelijken met een CPU.

[Verwijderd]

Een GPU is anders ingericht dan een cpu. Als we het over 1 shader core hebben, dan kan deze core meerdere instructies tegelijk uitvoeren in 1 cycle.

Om een simpel voorbeeld te geven:

Hij kan bijvoorbeeld de sinus van een hoek, een texture fetch, een dot product en een vector add allemaal tegelijk in 1 cycle uitvoeren (zijn slechts voorbeeldjes).

Dit kan hij, omdat hij meerdere units per core heeft die dit onafhankelijk van elkaar uitvoeren (een cpu heeft dit dus ook). Een shader compiler kan deze instructies dusdanig ordenen, dat deze dus als 1 VLIW (Very Long Instruction Word) 'instructie' naar alle onderdelen van de shader core gestuurd worden. Dit noemen ze in de shader compiler ook wel instruction scheduling. En dat heeft een cpu dus weer niet, die doet dit dynamisch. Dat noemen ze OOE. Out of Order Execution. De CPU gaat dus zoveel mogelijk onafhankelijke instructies naar de verschillende ALU poortjes schuiven om ze allemaal tegelijk uit te voeren.


Als je alle onderdelen van een shader core maximaal weet te benutten, door ze allemaal iets te doen te geven, dan haal je het optimale resultaat uit de shader. Daar haalt dat ding onder andere z'n snelheid uit.

Echter, de 8800 heeft 16 shader blocks. Dat wil zeggen, er zijn 16 blokken van 8 shader cores (volg je het nog?). Deze blokken draaien in lock step. Dat wil zeggen dat ze alle 8 dezelfde VLIW instruction uitvoeren. Dit is normaliter niet zo'n groot probleem, omdat bijvoorbeeld voor pixel shaders alle pixels op dezelfde manier berekend worden. En da's voor de chipbakkers van Nvidia en ATI lekker makkelijk, omdat ze dan maar 1x een instruction Word hoeven in te lezen voor 8 cores tegelijk (is dus weer een optimalisatie).

Verder hebben ze dus 'warping'. Als je de specs van CUDA doorleest kom je dat tegen. Waar het op neer komt is dat ze dus 8 threads pakken, instructie 1 uitvoeren, resultaat opslaan, nog 8 threads pakken, weer instructie 1 uitvoeren, etc. En als alle threads instructie 1 uitgevoerd hebben, dan naar instructie 2 gaan. Zo heb je (in dit geval voor 128 x 8 threads) maar 1 instruction fetch gedaan. Alle resultaten worden on chip opgeslagen, dus je memory bandbreedte is minimaal belast. Tevens gokken ze er op dat alle texture fetches redelijk spatieel coherent zijn, waardoor de texture cache goed z'n werk doet, dus nog minder bandbreedte vreet.

Ga je nou iets als CUDA doen, waar je in je code veel verschillende IF instructies er in zet, dan gaat dit ontwerp compleet over de zeik. Omdat die 8 cores dus verschillende instructies willen gaan uitvoeren en dus niet meer in sync kunnen lopen. Tevens is dat random memory access dus compleet tegenover gesteld aan wat de gpu probeert te bereiken. Weer een tegenslag.

De initiele critiek op de CUDA fora komt dan ook op dat verhaal neer. random memory access performance problemen, branching performance problemen, etc.

Tja, gpu programming is gewoon lastig, zeker als je free form code kan doen. En ja, je kan dus ook C++ code schrijven op CUDA.

[MikkieMaus]

Read-only memory? En hoe gaan wij dit vullen dan?! Ik neem aan dat ze bedoelen dat het schrijven naar dit geheugen niet direct door de shaders kan gebeuren maar via de CPU moet plaatsvinden, hetgeen dus traag is en alleen gebruikt zal worden voor bv. input variabelen voor de berekeningen die tijdens het rekenen wel vaak gebruikt worden maar niet veranderen.

[Jooz]

Of door de GPU zelf, dat deze berekende data op het geheugen zet dat bruikbaar is voor andere zodat het "normale" geheugen hier niet onder lijdt

[catfish]

waarschijnlijk is dit een deel dat normaal gebruikt wordt voor texture memory, wat dus enkel als cache gebruikt wordt

de gpu kan dan dingen opvragen aan het systeem (dit hoeft niet altijd via de cpu te gaan), maar kan dit zelf niet wijzigen

[Verwijderd]

The return of the co-processor <smiles>

[Indigo]

Ik volg de ontwikkelingen over CUDA op de voet. Zelf probeerde ik ook wat te schrijven, maar levert alleen maar errors op. Op de fora is het ook duidelijk dat het te complex is.

De software is niet per se bedoeld voor de gemiddelde computeraar, maar juist voor programma's die veel berekeningen hebben. Ik werk in de academische wereld, maar dat wilt niet zeggen dat we meer ervaring hebben met C++ of andere scripttaal. Pas als ze software ontwikkelen zodat het voor de gemiddelde tweaker toepasbaar is, wordt het voor de wetenschappelijke wereld interessant.

[Verwijderd]

Ik werk in de academische wereld, maar dat wilt niet zeggen dat we meer ervaring hebben met C++ of andere scripttaal.

In de academische wereld waar ik een tijdje terug in zat was C++ in elk geval de standaard. Als je wilt optimaliseren voor snelheid kan je bijna niet zonder. Ik denk niet dat C# daar veel verandering in gebracht heeft.

Pas als ze software ontwikkelen zodat het voor de gemiddelde tweaker toepasbaar is, wordt het voor de wetenschappelijke wereld interessant.

Ik denk niet dat de gemiddelde tweaker veel verstand heeft van code schrijven, en zeker geen HPC code. Ik zou het trouwens net andersom stellen: voor de wetenschappelijke wereld is het juist wél interessant (ook al is het wat moeilijker te implementeren).

Ik heb me zelf ook nog niet beziggehouden met het programmeren van GPU's voor HPC. Zoals hierboven reeds vermeld werd, is het gebruik van GPU voor HPC redelijk beperkt. Vergeet niet dat een GPU een superparallelle, high latency stream processor is, met beperkte functionaliteit (het is geen cpu) en met bv beperkte mogelijkheden qua geheugenaddressering. Tevens kunnen de huidige GPU's enkel 32 bit floating point math aan, en niet de standaard 64 bit met dubbele precisie.

De idee om GPU en CPU te integreren lijkt me echter veelbelovend op termijn.

[borft]

Als het programmeren echt zo ingewikkeld is, dan zijn de programmeurs avn de nvidia drivers dus ontzettende helden!

[bokkow]

Nee want dan wordt de G80 gebruikt waar hij voor bedoeld is en programmeertaal voor is waar vanaf de allereerste G-chip ervaring mee op is gedaan. Nu proberen ze hem op een heel ander vlak zijn rekenkracht te benutten; een stuk lastiger dus want je begint van onderaf taal hiervoor te programmeren waar hij mee om kan gaan...

[Verwijderd]

Ik weet niet of iemand ooit een DSP geprogrammeerd heeft. Dit is net als een GPU een vector reken unit.

Dit is een totaal andere tak van sport dan een programmeren op een CPU (Het is trouwens puur wat je gewent bent). Nog extremer dan de overstap van conventioneel programmeren naar object georiënteerd.

Mogelijk is een GPU nog complexer dan een DSP programmeren.

Ik kan me daarom best voorstellen dat de schrijver het programmeren moeilijk vindt.

[Ventieldopje]

@padawan_009
In dit artikel staat dat ze extensies hebben gemaakt op de C programmeertaal dus niet C++

[Dnomaid]

Whoah!

Nu kan ik eindelijk op het werk rechtvaardigen waarom ik een GeForce 8800GTX nodig heb!