Razendsnel rekenen op je grafische kaart

Enorme versnellingen

Internet Explorer 9 maakt straks gebruik van de rekenkracht van de grafische kaart om vector graphics (html 5), teksten en multimedia te renderen. Ook Firefox 4 zal de gpu gebruiken voor hardwarematig opgevoerde weergave van vector graphics. In de technische en wetenschappelijke wereld zorgt general-purpose computing on gpu, ook wel bekend als gpgpu, al een paar jaar voor enorme versnellingen. Met de nieuwe browserversies komt deze technologie nu ook naar onze huis-, tuin- en keukencomputers.

Gpgpu betreft het uitvoeren van algemene rekentaken op een grafische processor. Computergames en technische en wetenschappelijke visualisaties vereisen veel meer rekenkracht dan bijvoorbeeld office productivity programma's. Een high-end gpu kan bepaalde taken honderden keren sneller uitvoeren dan de cpu; het probleem is dat deze verwerkingskracht alleen door heel specifieke algoritmen benut kan worden.

Het ontwerp van gpu's is van oudsher helemaal toegesneden op de verwerking van grafische elementen als bitmaps, pixels, kleuren en textures tot een beeld in de frame buffer. Dat betekent dat er maar beperkt ondersteuning is voor geheugentransacties, floating-point-bewerkingen en control-flow-instructies zoals loops en sprongen. Grafische processors zijn volledig geoptimaliseerd voor supersnelle, parallelle bewerkingen op grote matrices en andere grote datastructuren.

Hpc- en huis-tuin-en-keukengebruik

Cpu's en gpu's hebben heel verschillende programmeermodellen. General-purpose processors zijn gebaseerd op het principe van sequentiële executie. Centraal daarbij staat de control flow: de manier waarop data en hulpvariabelen worden gemanipuleerd om tot het juiste resultaat te komen.

Grafische processoren daarentegen werken volgens het streamprocessing-model. Daar draait alles om grote matrices waarop supersnel en parallel kleine berekeningen op de afzonderlijke elementen worden uitgevoerd. Dat is waarom gpu's veel grotere registerbanken en lokale geheugens hebben dan cpu's. Veranderingen in de control flow leveren hier enorme vertragingen op. In het algemeen kun je dan ook zeggen dat streamprocessing alleen geschikt is voor problemen met een grote data-parallelliteit, en met zo min mogelijk communicatie tussen de afzonderlijke elementen.

Programmeurs die de prestaties van de gpu willen benutten, moeten dus een goed massively parallel algoritme voor hun probleem vinden. Dat lukt vooral bij wetenschappelijke high-performance computing, in de financiële wereld en in de techniek: daar spreken we van hptc. Zo gebruiken ABN-AMRO, ING en BNP Paribas grafische processors voor hun Monte Carlo-berekeningen om risicomodellen door te rekenen. In de wetenschap en techniek worden GPU's ingezet voor beeld- en videoverwerking, snelle Fourier-transformaties, weersvoorspelling en klimaatonderzoek, cryptografie, neurale netwerken en spraakherkenning.

Multimedia

Maar ook voor de gewone huis-, tuin- en keukengebruiker begint gpgpu inmiddels interessant te worden. De grafische processor is daar met name geschikt voor multimediabewerkingen. In de toekomst zullen berekeningen die nu met behulp van SSE-instructies worden uitgevoerd, naar de gpu worden verplaatst. Zo werd onlangs een patent voor video-encoding op een gpu aan Microsoft toegekend.

Maar ook Internet Explorer versie 9, op dit moment in bèta, maakt gebruik van de grafische processor voor de rendering van HTML5. Daarvoor wordt gebruik gemaakt van Direct2D (vector graphics), DirectWrite (text rendering) en Media Foundation (multimedia). Firefox versie 4, ook in bèta, maakt eveneens gebruik van Direct2D. De komende jaren zullen ook andere parallelle werklasten naar de gpu worden verplaatst.

Helaas!
De video die je probeert te bekijken is niet langer beschikbaar op Tweakers.net.

Cuda versus Cell

Cuda

Op dit moment is Nvidia het verst in de ontwikkeling van gpgpu. Hun Cuda-toolkit is inmiddels de de facto standaard om grafische processors aan het werk te zetten. De Tesla-producten, gebaseerd op de GeForce 8 GPU's, zijn speciaal voor deze toepassing ontwikkeld. Ze beschikken over meer lokaal geheugen en hebben geen video-uitgang. Ook voor de normale videokaarten is echter Cuda-ondersteuning. AMD biedt vergelijkbare mogelijkheden met zijn Stream Technology, dat voorheen bekend stond als Close to Metal.

De afgelopen jaren heeft Nvidia zijn gpu's steeds beter geschikt gemaakt voor general-purpose toepassingen. Zo is de programmeerbaarheid verbeterd en werd shared memory toegevoegd. De belangrijkste uitbreiding voor wetenschappelijk gebruik is echter de ondersteuning van floating-pointberekeningen. Daarbij gaan single-precision-berekeningen inmiddels al behoorlijk snel, maar de double-precision-prestaties zijn nog beroerd. Zo levert de Tesla Personal Supercomputer, voorzien van vier gpu-modules, respectievelijk 933Gflops en 78Gflops. Dat scheelt meer dan een factor tien.

Cell

De grootste concurrent van Nvidia in de gpgpu-markt is IBM. Samen met Sony en Toshiba ontwikkelde dit bedrijf de Cell-processor voor de PlayStation 3. Nadat grootverbruikers van rekenkracht stapels PS3's begonnen te bundelen tot grote rekenclusters, kwam IBM met Cell-processors op een blade. De PS3-systemen concurreren immers direct met IBM's Blue Gene-hardware.

Astron, het Nederlandse Instituut voor Radioastronomie, onderzoekt momenteel bijvoorbeeld of ze hun huidige IBM-supercomputer voor de Lofar-telescoop moeten vervangen door een op Cuda of Cells gebaseerd systeem. De huidige Blue Gene heeft een capaciteit van 42Tflops. Tien ATI 5970-kaarten zouden, als ze optimaal kunnen worden benut, dezelfde verwerkingskracht kunnen leveren.

Dat Astron deze afweging kan maken, heeft te maken met het algoritme voor de verwerking van de rauwe data. Lofar levert enorme hoeveelheden gegevens - met 200Gbps is dit project een van de grootste dataverwerkers ter wereld - maar het gaat daarbij om single-precision-elementen die grotendeels onafhankelijk van elkaar bewerkt moeten worden.

Probleem: parallelliseren

In het algemeen is het parallelliseren van software juist een enorm probleem. Ten eerste moet een parallel algoritme worden gevonden. Dat lijkt eenvoudig maar dat is het geenszins. Sterker nog, er zijn theoretische grenzen aan de parallelliseerbaarheid van algoritmen. De Wet van Amdahl stelt dat de maximale versnelling wordt bepaald door de sequentiële onderdelen die niet kunnen worden geparallelliseerd. Daarnaast moet een parallel algoritme geschikt zijn voor de beschikbare hardware: er moet dus een goede balans zijn tussen de verwerkingskracht en de communicatiecapaciteit tussen de elementen.

Deze problematiek is momenteel bijzonder actueel. Vanwege het energieverbruik maken Intel en AMD extra performance niet meer beschikbaar via hogere kloksnelheden maar in de vorm van meerdere rekenkernen. Het blijkt echter een groot probleem te zijn om software te schrijven die deze extra capaciteit kan benutten. Bjarne Stroustrup en James Gosling, de uitvinders van respectievelijk C++ en Java, hebben beide hun zorgen uitgesproken over de programmeerbaarheid van de manycore-processors. Wetenschappers werken op dit moment aan nieuwe functionele programmeertalen die gemakkelijker door de compiler naar parallelle executables kunnen worden omgezet. Met hetzelfde doel heeft Intel de programmeertaal Ct ontwikkeld. Die is inmiddels gepubliceerd onder de naam Array Building Blocks, oftewel arrBB. Ook de volgende versie van C++ zal nieuwe mogelijkheden voor parallellisme ingebakken krijgen.

Het automatisch parallelliseren van broncode is echter een probleem waarop computerwetenschappers zich decennia lang vergeefs de tanden hebben stukgebeten. Paul Klint, hoofd van de Software Engineering groep bij het Amsterdamse Centrum Wiskunde & Informatica, spreekt dan ook van de heilige graal van de informatica.

OpenCL

