Het huwelijk van gpu en cpu

Conclusie: developers, developers, developers

Gpu's bieden enorme mogelijkheden. Supercomputers worden ingezet voor de analyse van grote hoeveelheden data, zoals met de molecuul-simulaties van Amber maar ook voor het vinden van olie- en gasvelden. Er zijn echter nog geen toepassingen die niet met cpu's kunnen worden uitgevoerd, en het is ook nog eens een behoorlijke verandering voor programmeurs.

Met parallelle verwerking kunnen veel problemen echter wel sneller worden opgelost, en, nog belangrijker, het rendement van gpu's ligt hoger. De voornaamste reden dat cpu-cores niet veel sneller meer zullen worden, is dat ze anders te veel energie verbruiken. Een gpu kan per watt meer berekeningen uitvoeren dan een cpu, waarvan grote delen bij het verwerken van parallelle data onbenut blijven - maar wel energie verbruiken. Datacenters verbruiken bijna net zoveel energie voor het afvoeren van warmte als voor de voeding van processors, maar ook bij smartphones en laptops is energieverbruik een zeer zwaarwegend criterium. Elke winst op dit terrein is dus meegenomen.

Intel bracht zoals gezegd de Xeon Phi uit, maar ook de consumentenchips van dit bedrijf beschikken tegenwoordig over een degelijke gpu, met DirectX 11-ondersteuning en daarmee ook met ondersteuning voor OpenCL en DirectCompute. De Haswell-cpu's die volgend jaar verschijnen, zouden opnieuw een snellere gpu aan boord hebben.

Ook AMD's Fusion-apu's herbergen zowel een cpu als een gpu. De Llano-apu's zijn onlangs opgevolgd door de Trinity-chips, maar op de Fusion Developer Summit werd de volgende generatie alweer aangekondigd. De Steamroller-apu's, die volgend jaar moeten verschijnen, zijn vooral interessant omdat cpu en gpu het geheugen volledig kunnen delen. Daarmee wordt het makkelijker om voor een bepaalde bewerking de cpu of juist de gpu te gebruiken, terwijl de resultaten van een berekening voor beide componenten toegankelijk zijn.

Hoewel we het vooral over desktops en laptops hebben gehad, bewijst de deelname van Imagination en ARM aan de HSA-foundation dat heteregeneous computing ook op smartphones en tablets toekomst heeft. De razendsnelle maar specialistische en niet erg flexibele fixed-functionhardware, zoals Intels QuickSync, laten we maar even buiten beschouwing: gpu's zijn immers alomtegenwoordig. Het leeuwendeel van alle toekomstige cpu's zal een gpu aan boord hebben, er is een installed base van honderden miljoenen videokaarten en ook smartphones krijgen steeds krachtiger gpu's in hun soc's.

De vraag is dus met welke applicaties de consument tot aanschaf zal worden verleid. Volgens Microsoft gaan aanraakgevoelige schermen, gezichtsherkenning en 3d-beelden een grote rol spelen, zo liet het bedrijf op AMD's conferentie weten, en uiteraard zijn dat allemaal toepassingen die uitermate geschikt zijn voor throughput-processors - oftewel gpu's. Andere velden waar de extra rekenkracht van pas kan komen zijn augmented reality en biometrische herkenning. Zo kan je denken aan het sorteren van homevideo's aan de hand van de gezichten en stemmen die erin voorkomen, of aan Googles Project Glass, dat bijvoorbeeld naadloze graphics over afbeeldingen van een gebouw kan projecteren, zodat je kan zien hoe iets er vroeger uitzag of hoe iets eruit zou kunnen zien. Al deze toepassingen zullen zich echter nog in de praktijk moeten bewijzen.

Voor een echte doorbraak zal vermoedelijk toch het programmeren voor de gpu gemakkelijker moeten worden. Intel denkt dat gpu's met x86-ondersteuning een goede oplossing zijn, AMD werkt aan Fusion-apu's waarbij gpu en cpu hetzelfde geheugen gebruiken, en Nvidia is met zijn Cuda-platform in elk geval ervaring aan het opdoen. Er zijn dus in elk geval een aantal bruikbare mogelijkheden, en daarmee komt het lot van general purpose-gpu's nu in handen van de ontwikkelaars te liggen. Als zij het heterogene programmeren omarmen, kunnen we in de komende jaren een grote vlucht voor de geparallelliseerde toepassingen verwachten.

Reacties (74)

Voor een echte doorbraak zal vermoedelijk toch het programmeren voor de gpu gemakkelijker moeten worden.

Microsoft is hier hard mee bezig met hun C++ AMP. Met de integratie in Visual Studio 2012 (o.a. GPU debuggers) moet het maken van software die zowel op CPU als GPU draait een stuk makkelijker worden.
http://www.danielmoth.com/Blog/Get-Started-With-C-AMP.aspx

Daar is NVidia al veel langer en AMD/ATI al een behoorlijke tijd mee bezig hoor. Het resultaat: http://en.wikipedia.org/wiki/OpenCL een afgeleidde van het door NVidia ontworpen http://en.wikipedia.org/wiki/CUDA

Ik kon drie jaar geleden al debuggen van GPU-processen. Alleen het porten van CPU naar GPU threads is/was wat lastiger.

Iedere boerenpummel met een CUDA / OpenCL-supported GPU kan zo eenvoudig programmeren.

Daarnaast, als je echte rekenkracht wilt, zul je toch naar FPGA's moeten kijken. Velen malen sneller dan GPU's omdat alle processen parallel worden uitgevoerd. Ze zijn helaas veel minder goed in floats en dergelijke, maar om dat probleem te tackelen, zou je naar Fixed-point arithmetic kunnen kijken.

[Reactie gewijzigd door Matis op 2 augustus 2012 09:24]

NVIDIA en AMD/ATI zijn daar inderdaad al lang mee bezig.

Maar het grote voordeel van C++ AMP is dat exact dezelfde code ook op een gewone CPU kan draaien. Sterker nog: C++ AMP kan dezelfde code op zowel CPU als GPU tegelijk uitvoeren. CPU en GPU doen samen dezelfde berekening.

