Het huwelijk van gpu en cpu

Inleiding: heterogeen computeren

De Wet van Moore dicteert dat de dichtheid van het aantal transistors in een chip elke twee jaar verdubbelt. Deze wet ging decennialang op, maar er zitten grenzen aan de groei: vanaf 2013 zou elke verdubbeling wel eens een jaar of drie in beslag kunnen nemen. Bovendien nemen de prestaties van processors lang niet altijd evenredig met het aantal transistors toe.

Dus hoewel er nog wel wat rek in de transistordichtheid zit, zoeken Intel en AMD naar andere oplossingen om de prestaties van hun processors te verbeteren. Het vergroten van de transistordichtheid, en daarmee van het aantal transistors op een chip, is namelijk niet de enige manier om snellere chips te maken. Beide bedrijven gebruiken een steeds groter deel van hun chips voor de geïntegreerde gpu's, in plaats van voor de cpu. Met name AMD denkt dat de gpu meer kan dan alleen het renderen van 3d-beelden om spelletjes te kunnen spelen.

De cpu werd ooit ontworpen om een alleskunner te zijn, die een groot aantal verschillende - en complexe - instructies kan verwerken. Gpu's daarentegen zijn ontworpen om zoveel mogelijk data te kunnen verwerken. Als de data geschikt is voor parallelle verwerking, kunnen gpu's veel sneller werken dan de general purpose-cpu's, omdat ze over heel veel 'simpele' rekeneenheden beschikken.

Uiteraard zijn er meer zaken van invloed op de snelheid: zo is elke rekenkern tot op zekere hoogte afhankelijk van de beschikbaarheid van cachegeheugen en ook een branch predictor kan grote invloed op de snelheid hebben. Zulke onderdelen nemen echter weer veel transistors in beslag en kunnen dus niet onbeperkt aan de gpu-rekenkernen worden toegevoegd.

Beide typen processor hebben dus hun eigen specialisme, en de kunst is om een combinatie van beide zo goed mogelijk te benutten. Dat staat bekend als heterogeneous computing.

Cpu's kunnen wel overweg met parallelle code, aangezien ze tegenwoordig doorgaans twee tot zes rekenkernen aan boord hebben, die ook nog eens over hyperthreading beschikken. Het grote verschil zit hem in de efficientië. Een gpu maakt gebruik van het single instruction, multiple data-model, waarbij een control unit door meerdere rekeneenheden dezelfde instructie laat uitvoeren.

De verhouding van één control unit per 16 of 32 rekeneenheden blijkt zeer gunstig te zijn: met minder rekeneenheden wordt parallellisme onvoldoende benut, bij meer bestaat de kans dat er te veel rekeneenheden zonder werk komen te zitten als de data onvoldoende parallelliseerbaar is. En dat is zonde, want een gpu beschikt al snel over 1500 tot 2000 rekenkerntjes.

Vooralsnog wordt de rekenkracht van een gpu in veel gevallen nog onbenut gelaten. Zowel Intel als AMD wil daar verandering in brengen en sinds een jaar of wat zijn er processors op de markt die een cpu en een relatief krachtige gpu in dezelfde package bundelen. De integratie moet echter nog veel verder gaan: uiteindelijk is het de bedoeling dat programmatuur automatisch door de best geschikte processor wordt uitgevoerd.

Cpu's: de rek lijkt eruit

De wet van Moore is al een jaar of veertig geldig gebleken, maar er zijn al diverse barrières geslecht om dat mogelijk te maken. Zo kun je denken aan de introductie van high-k metal gates, waardoor transistors kleiner werden en lekstromen werden verkleind in vergelijking met transistors met siliciumdioxide-gates. Hierdoor kon het stroomverbruik van cpu's binnen de perken worden gehouden en kon de transistor-dichtheid verder toenemen dan oorspronkelijk gedacht.

Het 'shrinken' van de transistors brengt veel voordelen met zich mee. Zo worden processors goedkoper als er meer uit een wafer gehaald kunnen worden. De benodigde spanning om de transistors te laten schakelen neemt ook af, wat per saldo een energiebesparing oplevert.

