Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 74, views: 112.035 •

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)

Reactiefilter:-174072+151+211+31
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.
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]

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 :)
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.
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]

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.
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 twop 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.
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.
Mooi stuk, erg begrijpbaar uitgelegd!

Zoals gestelt: het is denk ik nu echt de taak van developers om de software beter te programmeren, en aan makers van compilers de developers makkelijker te maken.

Ik heb nu momenteel de Prescott cpu nog draaien, en draait stabiel. Je merkt uiteraard dat het flink traag is met zeg; 3d max, maar kan aardig mee nog voor webdesign werkzaamheden. Voor veel applicaties werkt het ding nog 'ok' tov nieuwe computers. En dan doel ik eigenlijk op de snelheidswinst van bijvoorbeeld de i7 3930k,.. (ok, ik overdrijf wel een beetje)

Je merkt dat de code van programma's niet alles uit het systeem halen, terwijl de systemen toch behoorlijk in snelheid is toegenomen (dan wel niet in MHz of cores).

Gpgpu's zijn erg interessant, en hoop dat deze beter benut gaan worden in de nabije toekomst :)
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.
Volgens mij omdat ze over veel meer cores beschikken dan een cpu (maar ik been geen cpu/gounkenner :))
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.
_/-\o_

mijn complimenten! Dit zijn artikelen die ik graag lees! Inhoudelijk in orde en duidelijk gebracht, zo mogen er meer achtergrond artikelen gemaakt worden.

@hierboven De hitte van CPU's komen voornamelijk door de hoge kloksnelheid en dat bij nog hogere klok de hitte en energieverbruik praktisch exponentieel begint te stijgen. het verbuik op GPU's is met z'n veel cores en geheugenverkeer wel relatief hoog, maar constanter en meer berekenbaar.

Ik vermoed zelf eigenlijk nog wel dat de schaalverkleining nog even kan doorgaan mits quantumcomputeren maar in ontwikkeling blijft en uiteindelijk ook eens zoden aan de dijk gaat zetten. Verder denk ik dat we ook nog wel gauw iets innovatiefs uit de IBM hoek zullen horen komen.
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
Als dit de toekomst is waarom zijn er dan nagenoeg geen aanwijzingen dat de technologie die richting op gaat.
Just askin............................. :)
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 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?
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 :)
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.
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.
gewoon ter info en voor de leken (myself included) onder ons dacht ik ineens aan dit super filmpje die een klein beetje het verschil tussen serial en parallel processing uitlegt (corrigeer me als ik het mis heb).

Mythbusters op Nvision 2008

http://www.youtube.com/watch?v=No4eUqdOSdw
Als ze met verfijnde technieken komen die 100Ghz mogelijk maken, dan wordt het dikke pret :P.
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.
Mooi artikel, heb ik veel van kunnen leren!

Op dit item kan niet meer gereageerd worden.