Deze eigenschap maakt het mogelijk dat mainstream software eerder gebruik gaat maken van GPU-berekeningen omdat de berekening ook werkt op computers zonder gpGPU.

Ook dat is (theoretisch) niet anders met OpenCL. Elk "render"apparaat kan zichzelf aanbieden als OpenCL target, en naar mijn weten doen zowel AMD als Intel dit. De programmeur blijft wel aan de knoppen, hij zal naar niet-GPU apparaten moeten query'en. Mocht hij er van overtuigd zijn dat zijn eigen CPU implementatie sneller is, dan kan hij dat dus net zo makkelijk _niet_ doen. Er is meer handwerk, maar de features zijn er wel!

Zoals je zegt moet je bij OpenCL naar apparaten query'en, de kernel compilen (geschreven in OpenCL) en dan deze kernel uitvoeren.

De charme van C++ AMP is dat de programmeur zich niet met deze zaken hoeft bezig te houden. Alles schrijf je in C++ en de rest wordt door de compiler en library geregeld.

Zie hier een volledig werkend C++ AMP programma (gebruikmakend van Lambda expressie):

#include <iostream>
#include <amp.h>
using namespace concurrency;
int main()
{
int v[11] = {'G', 'd', 'k', 'k', 'n', 31, 'v', 'n', 'q', 'k', 'c'};

array_view<int> av(11, v);
parallel_for_each(av.extent, [=](index<1> idx) restrict(amp)
{
av[idx] += 1;
});

for(unsigned int i = 0; i < av.extent.size(); i++)
std::cout << static_cast<char>(av(i));
}

Bron: http://blogs.msdn.com/b/n...-world-quot-in-c-amp.aspx

Eigenlijk probeer ik te zeggen dat de instap voor C++ AMP lager is dan voor OpenCL of CUDA vanwege de simpele opzet en toepasbaarheid.

Maar zoals het artikel al zegt, zolang programmeurs geen gebruik maken van de mogelijkheden van de gpGPU blijft een groot stuk van de computer onbenut. Vraag is of een normale gebruiker dit nodig heeft ...

[Reactie gewijzigd door erikloman op 2 augustus 2012 12:18]