Maar misschien nog wel belangrijker is de prijs per transistor. Het huidige procedé, op basis van immersielithografie, kan gebruikt worden voor transistors met een minimale grootte van 14nm. Met grote investeringen in extreme ultraviolet-lithografie zou het mogelijk zijn om de featuregrootte tot rond de 4nm te verlagen. Bij nog kleinere features zouden siliciumdioxide-transistors te heet worden, ongeacht de koeling, en bovendien krijgen ze dan te veel last van electron tunneling. Deze grens zou nog dit decennium bereikt kunnen worden, en de kans is aanwezig dat - voor zover de wet van Moore dan nog kán opgaan - het domweg niet meer rendabel is om meer transistors op een chip te plaatsen.

Powerwall

Een andere manier om processors sneller te maken, is het verhogen van het aantal kloktikken per seconde. Vooralsnog zien we amper cpu's met een snelheid van boven de 4GHz, en lijkt het erop dat die snelheid niet veel hoger gaat worden. Dat heeft te maken met de zogeheten powerwall.

Om de kloksnelheid toe te laten nemen moet de spanning verhoudingsgewijs meer toenemen. Dat betekent dat de toename in energieverbruik uiteindelijk zo hoog wordt, dat het niet langer de marginaal hogere prestaties rechtvaardigt. Intel en AMD kunnen best een cpu produceren die op 5GHz of hoger is geklokt, maar de cpu zou dan heel veel hitte produceren. Met de huidige koelmethoden en de huidige featuregroottes zou het silicium te warm worden om nog met een conventionele luchtkoeler gekoeld te worden.

Er is geen processor die dit probleem beter illustreerde dan de 'Prescott'-Pentium 4, bijgenaamd 'de kachel'. Deze cpu, een van de eerste die boven de 3GHz werd geklokt, werd vaak zo warm dat hij zichzelf moest uitschakelen. Na het uitbrengen van deze chip hield Intel de kloksnelheid-race voor gezien om zich op dualcore- en quadcore-ontwerpen te richten. Overklokkers bewezen dat betere koeling wel hielp: kloksnelheden van meer dan 8GHz bleken mogelijk, maar daar was wel vloeibarestikstofkoeling voor nodig. Het bleek echter niet erg praktisch om cpu's constant op een temperatuur van -100 graden Celsius of nog minder te houden.

Een mogelijke oplossing is het gebruik van andere materialen om transistors te maken, zoals koolstof nanobuizen of grafeen. Door de hogere elektronmobiliteit van het materiaal in vergelijking met de huidige halfgeleiders, is er minder spanning nodig om de transistors te laten schakelen. Het lukte IBM al in 2010 om een transistor van grafeen te produceren die met een frequentie van 100GHz kon schakelen.

Memory Wall

We hebben al gezegd dat het een toename van het aantal transistors lang niet altijd een evenredige toename van de prestaties betekent. Een belangrijke oorzaak daarvan vinden we in het werkgeheugen.

Waar een singlecore-cpu nog de hele geheugenbus voor zichzelf heeft, moeten de rekenkernen van een multicore-cpu die geheugenbus delen. Hoe meer cores er worden gebruikt, des te belangrijker is dus de snelheid waarmee gegevens uitgelezen en weggeschreven kunnen worden. Intel probeert het gebruik van het werkgeheugen zoveel mogelijk te beperken door de cpu van grote hoeveelheden cache te voorzien. Dit geheugen kan tot wel honderd keer zo snel benaderd worden als het werkgeheugen. Bij sommige cpu's wordt meer dan de helft van het aantal transistors voor cache gebruikt.

De geheugenbus sneller of breder maken is ook een optie, maar dat kost weer te veel energie. William Dally van Nvidia stelt dat een simpele berekening door de cpu slechts 1 picojoule kost, terwijl het uitlezen van extern geheugen 2000 picojoule vergt. Het energieverbruik kan worden gereduceerd door het geheugen zo dicht mogelijk bij de cpu te plaatsen. Ook daarom geniet cachegeheugen de voorkeur - dichterbij gaat geheugen niet komen - maar ook cache gebruikt energie, en bovendien zorgt veel cache voor veel transistors op de die. En die transistors zijn dus niet onbeperkt voorradig.

Opvallend is overigens dat geheugenfabrikanten wel steeds snellere ram op de markt brengen, maar zowel AMD als Intel ondersteunen dat officieel niet. Wel zijn er de afgelopen jaren architecturele vorderingen gemaakt: zo vinden er per kloktik nu meer data-tranfers plaats in plaats van slechts één.