Een lichtpuntje bij dit alles is opkomst van OpenCL als gemeenschappelijke taal voor het programmeren van gpgpu-toepassingen. Cuda mag dan de de facto standaard van dit moment zijn, maar deze Nvidia-architectuur is niet portable. Inmiddels hebben AMD, IBM, Intel en Nvidia zich allemaal achter OpenCL geschaard. De snelheid van de executables haalt het nog lang niet bij die van Cuda-code maar het verschil wordt steeds kleiner. OpenCL-software is overigens ook niet portable over verschillende hardware-platformen, omdat de code nog steeds topologie-specifieke zaken bevat. Wel spreken gpgpu-programmeurs straks allemaal dezelfde taal.

Het mag duidelijk zijn dat gpgpu op dit moment nog niet volwassen is, maar wel enorme kansen biedt om computersystemen heel veel sneller te maken. De komende jaren zullen de snelste computersystemen ter wereld worden opgebouwd uit grafische processoren. Onlangs werd bekend dat de Chinezen de capaciteit van hun snelste supercomputer hebben verdubbeld. Dat systeem maakt gebruik van nVidia-blades en zou nu het snelste systeem ter wereld zijn.

Er wordt algemeen aangenomen dat gpgpu bepaalde toepassingen honderden keren kan versnellen. Een enkele wetenschapper weet zijn software zelfs met een factor duizend te versnellen. Dat moet echter wel in perspectief worden geplaatst: de geschiedenis heeft geleerd dat dergelijke grote stappen vaak meer dan tien jaar kosten. Toen het Amerikaanse DARPA bedrijven als IBM, Cray en SGI vroeg of zij binnen zeven jaar Exascale-computers konden ontwikkelen, bleek dit niet haalbaar.

Reacties (114)

[Anoniem: 380368]

In Eyeon Fusion 6.1 werk ik nu veel véééél sneller dankzij openCL en renderen op de graka.
In 3dsmax heb ik nu met de renderer Vray 2.00.02 ook enorme snelle feedback dankzij gpu computing. Vroeger (tot een jaar of 2 geleden) moest je steeds op F9 duwen om een render te maken, nu verandert bijna alles in realtime.

Dit alles op spotgoedkope hardware, dit is echt de grootste verandering in 3d sinds 1995. Vroeger was alles enorm duur, beginnen met 3d en visual effects was moeilijk en onbetaalbaar, dat behoort nu tot het verleden alleszins.

De fotorealistische unbiased renderers zijn er al (maxwell oa), die renders hebben wel nog even hun tijd nodig om een noisefree beeld te maken, maar binnen een paar jaar zal dat ook iets van het verleden zijn.

Het gaat momenteel snel in deze wereld, het is om schrik van te krijgen ;-)

[Reactie gewijzigd door Anoniem: 380368 op 23 juli 2024 05:29]

[Villean]

Helaas komt 9 van de 10 keer je RT scene niet overeen met je "gewone" render qua licht dus ik vind het vrij nutteloos. Ook worden niet alle functies ondersteund. Het enige waar ik het voor zou gebruiken is om de belichting goed in te stellen maar dat werkt dus niet naar behoren. Ook is de GPU versie langzaam met inladen van data. Als je een beetje gewent bent met Vray kan je vaak in je GI berekening al zien hoe het er uit komt te zien.

Maar dat terzijde..Vray 2 is wel een hele goede release!

[StackMySwitchUp]

JA! wegens Vray RT wil ik een array aan nvidia kaarten bouwen, de performance gain is echt idioot.

Ik heb een i7 980x en 3 nvidia kaarten die bij elkaar de helft kosten kunnen bij elkaar ongeveer 60 keer sneller previewen/renderen.

[TylerHam]

Ik draai het project MilkyWay@Home via BOINC ook deels via de videokaart en dit scheelt echt gigantisch. Als er een workunit loopt via de processor op 2,75 GHz (C2D) dan is deze denk ik zo'n 10-12 uren bezig gok ik, maar als er 1 bij zit die via de Radeon 4800 gaat is deze in 5-6 minuten klaar

[Anoniem: 77640]

MilkyWay@Home maakt dan ook gebruik van grafische taken. BOINC gebruik extreem trage emulatie (via Mesa 3D) wanneer die op de CPU uitgevoerd worden.

Ter vergelijking, SwiftShader is honderd keer sneller dan de Microsoft Reference Rasterizer. SwiftShader is dan ook een implementatie, en geen emulator.

Het grote verschil in snelheid voor BOINC is dus niet te danken aan de mogelijkheden van de GPU, maar aan de onkunde van de ontwikkelaars om te optimialiseren voor de CPU. Als ook maar een fractie van de tijd die men spendeerde om te optimaliseren voor de GPU, gebruikte om te optimaliseren voor de CPU, zou je al een heel ander beeld krijgen.

Een gelijkaardig verhaal heb je ook voor PhysX: http://realworldtech.com/...cleID=RWT070510142143&p=1. Door niet te optimaliseren voor de CPU wekt NVIDIA de indruk dat z'n GPUs veel sneller zijn, terwijl goed geoptimaliseerde bibliotheken juist tonen dat je deze berekeningen best over laat aan de CPU.

[Reactie gewijzigd door Anoniem: 77640 op 23 juli 2024 05:29]

[Anoniem: 77640]

Er wordt algemeen aangenomen dat gpgpu bepaalde toepassingen honderden keren kan versnellen.

Dat is je reinste onzin. Zelfs voor "bepaalde" toepassingen is een factor honderd onhaalbaar.

In veel GPGPU tests maakt men de vergelijking met ongeoptimaliseerde single-threaded code. Door gebruik te maken van SSE en multi-threading kan je doorgaans tien keer hogere prestaties behalen.

Een quad-core CPU haalt 100 GFLOPS. Dat is minder dan de 3 TFLOPS die een high-end GPU zou kunnen halen, maar in de praktijk is de CPU véél efficiënter. Een bewijs dat TFLOPS weinig betekenen is dat NVIDIA's GPUs met de helft aan theoretische rekenkracht de GPUs van AMD verslaan. En dat voor graphics, iets dat extreem parallel is en waar de GPU dus erg goed in is. Voor GPGPU-toepassingen is efficiëntie nog véél belangrijker.

Komend jaar worden trouwens de Sandy Bridge en Bulldozer architecturen gelanceerd, en die ondersteunen AVX, wat de vectorlengte verdubbelt (en dus het aantal GFLOPS). De volgende architectuur introduceert ook FMA, wat de rekenkracht nogmaals verdubbeld, zonder veel extra transistors te kosten. Dus bovenop de verhoging van het aantal cores krijgen CPUs een verviervoudiging van de rekendichtheid. De GPU's rekendichtheid daalt daarentegen. Er zijn steeds meer registers en caches nodig om langere code te ondersteunen, met meer sprongen en meer divergente geheugentoegangen met langere latency.

De twee convergeren dus dichter naar elkaar. Zelfs vandaag reeds verslaat de CPU met SwiftShader IGPs en low-end GPUs. En dat is voor graphics! Met ondersteuning voor gather/scatter instructies zouden zelfs mid-end GPUs ingehaald worden.

[Reactie gewijzigd door Anoniem: 77640 op 23 juli 2024 05:29]

[Madrox]

Voor bepaalde toepassingen kan het zeker tientallen keren sneller, als je dit mag geloven:
http://www.organicvectory...=article&id=125&Itemid=89

Zo stellig als jij het ontkent, doe ik dan ook niet. Wel zijn dit soort versnellingen zeer specifiek en vooral gericht op specialistische taken. Je zal dit soort versnellingen dan ook niet vaak (gaan) tegenkomen.

[Anoniem: 77640]

Voor bepaalde toepassingen kan het zeker tientallen keren sneller, als je dit mag geloven:
http://www.organicvectory...&id=125&Itemid=89

Voor grafische toepassingen is in het beste geval een factor 30 haalbaar: Anoniem: 77640 in 'reviews: Razendsnel rekenen op je grafische kaart'. Er is niks waar de GPU beter in is dan grafische taken. Iemand die dus een hogere factor vernoemt maakt dus een vergelijking met slecht geoptimaliseerde code voor de CPU, wat uiteraard niet correct is. Code die niet aagepast is om op de GPU te draaien is ook makkelijk honderd keer trager, maar da's net zo min een eerlijke vergelijking van de werkelijke mogelijkheden.

En bemerk dat het hier gaat om GPGPU-toepassingen. Dat zijn dus niet-grafische toepassingen (anders had men het GPU-toepassingen genoemd). Daarbij is het verschil gegarandeerd kleiner dan een factor 30, aangezien de GPU bij grafische taken veel voordeel haalt uit z'n texture samplers, ROPs, setup engines, en andere zaken specifiek voor graphics die de CPU niet bezit.

Qua SP rekenkracht is een GPU in het beste geval een factor 10 sneller, en voor DP een factor 5 of minder. Maar dat is theoretische rekenkracht. De GPU is vooral geschikt voor korte coherente berekeningen zoals die bij grafische taken voorkomen, maar bij complexe divergente berekeningen gaan de prestaties heel snel achteruit.