Jouw post toont duidelijk aan waarom GPGPU voor het gros van de applicaties geen nut heeft.
Om efficient te werken moet je gewoon data parallellisme hebben. Task parallellisme is dood.
(Zie ook het mooie stukje op http://www.drdobbs.com/pa...-does-not-exist/240004626)

Het probleem is dat je maar een handvol data-parallelle toepassingen hebt, zoals games/3D/..., wetenschappelijke berekeningen, video/audio/image processing, ...
Mijn office-suite of browser gaat helemaal niet sneller draaien met GPGPU en laat net dat zijn waar de consument het gros van zijn tijd in stopt. Data-latency (bvb downloaden van een webpage) is daar bovendien een bijkomend probleem.

Bijkomend probleem is dat de gemiddelde 'programmeur' helemaal niet met multi-threading/-processing om kan. SIMD (wat je trouwens op de CPU ook hebt) lukt nog wel, maar daar heb je ofwel een slimme compiler voor nodig, ofwel moet je't zelf doen - wat dan weer een stapje hoger op de ladder is.

Ik was ook super-enthousiast over SMP, maar die enthousiasme is de laatste jaren wel aan het bekoelen. AMP zie ik nog iets in (denk aan het big.Little concept) voor power-aware devices. Blijkbaar denken Intel/AMD hier ook zo over aangezien de consumenten markt max 6-8 cores voorgeschoteld krijgt en ze nu naar GPGPU over willen.
Maar of die GPGPU hen zal redden? Het zal zijn (beperkte) toepassingen hebben, maar ik betwijfel dat het _de_ oplossing voor de komende paar jaar is.

Als ik op de hier gegeven Wikipedia link kijk dan is dat kernel verhaal pas sinds versie 1.2 van OpenCL zo. In 1.0 en 1.1 zit dit niet. Je hoeft dus helemaal niet de kernel te compileren, je kan dat doen mits OpenCL 1.2 wordt ondersteund. Dat kernel verhaal is in OpenCL gestopt om bepaalde stukken hardware nog hechter te kunnen integreren. Dat zou je in staat moeten stellen om andere hardware dan de cpu of gpu te kunnen gebruiken voor berekeningen (denk aan je geluidskaart). Het is nog maar de vraag in hoeverre je dat wil en in hoeverre dat zinnig is. Er zijn namelijk zat machines waarbij een geluidskaart niet nodig is en dit soort hardware er dan ook niet in zit. Als dit soort hardware voor een aanzienlijke performancewinst kan zorgen dan wordt het inbouwen er van natuurlijk wel aanzienlijk interessanter.

Als ik verder kijk naar wat er inmiddels al OpenCL ondersteund dan is dat erg veel. Als Microsoft wat van dat C++ AMP wil gaan maken zal het dit ook moeten doen. De sectoren die er baat bij hebben draaien over het algemeen geen Windows. Sommigen zullen het doen maar zeer zeker niet iedereen, het is een mix van operating systems. Als ik kijk naar wat Microsoft aan support voor niet-Windows en niet-Macs biedt is dat verre van rooskleurig. Daar valt nog heel wat te verbeteren. Iets kan wel mooi en eenvoudig zijn maar het moet ook toepasbaar zijn voor eindgebruikers. Als dat niet zo is dan is het gewoon geen optie.

HSML Cg Cuda OpenCL etc zijn ASM of C based languages.
Het plus punt is van AMP is dat het C++ en toegankelijk geintergreerd in visual studio.

Nou en dat voor de massa programmeur die voor windows programmeerd toch een voordeel.
Dat er supercomputer markt is waar men hardcore zelf in C of ASM GPGPU doet dmv Cuda. Nou die blijven Cuda gebruiken of liever het GPU onafhankelijke OpenCL.

MS richt met AMP op een breed deel van de markt, Zal niet ieders keuze zijn.

Maar zo een windows app ontwikkelaar voor gezicht herkenning zou AMP kunnen gebruiken.
De Linux tegenhanger heefd dan wat meer werk er aan met het veel generiekere OpenCL.

Absoluut mee eens. AMD erkende dit euvel ook op de AFDS (waar de slides in het artikel vandaan kwamen) en is op zoek naar allerhande oplossingen hiervoor. De C++ OpenCL bindings zijn al een stap in de goede richting, maar er zijn ook diverse libraries (zoals Bolt!) die het gros van de gebruikte reducties eenvoudiger maakt.
Het leuke is dus dat dit echt nog een markt in ontwikkeling is aan alle kanten. OpenCL heeft als voordeel de cross-platform portability, dus ideaal voor open-source projecten als The Gimp, Firefox etc.. C++AMP is sterk vanwege het single-source principe, die het dichter bij de traditionele programmeur brengen. Het zou mij niets verbazen als er nog een OpenMP->OpenCL compiler zal komen om dit weer vanuit een andere hoek te benaderen.

[Reactie gewijzigd door RSpliet op 2 augustus 2012 12:58]

De charme van C++ AMP is dat de programmeur zich niet met deze zaken hoeft bezig te houden. Alles schrijf je in C++ en de rest wordt door de compiler en library geregeld.

Als ik het goed heb gelezen op phoronix plant AMD dit ook en leent de door de Apple ontwikkelde Clang (http://en.wikipedia.org/wiki/Clang) hier zich ook uitstekend voor.

Blijkbaar was er rond GCC heel wat politiek en ideologisch gedoe die innovatie op dat vlak wat tegenhield.

Dit gezegd zijnde het verhaal van AMD is wel leuk maar ook op vlak van drivers en dergelijke is AMD een ramp als het gaat over OpenCL. De Blender instituut heeft namelijk een render geschreven (cycles) die ook gebruik maakt van OpenCL, maar AMD heeft blijkbaar zo slechte drivers en compilers voor OpenCL dat het gewoon op hun toestellen niet werkt.

Het kan blijkbaar enkel maar overweg met heel kleine beperkte kernels terwijl de Nvidia kaarten er geen problemen mee hebben.

Als ik het goed heb gelezen op phoronix plant AMD dit ook en leent de door de Apple ontwikkelde Clang (http://en.wikipedia.org/wiki/Clang) hier zich ook uitstekend voor.

Blijkbaar was er rond GCC heel wat politiek en ideologisch gedoe die innovatie op dat vlak wat tegenhield.

GCC is gewoon een 15 jaar oud product. Compileert geweldig van C naar binary, maar qua maintainability is de code niet zo sterk. LLVM(/Clang) leent zich er beter voor omdat het is gebaseerd op LLVM, een intermediate representatie waar je makkelijk mee naar de GPU's ISA kan vertalen. Weet niet wat er politiek achter steekt, maar gebruik van LLVM verbaast mij anno 2012 niet veel.

Dit gezegd zijnde het verhaal van AMD is wel leuk maar ook op vlak van drivers en dergelijke is AMD een ramp als het gaat over OpenCL. De Blender instituut heeft namelijk een render geschreven (cycles) die ook gebruik maakt van OpenCL, maar AMD heeft blijkbaar zo slechte drivers en compilers voor OpenCL dat het gewoon op hun toestellen niet werkt.

Het kan blijkbaar enkel maar overweg met heel kleine beperkte kernels terwijl de Nvidia kaarten er geen problemen mee hebben.

Daar staat tegenover dat AMD als enige fabrikant momenteel OpenCL 1.2 ondersteunt. nVidia steekt nog bij 1.1. Feit is dat Khronos documenteert hoe zaken moeten werken, en daaromheen kan je dingen doen in OpenCL die voor platform X wel werken maar Y niet. De hardware is niet hetzelfde, dus de ongedocumenteerde bij-effecten ook niet. Ik vermoed dat het Blender probleem net zo zeer in hun OpenCL kernel ligt als in AMDs drivers. Laat ik weer eerlijk zijn: ik heb geen AMD hardware om dit op te testen. Maar ik heb de indruk dat het meevalt en AMD momenteel harder pioniert op OpenCL gebied dan nVidia. Logisch, AMD heeft geen Cuda en de beste manier om daar tegenop te boksen is door de "open standaard" handschoenen aan te trekken. Deed nVidia ook 15 jaar geleden succesvol met OpenGL tegen glide!

[Reactie gewijzigd door RSpliet op 3 augustus 2012 03:24]

Een GPU is in feite een FPGA, maar dan als GPU geprogrammeerd.

Onwaar. Een GPU programmeer je aan de hand van de instructies die de ISA ondersteunt, terwijl een FPGA geprogrammeerd wordt met gate-level logica. Een FPGA is eigenlijk een soort van emulator voor chipontwerpen, en dit heeft een aantal gevolgen:
- FPGA's draaien op een lagere kloksnelheid dan GPU's. Het ontwerp van de LEON3 loopt op pak 'm beet 100MHz, terwijl een "carved in sillicon" GPU core richting de 1,5GHZ gaat.
- GPU's zijn energie-efficienter. Het bouwen van een ALU kost op een GPU een x-aantal transistors. Op een FPGA moeten er x transistors worden ge-emuleerd (aan de hand van lookup tables), en zijn er voor elke transistor dus meerdere transistors nodig.
- FPGA's zijn ingewikkeld. Je begint met een leeg vel, als je een optelling wilt doen moet je zelf een adder ontwerpen.
- GPU's zijn sneller in hun instructieset, maar FPGA's kunnen sneller zijn buiten deze instructieset. Een FPGA staat toe om zelf instructies te modelleren naar gelang de applicatie. Zo kan de von-Neumann overhead worden voorkomen en met een gewenste precisie worden gerekend ipv. die aangeboden door de GPU(/CPU).
- Het ontwerp in de FPGA is opnieuw te configureren. Je kan dus een gate-layout uploaden die precies is gemaakt voor taak A, en vervolgens een gate-layout voor taak B uploaden, en zo beiden met zo min mogelijk rekenwerk doen.

Overigens één kanttekening. Tegenwoordig hebben FPGA's ook ALU's (optellen, vermenigvuldigen) en geheugenblokken omdat dit veelgebruikte componenten zijn. De manier van aankoppelen is nog steeds vrij aan de gebruiker, maar dit maakt de performance een stuk hoger. Blijft wel dat deze vrijheid maakt dat het ingewikkeld ontwerpen is, waar de GPU "gewoon" programma's uitvoert.

Een GPU is een ASIC, geen FPGA.

Een GPU is tegenwoordig niet meer application specific.

[Reactie gewijzigd door Anoniem: 415197 op 5 augustus 2012 00:06]

Vanwaar de namingsproblemen?
Het is collectie silicium logic-gates zoals een CPU dat ook is. Een ASIC is dat ook.

Een FPGA is speciaal omdat je de logic-gates kan vertellen andere logic gates te emuleren. Daarmee lijkkt daarmee lijkt het alsof je je eigen logic gate layout maakt en dus je eigen chip (ipv programma) maakt. Dat kan bij sommige taken enorme voordelen opleveren, vooral bij taken die niet of weinig sequentieel zijn. Je hebt dus precies wat je wilt in een chip die alles kan zijn.

Een ASIC is precies wat je wilt in een chip die alleen dat kan zijn. Omdat je geen verwisselbare logic gates en routing nodig hebt zijn deze chips efficienter. Ook zijn ze goedkoper per gate, omdat een enkele gate niet een setje gates is maar echt een enkele gate. GPU's, CPU's, GPGPU's, screen controllers, beeldverwerkingsunits, mp3 decoders, etc. Zijn allemaal ASIC's. Nadeel van ASIC's is dat ze alleen per 10k of 100k kunnen worden gemaakt, je moet er heel wat kwijt kunnen voordat je ze kan maken.

Mijn punt was dat je een GPU veel breder kunt inzetten dan alleen voor graphics. Bijvoorbeeld om moleculen op te vouwen, lineaire systemen op te lossen, etc. etc.

ASIC staat voor "Application Specific IC". Dat is een GPU dus niet.

Zolang die boerenpummel wel weet wat de beperkingen zijn. Maar goed, ieder die daar aan begint zal zich daar van te voren in verdiepen.

Zo zal voor het porten van je CPU > GPU programma het probleem (deel probleem) al parallel uitvoerbaar moeten zijn, anders heeft het geen toegevoegde waarden.
Verder moet je er rekening mee houden dat een deel van het programma wat op in een CPU proces actief is, niet (zomaar, beetje roestig) in het geheugen van het proces(sen) komen wat op de videokaart actief is.

Anders dan dat is GPU computing FTW. Rete snel

Microsoft is hier hard mee bezig met hun C++ AMP.

Dat zit nog steeds vol met beperkingen, en als die worden weggewerkt in toekomstige versies dan krijgen we een versnippering van de markt. Neen, daar zit niemand op te wachten.

En het is ook belachelijk dat als alle beperkingen geëlimineerd zouden worden, dat we gewoon terug bij C++ uitkomen. En dat is dan ook waar Intel zich op richt. De AVX2 instuctieset die onderdeel wordt van hun eerstvolgende CPU-architectuur, bestaat uit exact het soort parallele instructies die je op de GPU terugvindt. Maar omdat het dus allemaal op de CPU-kernen draait is er geen enkele beperking en kan je in principe gelijk welke programmeertaal gebruiken.

Wat ik nog niet zie aangestipt worden in het artikel, is de mogelijkheden die AVX2 gaat bieden. Integer vectorization en gather support voor vectorization, gaat volgens sommigen flink wat rekenkracht toevoegen aan de CPU's (Haswell en nazaten en (mogelijk)Steamroller of een nazaat) en betreden ze hiermee ook het domein waar de GPU's normaal gesproken het alleenrecht haddden.

Dan gaan ze dus gewoon de kant van Powerpc op?

Neen, AVX2's vectoren zijn twee keer zo breed als in PowerPC's AltiVec, en het beschikt bovendien over parallele geheugen-instructies (gather). Hierdoor kunnen lussen code tot acht maal sneller uitgevoerd worden.

amd amd amd amd

Ben ik nou de enige die dit weer een typisch tweakers AMD artikel vind? Werkelijk geen WOORD over de uitstekende intel integrated graphics van sandy bridge of ivy bridge, waar je gewoon prima hedendaagse games op kan spelen zoals diablo 3 of starcraft 2. alleen de mislukte poot van intel (phi, nooit van gehoord) wordt genoemd

grote woorden voor amd met fusion, waar intel gewoon eerder op de markt was en een (veel) groter huidig marktaandeel heeft.

Als je een beetje tussen de regels door hebt gelezen zal je hebben gezien dat de AMD Fusion Developer Summit aan belangrijke aanleiding voor dit artikel is geweest. Is het dan een schande wanneer een organisatie een visie poneert die als inspirerend wordt ervaren? Een inspiratie die er dan de aanleiding voor is dat artikelen als het bovenstaande worden geschreven? Ik denk dat het artikel trouwens voldoende kritisch is ten aanzien van de beren op het pad. Het is beslist geen roze bril. Ook in de commentaren zie ik daarover goede feedback. Het is toch mooi als het zo kan werken? AMD geeft zijn visie, pusht, enthousiasmeert om de developersschare aan het bewegen te krijgen, en stelt zich daar kwetsbaar mee op, en hoe je het ook draait, ze staan achter iets. Vervolgens ontstaat een open discussie over de merites van de plannen. Transparant toch?

Tja, het is dus een AMD feestje. Punt. Public relations heeft AMD blijkbaar goed in de vingers. Blijft Intel onzichtbaar? Voor zover ik de media volg heeft Intel inderdaad nooit zo'n hoog profiel gegeven aan de geïntegreerde graphics zoals AMD dat nu doet (verbeter me als ik dat mis heb). Het is dus niet heel gek als AMD de toon zet. Als Intel iets belangwekkends te melden heeft zou Tweakers heel onverstandig zijn als dat geen even hoog profiel wordt gegeven, en ik weet zeker dat ze dat als nieuwssite gewoon zullen doen. Het enige dat Tweakers is te verwijten is een voorliefde voor het onconventionele, het afwijkende. Persoonlijk vind ik dat nu juist de charme aan de site, een beetje tegengeluid.

Voor wat mijn mening waard is: Een heel goed artikel, goed leesbaar, geeft een goed overzicht van ontwikkelingen die daarmee gelijk op hun plek vallen. Mijn complimenten. Deze materie zal nog wel even blijven gisten. De vorm hoe dit verder gaat is nog niet uit gekristalliseerd. Misschien is dat jammer voor AMD. Want de veranderingen die het bedrijf voorstaat zijn groot. Laat ze voldoende tussenstappen definiëren die geld opleveren, anders bijt AMD zijn tanden hierop stuk. Met name het maken van de software interface die de verdeling van taken tussen CPU en GPU gaat regelen, zonder dat de programmeur hierin capaciteit hoeft te stoppen, gaat veel inspanning kosten. Ook hier moeten weer slimme, kleine stappen gezet worden die direct in behoeftes voorzien en zichzelf zo snel terugbetalen. De instructieset voor een CPU is toch ook niet in een nacht ontstaan? Misschien zie ik het te simplistisch, maar met het maken van de juiste keuzes moet die verdeling toch generiek te definiëren zijn? Het zou toch absurd zijn als iedere programmeur zijn eigen unieke balans tussen cpu en gpu taken moet gaan vaststellen. Dan zijn we het wiel aan het uitvinden, en dat is de hond in de pot voor deze plannen.

De instructieset voor een CPU is toch ook niet in een nacht ontstaan? Misschien zie ik het te simplistisch, maar met het maken van de juiste keuzes moet die verdeling toch generiek te definiëren zijn?

Mee eens. Ik wordt daar altijd een beetje achterdochtig van. Het lijkt een toneelspelletje tussen AMD en Intel waarbij AMD zich op gevaarlijk gebied begeeft. Als er een processorarchitectuur komt waarbij de performance eenvoudig opgekrikt kan worden door de kwantiteit van een bepaal sub-circuit op de die te verhogen zou dat de processormarkt misschien wel compleet kunnen slopen.
Een CPU is nu nog een soort van monolitisch ding. Met multicore weken ze daar een beetje vanaf maar het blijft een enkele CPU die bij gebruik van gangbare software beperkte snelheidswinst uit die extra cores haalt. Als alleen de kwantiteit van de "cores" nog een rol speelt bij de performance keldert de waarde van een CPU als zijnde een enkel component. Ik heb wel eens het idee dat GPU's door hun herhalingsstructuur in de architectuur eigenlijk te veel mogelijkheden bieden voor een te lage prijs.
Anderzijds ben ik ook maar een leek. Mijn kennis van processorarchitectuur gaat in de praktijk niet veel verder dan i386 en simpel is dat moderne spul zeker niet.

sorry mnaar je post is gebaseerd op gebakken lucht.

de intel intergrated graphics iuitstekend ?
komop man doe wat research...
amd intergrated gpus zijn veel beter dan intel intergrated gpu's en alle review websites zullen je dit vertellen als je dan ook de moeite genomen had om deze te bekijken.

dat neemd niet weg dat bij amd wel de rek uit cpus is en bij intel nog niet dus wat dat betreft is dit wel een amd artikel maar kom niet aanzetten met de uitstekende gpu van intel dat zing is gewoon veel trager dan die van amd.


source voor je :
http://www.legitreviews.com/article/1915/3/

Als ik me de geschiedenis goed herinner zijn GPU's geintroduceerd om de CPU te ontlasten bij de zware grafische taken. Beginnende (ongeveer) met de Voodoo grafische kaarten. Zoals ik het nu begrijp is nu het plan er wederom een geheel van te maken?

Dit staat ook wel bekend als de "cycle of reincarnation":

cycle of reincarnation /n./ [coined in a paper by T. H. Myer and I.E. Sutherland "On the Design of Display Processors", Comm. ACM, Vol. 11, no. 6, June 1968)] Term used to refer to a well-known effect whereby function in a computing system family is migrated out to special-purpose peripheral hardware for speed, then the peripheral evolves toward more computing power as it does its job, then somebody notices that it is inefficient to support two asymmetrical processors in the architecture and folds the function back into the main CPU, at which point the cycle begins again.

Several iterations of this cycle have been observed in graphics-processor design, and at least one or two in communications and floating-point processors.

Ze willen de GPU als een soort co-processor inzetten (general purpose GPU). Maar software moet daar wel specifiek gebruik van maken. Vandaar de titel: developers, developers, developers

Nee ze waren er al veel eerder (grafische kaarten) bijv. https://en.wikipedia.org/wiki/Trident_Microsystems

[Reactie gewijzigd door PjotterP op 2 augustus 2012 16:58]

Grafische kaarten heb je in types. De eerste generaties (ook al van voor de PC -- denk Commodore 64 bijv) deden niets meer dan een stukje van het (main) memory de hele tijd uitlezen en op het beeldscherm gooien. Wat later de RAMDAC ging heten. Naarmate de techniek vorderde werd het stukje geheugen (de framebuffer) naar de grafische kaart gegooid, omdat de grafische kaart het 60 keer per seconde moest uitlezen en de CPU het een stuk minder vaak moest schrijven. Nog wat later (richting windows 3) kwamen er kaarten die bepaalde 2D taken konden ontlasten, zoals het tekenen van een muiscursor met behulp van bitblt. Er werden steeds meer 2D taken naar de GPU (inmiddels heette het een GPU) gegooid, en later kwam er naast je 2D kaart voor Windows een 3D kaart voor je games te zitten. Voodoo was de eerste succesvolle. Nog weer later kreeg je 2D/3D combinatiekaarten. En dat is eigenlijk nog steeds zo, alleen weer veel geavanceerder en sneller dan die eersten. Alleen is er weer een vierde functie bijgekomen (Naast 3D versnelling, 2D versnelling, en het maken van het beeld zelf), namelijk general purpose rekenen.

hardware acceleratie sloeld op logic dat spicfiek porbleem op hardware niveau op zich neemd.

De FPU was ooit ook los zo had ik Wietec ipv 80387 bij mijn 80386S.
FPU zijn al lang geleden geintergreerd in CPU. Door dieshrink is transistor budged aanzienlijk vergroot dat er steeds meer geintergreerd kan worden. System on single chip is nu goed mogelijk en in de toekomst wordt dit steeds krachtiger.

Los is eigenlijk alleen dit ipv DIE delen met ander logic heb je een hele DIE voor je logic.

Kan je zien Los als high-end 4 tot 6x de rekenkracht vs standaard on chip.
Vroeger singlecore is er weinig ruimte voor core en cache om er iets anders groots bij te pleuren. Nu met 6 core kan je tot 4 cores vervangen door een kleine GPU.
De hardware acceleratie is er nog steeds maar dan op de CPU zelf.

En GPU zijn door GPGPU wat breeder te gebruiken.

Boeeee! Moore's Law stelt dat de hoeveelheid transistors elke anderhalf jaar verdubbelt, niet elke twee jaar. Zie ook dit grafiekje op wikipedia.

Even voor de duidelijkheid; de reden dat "Moore's Law" waar is en blijft zit hem in het feit dat het DE doelstelling van Intel is om deze wet werkelijkheid te maken. Moore was dan ook één van de oprichters van Intel...

Zolang Intel het grote geld verdient zie ik niet in waarom ze het in 2013 ineens zouden opgeven.

Sterker nog ze zeggen zelf dat dankzij 22nm trigate ze weer on track zijn:

Intel, which has maintained this pace for decades, uses this golden rule as both a guiding principle and a springboard for technological advancement, driving the expansion of functions on a chip at a lower cost per function and lower power per transistor by introducting and using new materials and transistor structures.

The announcement of the historic Intel® 22nm 3-D Tri-Gate transistor technology assures us that the promise of Moore’s Law will continue to be fulfilled.

http://www.intel.com/cont...oores-law-technology.html
http://www.intel.com/abou...museum/exhibits/moore.htm

Ben bang dat Mark te veel op wikipedia heeft gekeken in plaats van op de Intel site .

Je hebt niet goed gekeken hoor. De wet schrijgt een verdubbeling van transistors voor. Een veel gemaakte 'fout' is dat een andere Intel-gast heeft gezegd dat de prestaties elke 18 maanden verdubbelen.

De beschrijving van de grafiek luid ook gewoon: English: Transistor counts for integrated circuits plotted against their dates of introduction. The curve shows Moore's law - the doubling of transistor counts every two years.

En zoals sdk1985 aanhaalt, Moore's Law zou een selffulfilling prophecy kunnen zijn. Je weet het niet zeker, maar ze kunnen vast sneller, maar ik gok dat dat niet rendabel is, dan moet je dusdanig veel investeren in producten die een veel te korte lifecycle hebben. Intel houd er nu al een moordend tempo op na met hun tick-tock strategie.

Kijk, dit is nou eens een interessant artikel. Mijn complimenten daarvoor. Misschien stel ik nu een n00b-vraag, maar waarom is het eigenlijk zo dat de huidige GPU's veel meer hitte produceren dan CPU's? GPU's kunnen namelijk vrij heet worden en kunnen wel met een conventionele luchtkoeler gekoeld worden. Bij het opvoeren van de clocks wordt de CPU gewoon te warm. Kleiner dan 4nm voor de transistoren is ook niet goed -> te warm.
Ik kan de link tussen de grootte van transistoren, het aantal kernen en de seriele vs parallele manier van verwerken even niet linken....
Tis absoluut goed dat nu naar alternatieven gekeken worden, dan alleen het verkleinen van de transistors om een zo efficient mogelijke cpu te krijgen, maar zoals met veel dingen zullen ze waarschijnlijk alle rek eruithalen.

Het klopt wel dat cpu's van nu inderdaad minder warm worden dan (discrete) gpu's.
6 jaar geleden mochten cpu's van intel en amd nog maximaal tegen de 90 a 100 graden lopen.
Nu is dat maximaal 70 a 75 graden.

Voor zover ik weet komt dat doordat gpu's eenvoudiger van structuur zijn en een meer voorspelbaar gebruik en warmteontwikkeling hebben. Cpu's zijn complexer en breeder inzetbaar waardoor ook de warmte ontwikkeling een stuk minder voorspelbaar is.
_{(gpu's hebben heel veel dezelfde onderdelen, cpu's hebben veel verschillende onderdelen)}

Op dit moment is het al bijna lastig zoeken naar een pure cpu zonder gpu gedeelte waardoor alles weer enigzins veranderd is.

CPU's mogen nog steeds 90 a 100 graden worden, Ivy Bridge max temp is 105 voor dat ie gaat throttlen.

Maar met normaal gebruik wordt de gpu meestal warmer ja. Redenen:
- gpu wordt altijd (vrijwel) maximaal belast. Met lichtere games geeft ie gewoon meer fps tot ie niet meer kan terwijl met bvb video encoding op de cpu lang niet alle transistors tegelijk gebruikt worden.
- gpu's zijn groter en verbruiken meer.
- cpu koelers zijn veel beter dan gpu koelers die hun werk ondersteboven moeten doen.

Ontopic: ik hoor dit nu al jaren en wacht rustig af tot dit echt doorbreekt. In de tussentijd voldoet alleen cpu ook vrij aardig.

omdat GPU groter zijn in vierkante millimeters, zou ik zo eerst denken. Grotere oppervlakte, kan dus meer warmte naar de koeler doorvoeren.

Nog een paar verschillen:
- frequenties zijn stukken lager in GPUs
- ongeveer de helft van een CPU is gewoon cache (ongeveer SRAM geheugen), dat bij mijn weten niet al te veel warmte produceert.

Ik denk, maar dit is mijn punt, dat een CPU vooral een grotere warmteproductiedichtheid heeft (meer warmte op kleinere oppervlakte) dan een GPU. Onder anderen door de hogere kloksnelheid. Een GPU is een array van dezelfde rekenkernen, dus vrij gelijke verdeling van warmteproductie in oppervlakte.

Op CPUs zijn er al redelijk lang Heat Spreaders... Toch kan je door de hogere warmtedichtheid lokaal sneller bij de maximum temperatuur liggen.

Dit doet mij ook denken aan de "Turbo" van tegenwoordig. Afhankelijk van temperatuur, zal de kloksnelheid van kernen aangepast worden.

Gpu's worden niet perse warmer maar wel anders belast. Bij de gpu is het eenvoudiger alle transistors aan het werk te zetten daar er veel rekenkernen zijn en veel parralel word uitgevoerd. Bovendien zijn de luchtkoelers erop vaak, qua massa, kleiner dan de cpu-koelblokken en heeft de cpu koeler tegenwoordig 120mm fans ipv de kleinere fans bij videokaarten.

Ik denk dat dat mede komt door concurentie.
iNtel CPU zijn krachtig maar kunnen ook aardig wat vermogen trekken. Maar er is nogal een zeer grote overklok marge. Dat houd in dat als er wel zware concurentie van AMD was. Zoals toen de 1.2Ghz thunderbird vs 1Ghz Pentium3. Dat intel nu een heel andere productline had met veel hogere klokken en ook meer vermogen.
Dus de grenzen ver overschreden worden. Het is dat AMD op CPU ver van huidige heigh-end verwijderd is.
Deze onbetwiste markt leiding positie brengt vooral dit mee. Je houd een aanzienlijke marge aan en geniet daarmee met een hoge yield en Bin. Ook kwa releases zit de druk er niet meer op. En kan men effectief uitrollen.

Het is nu dat nV AMD op GPU gebied volgd dat Bigchip benadering leuk voor prestige en imago is maar eerder voor grote problemen zorgt en moeizame executie van de planning en commerciele rendement laag is. nV 680 is niet zo extreem groot. Maar door concurentie kan het niet te licht. Dus vreet meer energie dan CPU.
nV ziet AMD sucses ook met hun lichtere performance chips in het verleden.
En dat commercieel sucses toch fijner is dan duure prestige imago sucses met staartje.

Daarnaast zijn CPU procedes en GPU procedes niet in sync en vaak loopt iig die van iNtel wat voor.

Volgens mij omdat ze over veel meer cores beschikken dan een cpu (maar ik been geen cpu/gounkenner )

Persoonlijk denk ik dat de toekomst meer richting de Zync oplossing van Xilinx gaat :
een cpu met een enorm blok herprogrammeerbare logica.
De core van een GPU is zeer geschikt voor grafische berekeningen maar voor een hoop andere zaken is hij een stuk minder geschikt.
http://www.xilinx.com/pro...s/epp/zynq-7000/index.htm

Grappig, aan het eind van het artikel zat ik ook in die richting te denken. Niet gehinderd door enige kennis hoor. Maar het lijkt me een hele logische ontwikkeling (@brugj03: dat iets nog niet in de roadmaps staat wil nog niet zeggen dat het niet de logische eindstatus kan zijn). Er zit naar mijn idee zeker logica om de huidige cpu architectuur meer in de de rol van regisseur/distributeur te drukken. Om de CPU heen zit een vijver van transistoren die dan wel rol van GPU dan wel de rol van cache kan afdekken. Hoe?..... Ik denk dat ik blij ben dat ik dat niet hoef te gaan verzinnen. Een dergelijke architectuur zou denk ik de volgende voordelen hebben.

• Zorgen dat een architectuurtype zowel de rol van Cache als GPU kan afdekken kan voorkomen dat de transistorbehoefte te groot wordt om op een fatsoenlijke die te proppen. De transistorbehoefte is de grootste catch voor dit soort SoC oplossingen
• Door de rol van de CPU te beperken tot die van regisseur en distributeur creëert wat lucht om de Instructieset toe te spitsen op die rol. Hierdoor kunnen de conventies die de activiteit tussen CPU en GPU verdelen meer in detail worden ingebakken.
• Door de beperking van de rol van CPU worden de conventies voor verdeling van activiteit tussen CPU en GPU ook eenvoudiger. CPU krijgt immers meer de rol van regisseur toebedeeld en de GPU/Cache vijver meer die van uitvoerder.
• Door de instructieset meer in te richten voor het verdeel mechanisme wordt voorkomen dat die logica in de software moet worden ingebed.

Een nadeel wat ik nog wel zie: de Cache/GPU vijver zal iets intelligenter moeten worden om met de meer impliciete commando's van de CPU om te kunnen gaan.

Nou, schiet me maar af. Wat ik hierboven schets is vast om meerdere reden momenteel onmogelijk. Hoe meer ik er echter over nadenk, hoe meer ik er van overtuigt raak dat een dergelijke verandering alleen kans van slagen heeft als de software developers geen extra belasting hoeven te ervaren in het programmeren voor een dergelijke architectuur. Dus vanuit mijn optiek is het hardwarematig inbedden van generieke conventies het enige pad om te gaan.

Ik zie eerder een groot probleem voor in de toekomst. Als ik de tech CUDA en OpenCL CS boeken lees. Schalen de meeste aplicaties niet zo makkelijk met Massive concurrent computing. Veel aplicaties zijn van het software type serieel en branche heavy. Erg moeilijke of niet deel bare code. Ook brengt enige seriele code de concurrent performance drastische terug.

je hebt dan een APP die alleen van meer performace genieten als die toekomstige CPU op 4nm een zeer hoog geklokte enkele core heefd. Maar dat zit er dus niet in. Geld nu ook. Niet elke software probleem kan overweg met meerdere cores. Als kan niet omgezet worden en efficent gebruik maken van meerdere cores.

Wat is het nu GPU hebben later mogelijk meerdere dozijnen aan duizende cores.
CPU worden ook chips met dozijnen aan cores.

De toekomst is alle applicaties moet men extreem het software probleem delen in stukjes omdat de CPU performance exteem afhankelijk is hoe deelbaar de software is over x aantal dozijn aan cores.

Nu kan je een werkstationnetje maken met 2 Optereon 6272 CPU met elk 16 cores.

Op 4nm mogelijk een APU met 32 cores en 3200 GPu cores.

Als dit de toekomst is waarom zijn er dan nagenoeg geen aanwijzingen dat de technologie die richting op gaat.
Just askin.............................

Interessant stukje, het is ook duidelijk merkbaar dat gpu berekeningen aan terrein winnen.
Enkele populaire voorbeelden hiervan zijn natuurlijk de vele folding programma's, bitcoin, renderprogramma's die de GPU gebruiken, forensische programma's voor het decrypten van hashes.

Ben zelf heel benieuwd wat de intel phi xeon gaat doen en hoeveel voordelen de x86 instructieset het bied ten opzichten van de AMD en NVIDIA kaarten.

keep 'm coming!

Je noemt een paar voorbeelden die leuk zijn maar waar geen hele grote doelgroep voor is.

De grootste doelgroep is bedrijfsmatig en particulier gebruik en daar zie ik tot nu toe weinig toegevoegde waarde. Bedrijven als intel moeten omzet draaien met massaproductie en voor dit soort speciale kaarten is de markt voorlopig nog heel klein en niet voldoende om te zeggen dat het een echt alternatief is voor de huidige cpu's.

Renderfarms of natuurkundige berekeningen zijn enorme markten, kijk naar de supercomputers, die zullen in de aankomende jaren meer en meer met videokaarten worden uitgerust, binnen nu en 7 jaar (naar mijn inzicht) zal meer dan de helft van de top500 snelste supercomputers voor het grootste deel uit videokaarten bestaan.

Als ze met verfijnde technieken komen die 100Ghz mogelijk maken, dan wordt het dikke pret .
De hamvraag blijft het het ooit nog tot een CPU/GPU geheel komt.

Volgens mij niet, maar er mogen best eens een keer nieuw spelers komen dan alleen AMD/Nvidia....
Je moe tje ook afvragen of je wel wilt dat alles steeds kleiner wordt -en of samensmelt.... een grote pc kast is altijd wel handig voor van alles.

[Reactie gewijzigd door A87 op 2 augustus 2012 11:15]

Nou, daar ben ik het niet mee eens. Ja ik heb twee fulltowers staan met een dikke G-kaart erin. Ik ben dus zo een consument die voor dedicated power gaat en daar betaal je ook voor.
De massa heefd geen grote kast nodig, upgrade gehalte is daar ook niet zo extreem.

Iemand die nu bewust voor APU tje gaat heefd daar ook zijn schappelijke eisen en budged naar.
Daarnaast de consument die totaal niet upgrade tot gradaties naar extreem upgraders. Je ziet dat er ook een redelijke markt is voor kliene design PC. En All In One's.

Daarnaast APU wordt in mobo geprikt en toekomstige PU ook en mobo kan je in een of andere standaard formfactor kast proppen van groot tot klein.
Dat zal niet zo snel veranderen.

Daarnaast er is niet alleen AMD vs nV en iNtel vs AMD. Het groeid naar mekaar toe dus het wordt uiteindelijk iNtel vs AMD vs nVidia.

Goed en interessant artikel.

Wel denk ik dat het inzetten van de GPU voor rekenintensieve taken voorlopig echt een uitzondering zal blijven. Om de volgende redenen:

• Er zijn maar weinig plekken / taken waar het echt de moeite loont om de GPU in te zetten. Niet alleen omdat het 'moeilijk' is (en dat moet inderdaad ook verbetert), maar er speelt ook mee dat de verbetering ook echt een noodzaak moet hebben. Iets wat 15 seconden tijd kost wat met een GPU verbetert kan worden naar 1 seconde zal in veel gevallen te duur zijn om daadwerkelijk te verbeteren tov. het 'voordeel'.
• In heel veel gevallen is eerst het inzetten van meer dan één CPU core al een uitdaging (multithreaded programmeren is niet zo een voudig).
• In veel programma's (vooral ook business software) is een goed werkend en goed getest programma al een hele uitdaging.
• Daarbij denk ik ook dat voor die onderdelen waar dan toch de GPU een hele verbetering kan bieden (grafische presentatie / analyse van veel data / bewerkingen op veel data (zoals grafische filters , modellen met grote datagrids) vanwege de materie en algoritmes waar het daar over gaat weer specialistische programmeurs nodig zijn. Dat is denk ik zelfs een groter probleem dan het feit dat GPU's niet zo eenvoudig te programmeren zijn (ze zijn te programmeren en voor echt programmeurs is het nu juist een uitdaging om het dan ook te gebruiken).{/li]

Nou je hebt een goed punt,
maar op game gebied is er een domper een ramp geweest.
.
Zo zie je in het artiekel dat ze met Cuda geslotenheid niet zo blij mee zijn en liever OpenCL zien. Zodat iedereen er in mee kan gaan. Op physics gebied stonden ze al op dat punt. Op game gebied is er dit gebeurd.
Onafhankelijke Havok Physic Middleware had een module in ontwikkeling die gpgpu ondersteunde. Er was geen standaard, maar men implementeerd de code path voor AMD en nV. Na wat modder gegooi en LRB dreiging tussen iNtel en nV. Eigenlijk een korte periode van CPU vs GPGPU.
Heeft iNtel havok overgenoemen en HavokFX gekilled. Als reactie daarop heefd nVidea Ageia PhysX SDK overgenomen. Maar vanwege weg vallen van larabee en sucses van AMD GPU tak wordt uitsluitend Cuda gebruikt ipv OpenCL Dus nv GPGPU only.
Deze tweedeling heefd de game industrie weinig mee. Soms komt er eens een titel met PhysX GPGpU suport.
Gezien Havok en PhysX de marktleiders zijn kwa physics middleware en er geen goeie derde is.

Ligt Physics hardware acceleratie op zijn gat., En is dus die momentum door iNtel compleet omzeep geholpen.

Ware dat niet, dan zou nu al tweede of derde wave aan Havok FX enable titles waren die AMD en nV gpgpu flink wat effect physics op los laten.

Dus als gamer zijn we daarmee toch even door iNtel genaaid.


En dan tegen argument. Ja het is moeilijk om dat even inhous te implementeren. Maar daar is zoiets als middleware dat zich specifiek met specialisten richten op gefocus software probleem. En daar jaren investeren en die barrierres met gemak nemen. Omdat ze dedicated de man uren en expertise erop los laten. Dus ware het niet door iNtel party pooping. Werd gpgpu wat massaler gedaan in Havok enabled games.

En is Gpgpu is dan niet zo wereld vreemd als nu geval is maar iets dat ingeburgerd zou zijn in de game industrie voor PC markt.