ILP Wall

Instruction-level parallelism is simpelweg het aantal instructies of delen van instructies die tegelijkertijd uitgevoerd kunnen worden. De aanname daarbij is dat de instructies niet van elkaar afhankelijk zijn, wat in veel gevallen natuurlijk wel degelijk zo is.

Tien jaar geleden wisten AMD en Intel daar nog flinke progressie mee te boeken, maar tegenwoording behalen de fabrikanten met elke volgende generatie slechts enkele procenten winst. Dat komt omdat met name Intel eigenlijk al het onderste uit de instructionlevelparallelismkan weet te halen.

Er zijn verschillende manieren om ilp te bewerkstelligen. Een bekend voorbeeld is out of order execution, waarbij instructies die niet afhankelijk van elkaar zijn maar door een programmeur in een bepaalde volgorde zijn gezet, toch tegelijkertijd worden uitgevoerd.

Dat kan natuurlijk door de instructie naar een tweede core te sturen, maar het kan ook een niveau lager. Instructies in een processor worden namelijk afgehandeld door een zogeheten pipeline. Elk deel hiervan kan een bepaald onderdeel van een instructie uitvoeren, en als dat onderdeel is afgerond, kan hetzelfde deel van de pipeline aan hetzelfde onderdeel van een nieuwe instructie werken. Er wordt dan dus al aan een instructie gewerkt terwijl zijn voorganger nog niet klaar is.

Dat heeft opnieuw als nadeel dat de chip een grotere vermogensbehoefte heeft, omdat de pipeline langer en het chipontwerp dus complexer is. In het slechtste geval neemt het aantal instructies per kloktik zelfs af.

Ook hangt de lengte van de pipeline nauw samen met branch prediction. De branch predictor probeert te voorspellen wat er met een bepaalde instructie moet gebeuren, zodat de processor 'weet' welke instructie er als volgende moet worden uitgevoerd. Zoals de naam al zegt probeert de branch predictor - vrij vertaald: de aftakkingsvoorspeller - uit te rekenen of er wel of niet aan bepaalde condities voldaan wordt.

Intels branch predictor zou al erg goed zijn, en daar valt dus nog maar weinig winst te behalen. De reden dat er met ilp niet meer te winnen valt, is dat out-of-order execution, branch prediction en multithreading allemaal transistors kosten. Die verbruiken weer energie, en zoals gezegd is deze logica al heel goed: het toevoegen van nog meer transistors is niet rendabel meer.

Cpu versus gpu

De taken die we op onze pc's, laptops en tablets uitvoeren, veranderen. Een nieuwe en steeds populairdere tak van sport is patroonherkenning: het analyseren van de aanrakingen op een touchscreen, gezichtsherkenning - dat bij Windows 8 gebruikt kan worden om in te loggen - en voice control zoals bij Apples Siri en Google Now zullen in de komende jaren steeds meer toegepast worden. Zulke taken zijn erg data-intensief en de hoge throughput van parallelle verwerking kan daarbij van grote waarde zijn.

Bij de introductie van dualcore-cpu's werd echter al snel duidelijk dat veel programmatuur geen baat bij een tweede rekenkern had. Omdat de kloksnelheid bij de eerste multicores lager lag dan bij de ver doorontwikkelde singlecores, was de snelheidswinst bij veel programma's ver te zoeken. Nu programmeurs weten dat het gros van de pc's over meer dan een kern beschikt, worden multicore-cpu's steeds beter benut. Bijna alle benchmarks die we bij Tweakers.net draaien zijn bijvoorbeeld multithreaded en ook games zijn steeds vaker ingericht op het gebruik van meerdere kernen.

Een maat voor de prestaties van een processor is de task latency: de hoeveelheid tijd die nodig is om een taak van begin tot eind af te ronden. Een tweede maat is de hoeveelheid werk die een processor in een bepaalde hoeveelheid tijd kan uitvoeren: de task throughput. Cpu's zijn ontworpen op een zo laag mogelijke task latency; bij gpu's ligt de nadruk op task throughput. De cpu en de gpu zijn grofweg in staat om elke taak uit te voeren, maar het gaat om het rendement: cpu's zijn veel beter in seriële taken, terwijl een gpu is gespecialiseerd in parallelle workloads - soms zijn problemen zo onthutsend simpel te parallelliseren dat er wel wordt gesproken van embarrassingly parallel workloads. Op hun eigen terrein zijn de processors soms wel een factor honderd sneller.