Voor GPGPU-toepassingen is een factor 10 dus het allerbeste dat je kan verwachten (bij een eerlijke vergelijking). Maar zoals je zelf ook aangeeft zal je dat niet vaak tegenkomen. En ik kan je uit eigen ervaring vertellen dat de gemiddelde PC nog helemaal niet klaar is voor GPGPU-toepassingen. De meest verkochte grafische chips zijn niet die van NVIDIA of AMD, maar de IGPs van Intel. En die hebben minder theoretische rekenkracht dan de CPU. In de praktijk zijn ze dus volstrekt onbruikbaar voor GPGPU...

[robvanwijk]

Een bewijs dat TFLOPS weinig betekenen is dat NVIDIA's GPUs met de helft aan theoretische rekenkracht de GPUs van AMD verslaan. En dat voor graphics, iets dat extreem parallel is en waar de GPU dus erg goed in is.

Het zijn allebei GPUs, dus hoe parallel het al dan niet is maakt geen bal uit, dat is alleen interessant als je een GPU met een CPU vergelijkt.

Edit: "De onzin van mijn uitspraak"? Ik zie vooral in dat we elkaar waarschijnlijk verkeerd begrijpen.

Komend jaar worden trouwens de Sandy Bridge en Bulldozer architecturen gelanceerd, en die ondersteunen AVX, wat de vectorlengte verdubbelt (en dus het aantal GFLOPS).

Daar heb je alleen iets aan als je vector ook daadwerkelijk zo lang is. Voor een vector van twee elementen blijft het aantal FLOPS hetzelfde. Andere wijzigingen in de architectuur hebben natuurlijk ook invloed, dus exact hetzelfde zal het niet zijn.

Edit: Ik had het over de situatie waar je maar twee elementen op wilt tellen. Dat is de beperking van SIMD, je moet wel genoeg werk aanbieden anders gaat er capaciteit verloren. Net zoals het optellen van twee 8-bit getallen op een moderne (64-bit) processor; de bovenste 56 bits worden wel gewoon uitgerekend, maar daar schiet je niks mee op. Ja, met sub-word parallellism / SIMD had je daar "gratis" meer 8-bit getallen op kunnen tellen, maar alleen als je op dat moment in de code meer 8-bit optellingen wilt doen.

[Reactie gewijzigd door robvanwijk op 23 juli 2024 05:29]

[Anoniem: 77640]

Daar heb je alleen iets aan als je vector ook daadwerkelijk zo lang is. Voor een vector van twee elementen blijft het aantal FLOPS hetzelfde.

Dat vormt geen enkel probleem. Je kan immers net zoals de GPU elementen in parallel verwerken. Met name de architectuur van NVIDIA gebruikt SIMD vectoren van 16 elementen breed. Elke component van een vector binnen de shader wordt in een register opgeslagen. Dus voor 16 pixels twee vectoren van twee componenten optellen, vergt twee instructies die 16 elementen in parallel optellen.

Veel mensen lijken dit eenvoudige principe niet te snappen, waardoor ze code schrijven die niet optimaal loopt op de CPU. Doch kan je gewoonweg SIMD code schrijven en expliciet doen wat de GPU eerder impliciet doet.

Hetzelfde geldt trouwens voor het aantal stands. Sommigen beweren dat de GPU superieur is omdat duizenden strands in parallel draaien en daardoor de geheugenlatentie verborgen wordt. Echter kan je net hetzelde op de CPU doen, door meermaals dezelfde bewerking uit te voeren maar dan op andere data.

Het zijn allebei GPUs, dus hoe parallel het al dan niet is maakt geen bal uit, dat is alleen interessant als je een GPU met een CPU vergelijkt.

De CPU ondersteunt net dezelfde technieken (SIMD en strands) als de GPU. Ik hoop dat je
nu dus zelf de onzin van je uitspaak inziet.

[Reactie gewijzigd door Anoniem: 77640 op 23 juli 2024 05:29]

[morrowyn]

Je functies binnen je eigen applicatie moeten wel te parallelliseren zijn. Een simpel voorbeeld is een for loopje.

Stel je hebt een array met data en je loopt er x aantaal keer over heen en elke iteratie kan je die array atomisch benaderen en gebruiken. Dan kan je die for loop perfect op delen in x aantal onafhankelijke parallelle functies.

Dit boek legt het redelijk goed uit mbt de nvidia gpu. Je hebt natuurlijk ook de standaard algemene boeken, waarvan deze een aanrader is.

[phoenix]

Maar stel dat je in je for loopje een dependency hebt, bijv. in iteratie n maak je een wijziging in je array en in iteratie n+1 doe je iets met die gewijzigde data. Dat kun je niet tegelijk doen; dit is een voorbeeld van een sequentieel onderdeel (zie wet van Amdahl in het artikel) wat de maximale versnelling van je programma bepaalt.

Ik denk dat het programmeermodel veranderd moet worden. In huidige programmeertalen moet je expliciet parallelle code schrijven. Als je als programmeur alleen de dependencies hoeft aan te geven dan heeft de compiler daarmee theoretisch gezien genoeg informatie om de code zelf te parallelliseren. Onder andere op de VU wordt hiernaar onderzoek gedaan om deze theorie ook in de praktijk te brengen. Google Go (de taal) is ook een goede stap in deze richting. Ik ben erg benieuwd naar de landscape over 5 jaar...

[morrowyn]

Dat is precies wat ik zei, je code moet wel te parallelliseren zijn. Het simpele voorbeeld zal in de praktijk zelden tot nooit voorkomen.

In jouw voorbeeld is de for loop niet meer atomisch te noemen omdat je in je je n-de iteratie iets met n+1 gaat doen en dus zal je die loop nooit van ze leven lang kunnen parallelliseren. Je zal dan moeten gaan werken met synchronisatie, locks, etc. Om zoveel mogelijk zooi parallel te kunnen uitvoeren.

Ik denk dat de grootste euvel die overwonnen moet worden, de denkwijze van de programmeur is. Een programmeertaal en compiler zijn niet meer dan tools voor de programmeur om die gedachten te kunnen realiseren. Zolang een programmeur sequentieel blijft denken zal zijn code nooit parallel kunnen laten uitvoeren.

[Jooz]

Tegenwoordig zijn de grote commerciële render programmes ook al CUDA-based.
(Vray 2.0 bijv.). Octante doet hier zeker goede zaken in.

Dus als GPGPU niet voor wetenschappelijke toepassingen gebruikt zal worden zal de Film en Game-industrie zeker wel hun voordeel hier uit halen.

[simplicidad]

SmallLuxGPU niet vergeten ! Die neemt anandtech nu ook mee in hun reviews van videokaarten

http://www.luxrender.net/wiki/index.php?title=SLG

Bij luxrender zie je het verschil enorm omdat ze een "klassieke" render hebben die gebruikmaken van de CPU en smallluxgpu (ook al heeft het op dit moment wel minder features) die gebruikt maakt van de GPU (of een combinatie)

Als je die twee naast elkaar zet dan is het verschil enorm als ik iets moet renderen.

Mij moeten ze echt niet meer wijzen op het nut van die zaken.

[Reactie gewijzigd door simplicidad op 23 juli 2024 05:29]

[YaaD]

Wat ik mij afvraag is, hoe het komt dat het pas in 2010 is ontdekt... GPU's en CPU's bestaan al enige tijd namelijk. Iemand hier een duidelijk antwoord voor?

Een factor 1000 op een is natuurlijk ongelovelijk. Als je dan terugdenkt, hoeveel tijd er vroeger verloren is gegaan

[Anoniem: 77640]

Wat ik mij afvraag is, hoe het komt dat het pas in 2010 is ontdekt... GPU's en CPU's bestaan al enige tijd namelijk. Iemand hier een duidelijk antwoord voor?

Pas sinds de Fermi architectuur is de GPU min of meer in staat om dezelfde bewerkingen als de CPU uit te voeren.

Een factor 1000 op een is natuurlijk ongelovelijk.

Het is dan ook bullshit.

Een GPU-core is in feite erg traag. Een bewerking uitvoeren duurt meer dan tien keer langen dan op op een CPU. Echter omdat men iedere klokcyclus een nieuwe bewerking kan starten voor onafhankelijke data kan je door extreem te paralleliseren er toch hoge totale prestaties uithalen.

Maar de CPU-technologie staat ook niet stil. Via vectorbewerkingen en multi-core haalt men voor parallele werklasten ook veel hogere prestaties. Tenminste, als men er gebruik van maakt. Maar al te vaak worden GPGPU applicaties vergeleken met ongeoptimaliseerde code voor de CPU. En dat terwijl ze net zo makkelijk/moeilijk te paralleliseren zijn. Een incorrecte vergelijking dus, en een factor 1000 is nonsens.