Zo is er het programma Amber, waarmee aan molecuulmodellen worden gerekend. Met behulp van Nvidia's Cuda-api kunnen Nvidia's videokaarten ingezet worden om de simulaties veel sneller uit te voeren dan met een cpu, zo tonen benchmarks op de site van Amber aan.

Bij de simulatie van een molecuul van 304 atomen is een GTX 580 bijna drie keer zo snel als twee Intel E5462-quadcores. Wanneer er 2492 atomen in het spel zijn, is de GTX 580 ruim twintig keer zo snel. Naarmate het aantal atomen toeneemt naar 25.000 of zelfs 100.000 neemt het verschil iets af, maar de GTX 580 is nog steeds acht tot tien keer zo snel.

Onlangs werd in het Verenigd Koninkrijk een supercomputer met 372 M2090-kaarten en 168 hexacore Xeon-cpu's in gebruik genomen, die 114Tflops aan rekenkracht levert en daarmee nummer 159 in de top 500 van supercomputers bezet. Een supercomputer met gpu's is daarmee een stuk goedkoper dan eentje met alleen cpu's.

Daar staat echter tegenover dat programmeren voor gpu's een stuk moeilijker is. Nvidia werkt echter al jaren aan general purpose gpu-applicaties en met name in de onderzoekswereld en het bedrijfsleven heeft dat al behoorlijk wat vruchten afgeworpen. Het marktaandeel van supercomputers met gpu's is de afgelopen drie jaar dan ook flink toegenomen. In juni 2010 beschikten 2 van de 500 supercomputers over gpu's, in juni 2011 waren het er 14 en tegenwoordig zijn het er ruim 50.

Ook Intel is zich van de kracht van parallellisme bewust. Dit bedrijf presenteerde onlangs de Xeon Phi Co-processor, een 'videokaart' met ruim 50 kernen. Dat staat nog in schril contrast met de 1500 tot 2000 kernen waar de gpu's van Nvidia en AMD over beschikken, maar Intels rekeneenheden kunnen overweg met x86-code. Daardoor hoeven bestaande applicaties niet herschreven te worden met OpenCL of Cuda, maar kunnen ze bijna zonder aanpassingen op de Xeon Phi-processors worden uitgevoerd.

Intel kondigde ook meteen de eerste supercomputer op basis van de Xeon Phi aan. Naast 1225 Xeon E5-cpu's bevat dit systeem 613 van deze co-processors, waarmee een snelheid van 118Tflops wordt gehaald. Dat is iets meer de supercomputer in het Verenigd Koninkrijk, maar daar zijn wel het dubbele aantal 'gpu's' en zeven keer zoveel cpu's voor nodig. Opvallend is trouwens dat Intel beweert dat de Xeon Phi 1Tflops aan double-precisionberekeningen levert, maar dat cijfer wordt in een benchmark van Linpack bij lange na niet gehaald. Nog opvallender is dat Nvidia voor de M2090's een maximum van 'slechts' 0,665Tflops aan double-precision berekeningen claimt.

Alles op de gpu?

Het lijkt er dus op dat de gpu een zonnige toekomst tegemoet gaat, maar het gebruik van de gpu als gpgpu is niet eenvoudig. Met traditionele, seriële programmeertalen kan het parallellisme niet zomaar benut worden en bovendien lenen niet alle toepassingen zich voor het gebruik van de gpu. Als de te bewerken data niet goed geparallelliseerd kan worden, komen zwakheden als het ontbreken van veel cache namelijk genadeloos aan het licht. Er moet dan relatief vaak met het geheugen gecommuniceerd worden, en dat kost niet alleen tijd maar ook energie.

Op de AMD Fusion Developer Summit, die in juni van dit jaar werd georganiseerd, probeerde AMD developers warm te laten lopen voor heterogeneous computing. Uitgangspunt daarbij is dat er een combinatie van cpu en gpu wordt gebruikt. Tijdens de keynote van Phil Rogers, corporate fellow bij AMD, kwam onder andere gezichtsherkenning met behulp van het Haar-algorithme aan bod. Met name de eerste fase van dit algoritme leent zich uitstekend voor gpu's, maar volgende fases kunnen weer beter door een cpu worden uitgevoerd. Als de cpu en de gpu perfect samenwerken zou dat volgens Rogers een snelheidswinst van 250 procent moeten opleveren.