Bovendien gaat de GPU op z'n gat als je code hebt die meer registers per strand gebruikt als de architectuur optimaal ondersteunt. Lange code met veel spronginstructies en een stack voor de functieargumenten kan je dus wel vergeten. Daar blinkt de CPU nog steeds in uit.

Als je dan terugdenkt, hoeveel tijd er vroeger verloren is gegaan.

Er is niks tijd verloren gegaan. Een GPU is waardeloos zonder een CPU die de niet paralleliseerbare taken in de driver en de applicatie uitvoert.

Binnen tien jaar is de GPU wellicht zelfs met uitsterven bedreigd. Vectorbewerkingen en multi-core zorgen ervoor dat de CPU dezelfde parallele verwerkingsmogelijkheden krijgt als de GPU, terwijl de GPU om z'n efficiëntie met lange complexe code te verbeteren rekendichtheid zal moeten opofferen.

De Sandy Bridge architectuur krijgt reeds een IGP op dezelfde 'die' als de CPU. De cache wordt gedeeld, dus het is maar een kleine volgende stap om de CPU-cores de taak van de GPU-cores over te laten nemen. AVX met FMA verviervoudigt de rekenkracht, en met gather/scatter ondersteuning kan men efficiënt texturen bemonsteren. De laatste dagen van de IGP en daarmee ook low-end GPUs zijn reeds geteld. En daar zal het niet stoppen.

Het is niet voor niks dat NVIDIA erg wanhopig is om een x86 licentie te bemachtigen. Als Intel en AMD met hun APUs de low-end en mid-end markt van NVIDIA wegsnoepen dan blijft er maar weinig over om op te kunnen overleven...

[Reactie gewijzigd door Anoniem: 77640 op 23 juli 2024 05:29]

[robvanwijk]

> Een factor 1000 op een is natuurlijk ongelovelijk.
Het is dan ook bullshit.

Waarom zou het bullshit zijn? Een GPU is van de grond af aan helemaal ontworpen om (eenvoudige) taken te verwerken. Daardoor kunnen de cores, in vergelijking tot CPU-cores, extreem klein zijn, zodat er zeer veel op een die passen. Meer dan duizend stream processors (cores) op een enkele kaart is al mogelijk, terwijl CPUs (voor consumenten) nog niet verder komen dan zes cores. Tuurlijk, een enkele CPU-core is veel krachtiger dan een GPU-core, maar er zijn algorithmen waarbij je met die extra kracht (zoals drie cache levels, OoO-hardware, etc.) niks kunt, zodat die "verloren gaat".
In combinatie met het feit dat je hardware efficiënter (sneller) kunt gebruiken als de programmeerbaarheid afneemt (DSPs zijn 1000x zo snel als CPUs, voor de functie waarvoor ze gemaakt zijn) verbaasd het me niks als een GPU duizend keer zo snel is als een CPU, mits het natuurlijk een taak is die een GPU efficiënt uit kan voeren.

Lange code met veel spronginstructies en een stack voor de functieargumenten kan je dus wel vergeten. Daar blinkt de CPU nog steeds in uit.

Ehm ja, maar dat stond ook al in het artikel...

Binnen tien jaar is de GPU wellicht zelfs met uitsterven bedreigd.

Ik spreek je nog wel in 2020.
Overigens, de rest van je argumentatie komt nogal neer op "als we een CPU en een GPU op een enkele die bouwen dan moet dat CPU heten en is de GPU dus verdwenen". Je kunt natuurlijk vechten over naamgeving en definities, maar dat vind ik niet helemaal "eerlijk".

[Anoniem: 77640]

Meer dan duizend stream processors (cores) op een enkele kaart is al mogelijk, terwijl CPUs (voor consumenten) nog niet verder komen dan zes cores.

Je laat je vangen door de verkoopspraat.

Wat de GPU-fabrikanten een core noemen is helemaal geen core, maar een ALU. Een GF110 bijvoorbeeld telt vier echte cores, met elk 128 ALUs. Hij kan zo asynchroon bewerkingen uitvoeren op 8 vectoren van 16 elementen, maar de instructies behoren binnen een core tot hetzelfde programma.

De CPU heeft per core twee vectorrekeneenheden van 4 elementen. Een 6-core CPU beschikt dus over 48 ALUs. En omdat ze ook nog eens hoger geklokt zijn, loopt een CPU heus niet zo heel veel achter op de GPU. En een CPU heeft veel minder beperkingen en kan efficiënt om met minder coherente geheugentoegangen.

Vanaf 2011 krijgen we CPUs met vectoren die 8 elementen breed zijn. De verwerkingsdichtheid verdubbelt dus, zonder veel extra transistors te vereisen.

Overigens, de rest van je argumentatie komt nogal neer op "als we een CPU en een GPU op een enkele die bouwen dan moet dat CPU heten en is de GPU dus verdwenen". Je kunt natuurlijk vechten over naamgeving en definities, maar dat vind ik niet helemaal "eerlijk".

Neen, dat is niet mijn argumentatie. De hybride architectuur verdwijnt, en alle bewerkingen worden generiek. Dan is er sprake van een CPU en niet van een GPU.

Tien jaar geleden waren GPUs niet eens programmeerbaar. Let op mijn woorden; binnen nog eens tien jaar houdt men niks van hardware over dat specifiek voor grafische berekeningen dient. Zelfs textuurbemonstering wordt programmeerbaar, via generieke gather/scatter bewerkingen.

CPUs missen nog gather/scatter ondersteuning, maar niet voor lang. En dan is een CPU met veel cores net zo goed in grafische taken als de GPU. Het is dan efficiënter om alles te verwerken op een homogene architectuur dan een heterogene architectuur waarvan beide delen nagenoeg identiek zijn. Data uitwisselen tussen de CPU en GPU heeft op dit moment nog een veel te hoge latentie voor een groot aantal toepassingen.

[Reactie gewijzigd door Anoniem: 77640 op 23 juli 2024 05:29]

[narotic]

Het is bullshit omdat de theoretische grens geen factor 1000 verschilt. Een moderne high-end processor haalt rond de 100 Gflop/s (double precision). Een moderne high-end GPU haalt 500 Gflop/s (double precision). Theoretisch heeft een GPU dus in de grootorde 5-10 keer zoveel rekenkracht (het verschil voor single precision is groter, zeg maximaal 50).

Met andere woorden, een factor 1000 is niet realistisch en geeft aan dat de CPU implementatie verre van optimaal was.

[Reactie gewijzigd door narotic op 23 juli 2024 05:29]

[Madrox]

Die factor 1000 geldt alleen voor een speciek, wetenschappelijk stukje code/software. Leuk voor de statistieken, maar dit soort versnellingen zal je in reallife zelden/nooit meemaken.

[Anoniem: 77640]

Die factor 1000 geldt alleen voor een speciek, wetenschappelijk stukje code/software.

Neen, die factor geldt niet. Men vergeleek geoptimaliseerde code voor de GPU met ongeoptimaliseerde code voor de CPU. Ja zo kan ik ook een applicatie schrijven die 1000 keer sneller draait op de CPU dan op de GPU hoor.

Een Core i5 en GTX 460 zijn ongeveer even duur, en gebruik makend van SwiftShader is de GPU in grafische benchmarks maximaal 30 keer sneller dan de CPU. Merk op dat dit voor grafische toepassingen is! Dit is voor de GPU het best-case scenario. Meer dan een factor 30, in een eerlijke vergelijking, is dus onmogelijk.

En GPUs verliezen heel snel aan efficiëntie bij niet-grafische applicaties. Dan hebben ze immers geen nut van hun texture samplers, ROPs, rasterizers, setup engines, etc. En met ondersteuning voor gather/scatter, zou de CPU dan weer véél efficiënter zijn voor grafische taken. Dus die factor 30 zal de komende jaren enkel maar verkleinen.

[poktor]

Eens. Het is al te zien aan het feit dat Intel en AMD inmiddels zijn begonnen met het fuseren van GPU en CPU. Deze lijn zal steeds verder worden doorgetrokken, m.a.w. er zal steeds meer GPU architectuur in de CPU verwerkt worden, puur vanwege de snelheidswinst die hiermee behaald kan worden en het geld wat men uitspaart omdat er voor het low- en middensegment straks geen losse GPU's hoeven te worden ontwikkeld en geproduceerd. Dit is dus een logische stap. Ik denk dat deze stap zal worden gevolgd door de fusie met north- en southbridge op dezelfde die, zodat ook deze chips straks kunnen komen te vervallen. Wat overblijft, is het RAM-geheugen, de voeding en connectors op het moederbord, de rest is ingebakken in de CPU. Lekker simpel, snel en lekker goedkoop produceren.

[Reactie gewijzigd door poktor op 23 juli 2024 05:29]

[MicGlou]

In de technische en wetenschappelijke wereld zorgt general-purpose computing on gpu, ook wel bekend als gpgpu, al een paar jaar voor enorme versnellingen. Met de nieuwe browserversies komt deze technologie nu ook naar onze huis-, tuin- en keukencomputers.

Dit is niet een recente ontdekking, zoals het artikel al aangeeft wordt het in bepaalde industrieën e.d. al een aantal jaren gebruikt. De reden waarom het nu pas naar de thuis-pc komt staat in principe ook in het artikel; ondanks dat de theorie hierover vrij helder is, is het toepassen een heel ander verhaal. Het betekent sowieso dat bepaalde software compleet herschreven moet worden om (optimaal) gebruik te kunnen maken van hardwareversnelling dmv gpu of het gebruik maken van meerdere cores in een cpu.

[Reactie gewijzigd door MicGlou op 23 juli 2024 05:29]

[Madrox]

1) GPU's zijn net als CPU's in de loop der jaren steeds krachtiger geworden.
2) Een GPU is niet te vergelijken met een CPU, je zal altijd een CPU(achtige kern) nodig hebben. Een CPU is nml. een alleskunner en dat moet ook, alles is erom heen gebouwt als het ware. Een GPU is een speciek soort kern die tot voor kort alleen voor pixel verwerking diende.
3) Nu GPU's zo krachtig zijn (al zijn ze functioneel beperkt) met heel veel "mini cores" is het logisch dat we die potentionele kracht ook meer gaan benutten. Nu staat de GPU, als je niet gamed over gpu-rendering doet, er meestal werkloos bij.
4) Parallel programmeren is een harde noot om te kraken, de specialisten buigen zich er al decennia over. De progessie gaat moeizaam.

Denk trouwens niet dat de GPU voorgoed gaat verdwijnen, zoals hierboven geoppert word.
Simpelweg omdat twee kleinere core oppervlakken makkelijker te koelen is dan 1 grote. O.a. geeft het meer flexibiliteit, omdat je de hitte dan op meerdere plaatsen kan afvoeren.

[Reactie gewijzigd door Madrox op 23 juli 2024 05:29]

[Brawler1986]

Denk trouwens niet dat de GPU voorgoed gaat verdwijnen, zoals hierboven geoppert word.
Simpelweg omdat twee kleinere core oppervlakken makkelijker te koelen is dan 1 grote. O.a. geeft het meer flexibiliteit, omdat je de hitte dan op meerdere plaatsen kan afvoeren.

Dit is precies wat ik wilde zeggen, als alles inderdaad op 1 chip wordt gezet, wordt het gevraagd vermogen ook gigantisch. Tegenwoordig is het al lastig om processors in een kleine behuizing te koelen. Laat staan als alles wordt geintegreerd in een processor. Nog even en dan hebben we een PC met 1 mega koelblok nodig om dat allemaal te koelen en dan is waterkoeling een vereiste.

[djgerry300]

Het is goed dat ze de rekenkracht willen vergroten maar is enkel het paralellelliseren genoeg om grote prestatiewinst op te kunnen leveren?

Ik denk dat ze nog enkele factoren over het hoofd zien al weet ik niet direct wat...

[robvanwijk]

Het is goed dat ze de rekenkracht willen vergroten maar is enkel het paralellelliseren genoeg om grote prestatiewinst op te kunnen leveren?

Laten we het hopen, want heel veel andere opties voor grote vooruitgang in prestaties zijn er niet meer:
- Het verder verhogen van kloksnelheden wordt steeds lastiger; je stroomverbruik (en dus benodigde koeling en de dikte van de sporen!) schiet dan omhoog.
- Er zijn weinig berekeningen waarvoor 64 bit integers niet toereikend zijn, dus naar 128 bit integers gaan helpt weinig. (Een 128 bit register gebruiken als 4x 32 bit ("subword parallellism") is een vorm van parallellisme (die je ook met 4 32 bit cores zou kunnen bereiken), dus dat "telt niet", bovendien loop je dan uiteindelijk tegen dezelfde practische problemen aan). Hetzelfde geldt voor double precision floats; er zijn nauwelijks toepassingen waar die niet nauwkeurig genoeg zijn of de exponent niet groot (of klein) genoeg kan worden. (Laatste wat ik ervan gehoord heb zijn zelfs single precision floats vaak meer dan voldoende.)

Dus als we niet meer instructies per kloktik (kloksnelheid) of meer werk per instructie (registerbreedte) dan zit er eigenlijk maar één ding op: meer cores ertegenaan gooien.

[Anoniem: 28958]

Er is nog heel veel ruimte om sneller te gaan, maar alleen moet dan de computer in zijn geheel opnieuw uitgevonden worden, maar daar zijn ook mensen mee bezig. Er zitten nog wat fysische haken en ogen aan, maar qua plan van hoe andere computers zouden kunnen werken zijn ze al helemaal klaar.

Als een andere theorie klopt, dan is er overigens geen maximale single-threaded performance, d.w.z. je zou arbitrair snel moeten kunnen rekenen.

[Madrox]

Meer cores alleen is niet voldoende natuurlijk, je moet ook software hebben die het ook benut. Zoals ik het nu zie, is de kar er al maar moeten er nog paarden voor gespannen worden (of andersom).

De vraag is alleen: gaat het echt lukken. De wetenschap bijt zich er al decennia lang stuk op, er zijn wat successen maar het is nog lang niet voldoende. Er is nog een hoop te winnen.

Staat toevallig ook een goed stuk over dit onderwerp in de laats HW info magazine, waar ze bijv. uit de doeken doen dat encoden via de GPU nog lang niet zaligmakend is. Kan dat beamen; hoewel het snel gaat met cuda of Ati's encoder tool; de kwalteit is droevig naar mijn smaak. In het artikel meld een insider in deze materie, dat het wel beter kan maar dat er van de 9X versnelling er nog maar een faktor 4 overblijft. Zelfs dan is de kwaliteit niet vergelijkbaar met cpu-encoding, het blijft dan ook nog steeds appels met peren vergelijken. Dat is spijtig, want wie wil er nou niet een supersnelle MPEG-4 encoder, die perfecte encodings uitspuugt ?

Hoop dat Microsofts encoding software (zie deal) meer kwaliteit bied, want daar zitten de encoding kiddies op te wachten.

[Reactie gewijzigd door Madrox op 23 juli 2024 05:29]

[Skohsl]

Voor specifieke algorithme loont het inderdaad de moeite om te paralelliseren. Het vragen naar 'genoeg' is wat lastig, wat is 'genoeg'. Zoals je al kan zien in het laatste stuk dat paralelliseren niet tot in de eeuwigheid snelheidswinst gaat opleveren. Enkel paralelliseren kan dus nooit genoeg zijn (tenzij je algorithmen kan schrijven die 100% paralelliseerbaar zijn).

[pietermx]

M.b.t. het probleem "parallelliseren van software": Het is natuurlijk waar dat er veel software is (en zal blijven) dat niet gebruik kan maken van meerdere (of alle beschikbare) cores in een systeem. Dat wil echter niet zeggen dat het geen voordeel heeft om meer cores beschikbaar te hebben, aangezien er vrijwel geen systemen zijn waarop maar één applicatie draait...

Neem bijvoorbeeld een server, hierop draaien vaak zoveel processen parallel dat het al minder ter zake doet of deze individuele processen gebruik maken van meerdere cores.

[phoenix]

Natuurlijk, maar de snelheid van één proces is ook belangrijk aangezien je als gebruiker meestal maar één ding tegelijk doet. Wat je zegt is als je een filmpje draait en een ander zwaar programma op de achtergrond, dat dat zware programma geen invloed heeft op het afspelen van het filmpje. Maar als je 1080p movieplayer niet is geoptimaliseerd voor multicores of gpu-acceleration en dus maximaal één core of thread gebruikt dan zal het alsnog stotteren.

[freaq]

het punt waar het echt interessant wordt is al men het dus voor elkaar krijgt die "ene" video te parralelliseren, split de video in 4, en "stitch" die aan elkaar, en je hebt een high res zeg 4k beeld bijvoorbeeld, en dat parralelliseren kan in dit geval mogelijk nog verder gaan.

16 threads voor het beeld , 1 thread per luidpsreker, en 3D dus weer 16 threads,
dit klinkt nog volkomen belachelijk en voor dit purpose is het ook nog helemaal niet nodig, maar het punt dat mensen 1 applicatie als 1 taak zien is een groot probleem.

ok er zijn ook vele taken die echt niet opgeslitst kunnen worden,
maar dat geldt lang niet altijd, en als mensen eenmaal aan het dee wenne hoop ik dat dit echt snel zal gaan.

[sdk1985]