Een ander voorbeeld is memcached, waar de combinatie van cpu en gpu de prestaties kan verdrievoudigen ten opzichte van enkel de cpu - maar ook als alleen de gpu wordt gebruikt, is het programma langzamer dan bij een heterogene aanpak.

Er zijn ook al enkele consumentenapplicaties die gebruik kunnen maken van de gpu en daardoor significant sneller zijn dan wanneer enkel een cpu gebruikt wordt. De bekendste daarvan zijn Handbrake, Winzip, en Adobes Photoshop en Premiere. Maar hoewel Intel en AMD al miljoenen processors met een relatief snelle igp hebben verkocht en talloze pc's een losse videokaart aan boord hebben, is het aantal programma's dat ook daadwerkelijk de gpu gebruikt nog verwaarloosbaar klein - afgezien, uiteraard, van games.

Programmeren voor de gpu kost namelijk aanzienlijk meer tijd dan programmeurs gewend zijn. De onderstaande grafiek laat zien hoeveel code er met de diverse programmeermethoden nodig is, maar toont ook de prestatiewinst die er met een gpu te behalen is.

Met Intels C++-library Threaded Building Blocks nemen de prestaties fors toe, maar is ook meer dan twee keer zoveel code nodig. Worden er intrinsic functions gebruikt om de code meer parallel te maken, dan verdubbelt de benodigde hoeveelheid code nogmaals, maar dat loont wel: de prestaties verdrievoudigen. Gebruik van de open OpenCL-standaard weet de prestaties nog eens te verdubbelen, maar vergt ook weer wat meer code. In deze AMD-grafiek ontbreekt Nvidia's Cuda, maar omdat dat geen open standaard is, wordt deze library geen grote toekomst toegedicht.

Tijdens de Fusion Developer Summit kondigde AMD de HSA Foundation aan. Dit is een samenwerkingsverband met bedrijven als ARM, TI en Imagination, dat gaat werken aan de zogeheten Heterogeneous System Architecture. Het doel is om programmeren, voor ongeacht welke processor, net zo eenvoudig te maken als programmeren voor een 'klassieke' cpu. Daarbij kan de gpu pc's sneller maken, maar een cpu blijft noodzakelijk. Een symbiose tussen beide heeft wat AMD betreft dus de toekomst.

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)

[erikloman]

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

[Matis]

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 22 juli 2024 13:41]

[erikloman]

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.

[RSpliet]

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!

[erikloman]

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 22 juli 2024 13:41]

[H!GHGuY]

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.

[ppl]

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.

[SG]

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.

[RSpliet]

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 22 juli 2024 13:41]

[simplicidad]

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.

[RSpliet]

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 22 juli 2024 13:41]

[TunderNerd]

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

[RSpliet]

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.

[H!GHGuY]

Een GPU is een ASIC, geen FPGA.

[Anoniem: 415197]

Een GPU is tegenwoordig niet meer application specific.

[Reactie gewijzigd door Anoniem: 415197 op 22 juli 2024 13:41]

[GamingZeUs]

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.

[Anoniem: 415197]

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.

[Anoniem: 62201]

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

[Anoniem: 77640]

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.

[cannibal]

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.

[lezzmeister]

Dan gaan ze dus gewoon de kant van Powerpc op?

[Anoniem: 77640]

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.

[Whiskeyjack]

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.

[teacup]

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.

[blorf]

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.

[computerjunky]

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/

[RwD]

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?

[MneoreJ]

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.

[erikloman]

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

[PjotterP]

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

[Reactie gewijzigd door PjotterP op 22 juli 2024 13:41]

[Jasper Janssen]

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.

[SG]

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.

[sab]

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

[sdk1985]

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 .

[Marc Rademaker]

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.

[Deathchant]

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.

[Anoniem: 64119]

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.

[Anoniem: 325840]

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.

[bjp]

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.

[Madrox]

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.

[SG]

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.

[gitaarwerk]

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

[-=bas=-]

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

[teacup]

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.

[SG]

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.

[brugj03]

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

[Wannial]

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!

[bbob]

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.

[Wannial]

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.

[A87]

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 22 juli 2024 13:41]

[SG]

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.

[kh65]

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]

[SG]

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.