Je voorbeeld is niet echt handig gekozen. Juist indien de zware applicatie multithreaded is en de movieplayer niet dan zal de zware applicatie de movie player in de weg zitten. Zijn ze beiden single threaded dan zullen ze beide aan een andere core worden toegewezen en zal de film dus niet haperen (mits 1 core genoeg rekenkracht levert natuurlijk).

Ik merk in de praktijk nu al af en toe problemen met een traag (dualcore) systeem door programma's die echt multithreaden. Zo veroorzaakt left 4 dead 2 bij mijn systeem input lag omdat de muis en keyboard drivers niet meer aan bod komen, terwijl dit programma op 1 core gewoon 60 fps draait.

[Reactie gewijzigd door sdk1985 op 23 juli 2024 05:29]

[SG]

Elk software toepassing is een mix van niet tot goed parraleliseerbaar sub probleempjes.
Het gaat om de verhoudingen. En daar kunnen vlinke ratio verschillen in zijn.

Is de toepassing performance afhankelijk.
Als notepad code toch grotendeels parraleliseerbaar is. HEt is dan toch niet relevant als de computing requierment gewoon erg laag zijn.
Maar is die hoog. Zware apps moeten dus optimaal gesplits worden in slecht parraleliseerbaar probleem wat naar de betere serieele PU geleid moet worden. Dat is dus de CPU. En beter geschikd voor parralel aanpak geleid naar massive core PU. De GPU dus. Zware taken met een groot aandeel dat goed fijnmazig gesplit kan worden met grote onafhankelijkheid. Is hier dan goed geschikd voor.

GPGPU draai rondjes om een CPU met parralel software problemen. Maar seriele is dit juist anders om.

Dus die GPU vervangt de CPU niet.
Men moet dus software routines verdelen naar de uniet die daar het beste voor geschikd is.

PRobleem is dus dat er software apps zijn met software probleem dat gewoon grotendeels vooral serieel is.
Tja dan heb je niks aan CPU die naar multi cores gaan als meer computing power door meer cores geleverd moet worden.

Niet elke zware taak schaald zo extreem goed op GPGPU gebied. De minder goeie blijven bij CPU. En de reken kracht per core schaald met elke nieuwe gen niet meer zo snel op.

Probleem dus.

[stijn1309]

Een leuk filmpje die heel simpel en kort door de bocht het verschil uitlegt tussen een CPU en een GPU. Ik fenk benkend bij de menig tweakers hier.
http://www.youtube.com/watch?v=XtGf0HaW7x4

[Anoniem: 77640]

Die vergelijking is ronduit fout en een schande voor Mythbusters die de feiten niet nagegaan zijn. Een moderne CPU kan 32 bewerkingen per klokcyclus, en is ook nog eens hoger geklokt. De rekenkracht loopt dus niet niet zo enorm veel achter. De GPU heeft echter wel specifieke logica voor textuurbemonstering en zo, en daar zit hem het verschil.

Met SwiftShader verslaat een moderne CPU reeds IGPs en low-end GPUs, en met AVX, FMA en gather/scatter wordt de kloof nog veel kleiner...

[Madrox]

Het is ook geen wetenschappelijke test, maar het geeft wel duidelijk een indruk. Ook niet meer dan dat, want ze laten bijv. niet zien wat een GPU allemaal niet kan, wat een CPU wel moeiteloos uitvoert. De CPU kan in principe alles, de GPU is een sterk beperkte "processor". Toegespitst op eigenlijk slechts enkele taken, allemaal pixel gerelateerd. Logisch dat de GPU daar erg sterk in is, daar is die ook voor ontworpen.

Het benutten van de GPU voor meer taken, is iets van de laatste tijd en staat nog in de kinderschoenen. Maar dan nog gaat de GPU in de huidige vorm, nooit alle taken uitvoeren die een CPU doet; simpelweg omdat de GPU dat niet kan. Als dat trouwens wel zou gebeuren heb je volgens mij een omgekeerde transformatie en is de GPU verandert in een CPU met geweldige GPU performance. Zo'n vaart zal het wel niet lopen.

[Anoniem: 77640]

Het is ook geen wetenschappelijke test, maar het geeft wel duidelijk een indruk.

Tuurlijk is het het geen wetenschappelijke test en het is een leuke opstelling, maar de indruk die het geeft is gewoon fout. Mythbusters is duidelijk vette poen betaald om de GPU extreem superieur te doen lijken. Een ietsje betere vergelijking was om de Mona Lisa lijntje per lijntje te doen verschijnen bijvoorbeeld.

Als dat trouwens wel zou gebeuren heb je volgens mij een omgekeerde transformatie en is de GPU verandert in een CPU met geweldige GPU performance. Zo'n vaart zal het wel niet lopen.

De CPU leunt reeds dichter aan bij de GPU dan omgekeerd (ookal lijkt dat een tegenspraak). De CPU hoeft immers louter het aantal cores te verdubbelen, de vectorlengte te verdubbelen, en FMA en gather/scatter ondersteuning te krijgen om even goed te presteren als een doorsnee GPU. En die zaken staan allemaal reeds op de roadmap. De GPU daarentegen moet radicaal z'n architectuur omgooien om overweg te kunnen met complexere, divergente code en niet-coherente geheugentoegangen. Om dat te verwezenlijken moeten veel transistors anders ingezet worden en gaan dus de ruwe prestaties omlaag.

Ze convergeren dus naar elkaar toe maar de GPU zal aan het kortste eind trekken want de CPU is steeds nodig. Een dubbel zo krachtige CPU is dan interessanter dan een CPU plus GPU.

[Reactie gewijzigd door Anoniem: 77640 op 23 juli 2024 05:29]

[BadRespawn]

Een dubbel zo krachtige CPU is dan interessanter dan een CPU plus GPU.

Lang niet voor alle toepassingen, bvb niet voor 'klassieke' grafische taken zoals 3D games. Anders zou een vier-core CPU voor games beter presteren dan een duo-core plus GPU, en dan zou er geen markt zijn voor grafische kaarten.

In specifieke gevallen kan de prestatiewinst van een GPU veel meer zijn dan het dubbele van een CPU.

[Anoniem: 77640]

Lang niet voor alle toepassingen, bvb niet voor 'klassieke' grafische taken zoals 3D games.

Je hebt het niet begrepen. De CPU is goed op weg om net zo parallel te worden als de GPU, terwijl de GPU net zo generiek programmeerbaar wordt als de CPU maar daarbij rekendichtheid inboet. Met andere woorden over tien jaar zijn ze zodanig gelijkaardig dat de GPU geen specifieke voordelen heeft voor "klassieke" grafische taken. Ook 3D games maken meer en meer gebruik van complexe berekeningen waarvoor een architectuur die aanleunt bij die van een CPU beter geschikt is.

Anders zou een vier-core CPU voor games beter presteren dan een duo-core plus GPU, en dan zou er geen markt zijn voor grafische kaarten.

Ik had het over de toekomst, niet over vandaag. AVX en FMA staan de komende jaren reeds op de planning, en daarna volgt gather/scatter. Iedere 2-3 jaar verdubbelt ook het aantal cores en verbetert hun efficiëntie. In afzienbare tijd wordt de CPU dus heel erg krachtig.

De GPU heeft niet zo'n rooskleurig vooruitzicht. Door kleinere halfgeleiderprocessen kan men wel nog het aantal cores verhogen, maar omdat er nood is aan betere programmeerbaarheid en snellere geheugentoegangen zullen veel van de transistors gespendeerd worden aan nieuwe mogelijkheden en grotere caches, en minder aan het verhogen van de ruwe rekenkracht.

Maar ook vandaag reeds kan je zien dat de markt voor GPUs onder druk komt te staan. Met SwiftShader kan een quad-core CPU de meeste IGPs en sommige low-end GPUs verslaan. En dat zonder gather/scatter instructies! In de nabije toekomst zullen IGPs volledig verdwijnen en neemt de CPU hun taak over. En langzaam aan zal de CPU ook de markt voor krachtiger GPUs wegsnoepen.

Daarom dat NVIDIA zo wanhopig is om een x86 licentie te bemachtigen. Het is de enige manier om op lange termijn te overleven: De CPU geschikt maken als grafische processor.

Vergelijk het met de markt voor geluiskaarten. Sinds de toevoeging van MMX heeft 99% van alle systemen een audio codec die op de CPU draait. Discrete geluidskaarten zijn nagenoeg uitgestorven. Dat lot staat de GPU binnen een jaar of tien ook te wachten. CPUs zijn dan zodanig krachtig dat ze alles aankunnen wat een doorsnee gebruiker van hun systeem verwacht, complexe grafische taken inbegrepen.

[SG]

Ja en daarmee krijg CPU dezelfde GPU probleem dat niet alles te parralelliseren valt.
en voordeel van CPU is dat elke core complex is en heel stuk krachtiger dan zo'n compact klein beperkte GPU coretje.

Alleen.
de laaste top Single core CPU vs veel primitievere 100 shader core
en huidige Six HT core vs 512(nV) 1600(AMD) current gen "shader" core.

D'r is zoiets als grote verschil in aantal core verhouding tussen CPU en GPU.

Ik zie eerder dat CPU de GPU achilles hiel van ondeelbaar software probleem meekrijgd.
Waar GPU lekker doorschaald waar het voornamelijk voor gerbuikt wordt massive parrallelisatie. Gaat CPU ook die kant op.

En dat houd in dat zware serriele applicaties nu slechter mee schalen op CPU.
En CPU only parralel taken wel meegroeien kwa next gen reken kracht maar GPU uiteraard ook lekker verder opschaald. En dat die applicaties door betere toegankelijke tools en nieuwe en geupdate progameer talen ook overgaan naar GPGPU.


Ik heb een zware antipathie gekregen tegen iNtel en wel dit.

iNtel ziet GPPGU wel als dreiging. En iig op korte termijn voordat LRB uit zou komen. En gezien het modder gekletter tussen nV en iNtel. Had intel met LRB fiasco zelfs op middel lange termijn verloren. Maar komen nu zelf met GPU on CPU.

Voor korte tijd hun counter tactic. Hebben ze even Havok FX omzeep geholpen door Havok_FX over te nemen. En als reactie daarop heefd nV Ageia PhysX overgenomen.

En de hele HArdware accelerated Physics gestalled. Dus voel me als gamer toch wel genaaid door iNtel.

Het is zwaar klote dat nr 1 en 2 middleware voor physics in handen is van PU rivalen.
Met een derde speler buiten spel en dat is AMD.

Met andere worden naast DirecX 11 en HavokFX had de PC game platform een flinke effect physics puls kunnen hebben. De optie om ook zwaardere gameplay physics te doen is ook voor breeder publiek beschik baar. En aantrekkelijker voor dev's. De GPU eisen zouden dan iets wat hoger zijn.

Dus misschien kan je iNTel zelf weiten dat nV intel CPU producten boycot kwa support met slechte support of op de handrem laat lopen. iNTel is op GPU en dus PhysX gebied nV grootste concurrent en dus genaai visa versa.

Dus strijd nV vs iNtel is 1 - 1.

We hadden nu wat HAvok FX triple A games kunnen hebben.

Alan Wake in een heel andere form.

[Reactie gewijzigd door SG op 23 juli 2024 05:29]

[Madrox]

Hee, natuurlijk is het zwaar overtrokken; die demo is gesponsord door....Nvidia. Dat mag duidelijk zijn

Verder zeg ik al dat de test beperkt is, ten voordele van de GPU. Misschien niet duidelijk genoeg voor je.

[Reactie gewijzigd door Madrox op 23 juli 2024 05:29]

[Anoniem: 77640]

Het is blijkbaar niet voor iedereen duidelijk, want dit soort filmpjes en andere misinformatie zorgt er voor dat sommigen werkelijk gaan geloven dat de GPU 1000 keer sneller is. Ik wed dat er al menige miljoenen dollars en euro's verloren zijn gegaan naar onderzoek en bedrijfjes die trachten een GPGPU-applicatie te ontwikkelen maar veel te laat ontdekken dat ze er niet in slagen hogere effectieve prestaties te behalen als geoptimaliseerde software voor de CPU.

Wat vele ontwikkelaars ook niet blijken te beseffen is dat de gemiddelde GPU voor mensen die niet dagelijks gamen, heel erg zwak is. De gemiddelde CPU daarentegen is niet zo heel erg veel trager dan de snelste CPU. Dus zelfs als men erin slaagt een applicatie te ontwikkelen die merkbaar sneller is op een GTX 580 dan op een doorsnee CPU, dan is die op een doorsnee GPU niet vooruit te branden.

Ik wil dus gewoon waarschuwen je niet beet te laten nemen door de hype/mythe. Erg jammer dat Mythbusters zich heeft laten omkopen.

[houseparty]

Vergeet het artikel niet DirectCompute aan te halen?

Dat is, althans op het Windows platform, wel een tegenhanger van Cuda en OpenCL lijkt me.

@Hieronder:

Ik snap dat DirectCompute OS-afhankelijk is, maar het is in tegenstelling tot CUDA weer wel hardware onafhankelijk. Aangezien ook veel productie-machines (etc) op Windows draaien, en aangezien het artikel ook huis-tuin-en-keuken gebruik aanhaalt, waar Windows nog steeds gemeen goed is, hoort DirectCompute ook gewoon aangehaald te worden. Vooral ook omdat op pagina 2 sowieso al wat Windows functionaliteit wordt aangehaald. In die zin past DirectCompute gewoon in het rijtje met CUDA en OpenGL, met vermelding van het nadeel aan Win7/WinVis gebonden te zijn.

[Reactie gewijzigd door houseparty op 23 juli 2024 05:29]

[Visitor.q]

Het voordeel van CUDA is dat het platform onafhankelijk is (er zijn ook linux drivers en volgens mij ok voor apple). Het voordeel van OpenCL is hetzelfde, en bovendien werkt het ook nog eens op andere kaarten dan die van NVidia. Dus: we hebben eindelijk een de-facto standaard (CUDA), en bovendien daarnaast nog een open standaard (OpenCL). Waarom zou je dan een alternatief gaan gebruiken en daarmee meteen de interoperabiliteit van je software om zeep helpen?

[mjtdevries]

Leuk dat CUDA OS onafhankelijk is, maar het is niet hardware onafhankelijk.
OpenCL is dat ook niet, directcompute wel.

Daarom is het voor ontwikeklaars (zeker voor thuisgebruik) veel aantrekkelijker. Het is daarom dan ook zeker een gemis dat het niet besproken word.

[Anoniem: 155467]

DirectCompute is juist wel OS afhankelijk. Het is Microsoft DirectCompute en werkt alleen op Vista en Win7. OpenCL is daarentegen OS en hardware onafhankelijk.

[mjtdevries]

Even een quote uit het artikel:

OpenCL-software is overigens ook niet portable over verschillende hardware-platformen, omdat de code nog steeds topologie-specifieke zaken bevat.

Je krijgt hetzelfde probleem als bij OpenGL.
Je moet nog steeds je OpenCL code schrijven voor een bepaald stuk hardware. Dat is nog steeds iets wat je niet wilt, dan heb je immers hetzelfde probleem als CUDA.


Voor thuisgebruik is afhankelijkheid van het OS veel minder belangrijk dan afhankelijkheid van de videokaart.

[johnkeates]

Thuis ga je toch echt niet professioneel werken met el cheapo mainstream crap. Dat is leuk voor gamers, mensen zonder werk of andere types die buiten de enterprise/science computing groep vallen.

Windows is leuk voor gamers, en mensen die wel een 'tweaker' willen zijn, maar niet echt willen tweaken. Het een OS waar een groot bedrijf je vertelt wat te doen, waar de enige aanpassingen gewoon ronduit dirty hacks zijn, en waarmee je vooral heel goed general purpose taken mee kan bedrijven. Dat is niet slecht, maar het heeft gewoon niks met de onwikkelaars/CUDA/OpenCL wereld te maken. Als je bijvoorbeeld een cluster met OpenCL-capable kaartjes gaat opzetten, zul je waarschijnlijk toch echt een microkernel nemen of bouwen, die strippen zodat je echt alleen datgene hebt wat je nodig hebt, en die netwerken zodat je via control nodes gewoon je taken kan laten uitvoeren die je vanuit je distributie node stuurt. Windows heeft ondersteuning voor general purpose hardware, meestal werkt het alleen correct op x86 hardware met een oude BIOS, (en ja x64 kan ook prima werken, maar ze zijn pas net een paar jaar goed op weg) en als je EFI gebruikt is d'r een prima kans dat het niet draait zonder BIOS emulatie. Naast het feit dat x86 architectuur (incl. x64/64-bit extensions) gewoon ondergeschikt is aan bijv. PowerPC (en dus ook Cell) of Itanium architecturen voor supercomputing taken, en het probleem dat OpenCL/CUDA & Co vooral voor supercomputing zinvol is, heb je altijd nog het probleem dat je gewoon niks aan de NT kernel kan veranderen...

[houseparty]

Niet om Windows te gaan lopen verdedigen, maar je moet geen FUD verkopen:

Windows heeft ondersteuning voor general purpose hardware, meestal werkt het alleen correct op x86 hardware met een oude BIOS, (en ja x64 kan ook prima werken, maar ze zijn pas net een paar jaar goed op weg) en als je EFI gebruikt is d'r een prima kans dat het niet draait zonder BIOS emulatie.

Ik neem aan dat waar je x64 zegt je eigenlijk x86-64 bedoelt? Want dat is namelijk ook hoogstwaarschijnlijk waar je je *nix microkernel voor zult compileren als je Cuda/OpenCL wilt gebruiken.

Microsoft is net zo lang op x86-64 gebied actief als alle anderen, en het functioneert niets minder dan bij de anderen. Wellicht niet wat in vergelijking met bepaalde specifieke OS-en/Kernels, maar de markt is veel breder dan die niche. Wat echte x64 processor architecturen zoals IA64 betreft: dat is leuk, maar daar heeft het artikel niet zo zeer betrekking op.

En Windows heeft tegenwoordig prima EFI support zonder dat BIOS emulatie nodig is..

Naast het feit dat x86 architectuur (incl. x64/64-bit extensions) gewoon ondergeschikt is aan bijv. PowerPC (en dus ook Cell) of Itanium architecturen voor supercomputing taken, en het probleem dat OpenCL/CUDA & Co vooral voor supercomputing zinvol is, heb je altijd nog het probleem dat je gewoon niks aan de NT kernel kan veranderen.

CUDA wordt afaik sowieso enkel gebruikt op x86-64 systemen, en OpenCL voornamelijk op x86-64 systemen. (Ook aangezien PowerPC clusters door de meer capabele architectuur sowieso minder nuttig effect van GPGPU ondervinden, de noodzaak is er minder.)

Het artikel gaat niet enkel en alleen over supercomputing. Er zijn wel degelijk óók toepassingen waarbij GPGPU voor minder grootschalige doeleinden zéér nuttig is.

En zaken zoals OpenCL, CUDA, DirectCompute zijn jijst ook bedoeld om met die "el cheapo mainstream crap" zware GPGPU taken uit te kunnen voeren.

[Reactie gewijzigd door houseparty op 23 juli 2024 05:29]

[johnkeates]

Ik bedoel inderdaad de intel x86 architectuur met x64 extensies, hoewel ik de naam AMD64 of Intel64 aantrekkelijker vind, samen met de universele 'alles wat x64 kan' beduiding: x64.

Het is natuurlijk zo dat de huidige kaartjes afhankelijk zijn van ouderwetse BIOS implementaties, en die hebben dan alleen maar x86 instructie ondersteuning, waardoor je er ook alleen x86(-64) CPU's mee kan combineren, maar dat zegt niet dat dat zo blijft, of dat het ideaal is. Stel je voor, een compute node met een Cell CPU en een aantal Tesla's van Nvidia met elk 448 cores, neem er dan meteen 100 per Cell (dus heb je 44800 cores / 100 GPU's als GPGPU) met een CPU (Cell) die ook nog eens de data bliksemsnel kan verwerken (in & out) en interconnects dirigeert. Dat soort scenario's kan je met de huidige, en tussen nu en 5 jaar bestaande x86(-64) architectuur niet bereiken, maar als je PPC (Cell) & OpenCL (als Tesla daar fatsoenlijk aan deed) combineert zou je een vrij krachtige supercomputer kunnen bouwen met slechts het formaat van een compleet 19" cabinet.

Dat windows op x86_64 werkt klopt ook wel, maar ze waren pas sinds windows xp op weg om een echt bruikbaar systeem te maken. Maar rond 2001 was linux al volledig x84_64 en Intel64/AMD64 te draaien, inclusief userland, terwijl eind 2001 Windows XP voor Itanium pas uitgebracht werd, maar de enig echt bruikbare Windows XP voor x86_64 pas rond 2007 fatsoenlijk inzetbaar was (na de SP2 release). Maar genoeg over windows, dat heeft er vrij weinig mee te maken. Windows is gewoon general purpose en zal daarom ook altijd een 'general' score behalen, om dat het voor geen enkele taak beter is dan een andere.

Om nog even kort op PPC + OpenCL in te gaan, PPC computers en supercomputers profiteren nog steeds van OpenCL en bijv. Tesla achtige situaties, om dat voor echt grote matrices een paar honderd cores van een nvidia GPGPU gewoon sneller zijn door dat ze meer tegelijk kunnen verwerken. Een single core PPC zal natuurlijk altijd sneller zijn dan een single GPGPU core uit een GPU, maar zelfs een Cell heeft niet hetzelfde aan boord voor de parallele verwerking die je met een GPU kan doen. Wat de PPC dan als voordeel heeft, is dat het de data een stuk beter kan 'beheren' of hoe je het noemt, je gebruikt de GPGPU dan voor het grote grove werk, en verwerkt de data met de Cell zodat je het naar een control node kan zenden die het naar je management node stuurt als alles van een bepaalde taak, of van een onderdeel van een taak binnen is. Voor de grote ladingen data die je met ruwweg een paar duizend GPU cores kan verwerken heb je ook een CPU nodig die de data heen en weer kan pompen. Hmm.. dat was niet echt 'kort', maar je begrijpt m'n punt wel; OpenCL/CUDA enz is een zeer relevant stukje technologie, maar je kan het haast met een ASIC vergelijken, supersnel in wat het moet doen, maar het komt op de 'aanstuuring' aan of je er ook echt uit kan halen wat er in zit. Twee i7's zijn vrij snel, maar je kan er niet hetzelfde mee verwerken aan data als je het naast een tweetal Cell's zet. Helaas kunnen we daar op het moment alleen nog over dromen, want Nvidia & AMD maken voor non-embedded technologieen vooral BIOS-only hardware. Dat is stilstand, en stilstand is zoals bekend achteruitgang. Als iets stil staat, en de rest gaat door... je begrijpt het wel

[houseparty]

De eerste x86-64 CPU was een Opteron die in april 2003 werd uitgebracht.
Dat er voor die tijd al OS-en waren die volledig in staat waren x86-64 te draaien lijkt me zeer sterk, en ook nog eens totaal niet ter zake doend aangezien de CPU's op zich lieten wachten.

Bovendien ga je weer op de supercomputing toer. Wat je zegt is weliswaar grotendeels waar, maar dat is niet geheel de scope van het artikel. Het artikel heeft óók en betrekking op kleinschaligere toepassingen.

[.oisyn]

Ik neem aan dat waar je x64 zegt je eigenlijk x86-64 bedoelt?

En

Wat echte x64 processor architecturen zoals IA64 betreft: dat is leuk, maar daar heeft het artikel niet zo zeer betrekking op.

Euh, x64 *is* x86-64. Het staat niet voor een generieke 64-bits architectuur, maar de 64 bits architectuur van de x86. IA64 heeft dan ook geen drol met x64 te maken .

Staat trouwens ook gewoon op die wikipedia pagina die je aanhaalt:

x86-64 is still used by many in the industry as a vendor-neutral term, while others, notably Sun Microsystems (now Oracle Corporation) and Microsoft, use x64.

[Reactie gewijzigd door .oisyn op 23 juli 2024 05:29]

[Anoniem: 28958]

Ik kan me niet voorstellen dat je de OpenCL standaard ook maar in zijn basis begrijpt. Je kunt wel iets quoten, maar ik denk eigenlijk dat de auteur van Tweakers.net ook geen idee heeft waar hij ook spreekt.

Alle hardware abstractie lagen (de MS variant, CUDA en OpenCL) doen alles in bijna precies dezelfde manier, omdat ze willen abstraheren over moderne GPU hardware. Er zitten wat verschillen in de constantes van het platform (hoe lang een vector mag zijn, etc.), maar verder is het allemaal om het even.

Dat iets portable is betekent dat het draait, het zegt niets over de snelheid. Als jij bijv. een datatype gebruikt dat niet direct in de hardware is uitgevoerd dan mis je dus al een hele hoop performance, maar dit is de prijs die betaalt voor het gebruiken van een abstractie laag.

Heel simpel voorbeeld, als jij een vector met 4 componenten specificeert in OpenCL en je wilt deze dan op een videokaart draaien die alleen maar vectors met 3 componenten ondersteund, dan moet de driver het dus eigenlijk emuleren wat natuurlijk langzamer is.

Ik ken overigens stukjes geoptimaliseerde OpenCL code door een ontwikkelaar met een Ati kaart dat een paar honderd keer sneller dan zijn CPU draait, maar diezelfde code draait met nvidia hardware (lagere prijsklasse) langzamer dan twee CPUs.

Dit soort problemen horen vooral bij een nieuwe techniek. Na verloop van tijd ontstaan er benchmarks en dan zullen AMD en nVidia een beetje hetzelfde performance plaatje willen kunnen geven, omdat ze anders hun hardware niet meer kwijt kunnen.

[Anoniem: 173243]

OpenCL draait anders op Nvidia, ATI, Intel, AMD en Cell processors, dus wat nou niet hardware onafhankelijk?