Intel geeft alpha OpenCL voor Core-cpu's vrij

Chipfabrikant Intel heeft een vroege versie van ontwikkelsoftware vrijgegeven die de ondersteuning van specifieke instructiesets van Core-processors aan OpenCL-applicaties toevoegt. De software draait op Windows 7 en Vista.

Anders dan de generieke versie van de OpenCL-programmeertaal is Intels versie geoptimaliseerd om op diens Core-processors te draaien en te profiteren van de meerdere rekenkernen en simd-instructieset waarover de Core-familie beschikt. De sdk die Intel beschikbaar heeft gesteld is een alpha-versie en het bedrijf geeft dan ook geen garanties over werking of ondersteuning. Wel is de software kostenloos te downloaden en te gebruiken als technology preview.

Met OpenCL, of Open Computing Language, kunnen zogeheten gpgpu-applicaties geschreven worden, maar de uitvoering van de code is niet beperkt tot de gpu. OpenCL werd aanvankelijk door Apple ontwikkeld, maar inmiddels hebben fabrikanten, waaronder naast Intel ook AMD, Nvidia en IBM, zich achter de open standaard geschaard. De bedrijven hebben zich verenigd in de Khronos Group. Intel zou met de publicatie van de sdk aan een inhaalslag begonnen zijn: AMD biedt al langer ondersteuning voor OpenCL.

Reacties (45)

[vinx77]

Als de eigenaar van het OpenCL-bedrijf StreamComputing, bij sommigen van jullie misschien bekend, voel ik me geroepen even wat uit te leggen.

Probeer hier niet de CPU rechtstreeks met de GPU te vergelijken. Het gaat hier om een alternatieve aansturing van SSE en vooral de AVX van de Sandy Bridge, zodat C-achtige code (OpenCL) sneller draait dan als het alleen gebruik maakte van de standaard CPU-instructies. AVX staat voor Advanced Vector Extension en Intel heeft voor OpenCL gekozen voor aansturing van deze extensie voor parallelle berekeningen. Zie http://software.intel.com/en-us/avx/ voor meer informatie. Tevens zal de Sandy Bridge een snelle videokaart huisvesten, die waarschijnlijk ook met OpenCL aangestuurd kan worden. Verwacht dus niet echt veel versnelling door OpenCL met je I5 of I7, maar straks in januari wel heel erg veel van je Sandy Bridge.

Het echt grote nieuws is dat data niet meer via de PCIe-bus getransporteerd hoeft te worden, maar de parallelle instructieset geheugen deelt met de CPU. Momenteel is de grote beperkende factor van de techniek juist deze transfer-tijd tussen CPU-geheugen en GPU-geheugen. Straks komen ook nog de zeer vergelijkbare AMD Fusion processoren, en nog later volgend jaar IBM's nieuwe Power-processoren met parallelle instructiesets (geruchten). NVIDIA heeft (nog) geen hybride architecturen aangekondigd, maar er wordt flink gespeculeerd dat NVIDIA naast een ARM-processor ook een X86-processor gaat ontwikkelen.

Wil je meer lezen, kijk dan even op dit artikel op mijn bedrijfsblog.

[stewie]

je kan met OpenCL eenvoudig code delen tussen de CPU en de GPU, dit was in het verleden gewoon simpelweg onmogenlijk (vooral cross-platform)

je kan dingen doen op de CPU die je niet met een GPU en visa-versa, er zijn gewoon dingen die ze beiden gewoon echt totaal niet goed kunnen (het vult elkaar aan, en het sluit niet uit)

[Verwijderd]

De CPU kan alles wat een GPU kan, andersom niet.

[stewie]

jij hebt het over shading, er zijn echt dingen bij die jaren zouden duren op een CPU en een GPU kan dat in een paar minuten.

zoals folding bijvoorbeeld waar de GPU dingen kan unfolden die gewoon 100% onmogelijk zijn op cpu's.

[Reactie gewijzigd door stewie op 24 juli 2024 05:32]

[Dreamvoid]

maar er wordt flink gespeculeerd dat NVIDIA naast een ARM-processor ook een X86-processor gaat ontwikkelen.

Ik geef het ze te doen, x86 is een kerkhof voor hoopvolle nieuwkomers, en niet de minsten: IBM, VIA (zo goed als), Cyrix, Transmeta en (bijna) AMD. Zeker nu ARM de grote groeimarkt is (tablets/smartphones).

[jeffhuys]

Ik begrijp nog steeds niet helemaal hoe het nou komt dat "programma's" (brute force e.d.) no snel draait op een GPU!

On-topic:
Zeer mooi dat dit dus nu ook op CPU kan.

[DarkJack]

omdat een GPU doorgaans honderden lightweight threads naast elkaar kan draaien, terwijl een quadcore bijv max 4 kan draaien. Een gpu heeft een zeer beperkte instructieset tov een CPU, en is niet gemaakt om zware berekeningen in 1 thread te doen. Kan je de workload echter zeer granulair opdelen in zeer lichte en korte bewerkingen, maar die wel honderdduizendden keer moeten uitgevoerd worden, dan kan je dmv de enorme parralellisatie die een GPU ondersteunt enorme snelheidswinsten tov een CPU maken.

[SG]

Juist maar dat maakt GPGPU geschikt voor specifieke problemen en de CPU wordt dus niet massaal vervangen door GPGPU. Aangezien er nog heel veel software is dat lastig of moeilijk of helemaal niet te parraleliseren valt.
In Cuda boeken raad men ook aan dat seriele software problemen en dus die routines beter op de CPU gedaan worden aangezien dat Cuda performance bevorderend werkt.

Want de meeste zwaar parraleliserende taken zijn niet puur parrallel dus CPU en GPGPU kan goed samen benut worden.

[Wolfos]

OpenCL is wel geschikt voor mass-physics, zoals bij astrophysics enzo.
Apple heeft een demo uitgebracht die honderd duizenden sterren realtime berekent en op een GeForce 9400M loopt dat op zo'n 20FPS met OpenCL, op de CPU ongeveer 1FPS geloof ik.
Helaas kan ik me de getallen niet meer helemaal herinneren.

[johnbetonschaar]

Het is precies hetzelfde concept als waardoor een DSP processortje op nog geen 400 Mhz vloeiend twee 1080p streams tegelijk kan decoden, terwijl zelfs een moderne single of dual-core CPU het daar al knap lastig mee heeft: de architectuur is volledig geoptimaliseerd op 1 taak, en dat is enorme hoeveelheden floating-point operaties in parallel uit te voeren. Al die pixels op het scherm die jij ziet als je een 3D spel op 1920x1080 op 60 fps speelt rekenen zich natuurlijk ook niet zelf uit ;-)

Een standaard desktop CPU is een all-rounder en zit vol met waanzinnig complexe logica om een zo hoog mogelijke performance op zo veel mogelijk verschillende taken te halen. Dat heeft als voordeel dat je een desktop CPU overal voor kunt gebruiken, maar als nadeel dat ie nergens eigenlijk 'het beste' in is. Voor rekentaken die je in streams kunt definieren die parallel verwerkt kunnen worden is een GPU de koning, terwijl taken met veel control-flow en I/O waarschijnlijk duizenden malen trager lopen op een GPU dan een CPU, als je ze (met enorm veel omwegen en trucs) al op een GPU uitgevoerd zou krijgen.

[vinx77]

En Intel komt nu dus met OpenCL-aangestuurde AVX om hun Sandy Bridge CPU betere ondersteuning voor die streams te geven. Code dat ontwikkeld is voor een GPU kan met enkele tweaks nu even snel of misschien wel sneller draaien op Sandy Bridge (of als het CUDA is, met Swan te transformeren naar OpenCL).

[ObAt]

"Benchmarks that focus on floating point arithmetic, those most often used in these engineering computations, show that GPUs can perform such computations much faster than the traditional central processing units (CPUs) used in today’s workstations—sometimes as much as 20 times faster, depending on the computation."

Bron: LinuxToday

Intel zegt: “GPUs Are Only Up To 14 Times Faster than CPUs”

D.E. heeft dit te zeggen: "Benchmarks that focus on floating point arithmetic, those most often used in these engineering computations, show that GPUs can perform such computations much faster than the traditional central processing units (CPUs) used in today’s workstations—sometimes as much as 20 times faster, depending on the computation."

Ohja, deze link zorgt dat veel first posts worden vermeden.

[Reactie gewijzigd door ObAt op 24 juli 2024 05:32]

[Iska]

Klopt, maar is wel maar de helft van het verhaal. Laten we bijvoorbeeld voor de Intel Core i7 X 980 @ 4515MHz zo'n 25 GFlops nemen. Voor de Radeon HD 5870 (niet overclocked) is dit zo'n 600 GFlops (double-precision). Dat betekend dat het verschil zo'n 24 keer is.
MAAAAR; Prijs Core i7 X 980 - 850,-; Prijs HD 5870 - 300,-
Prijs/FLOP is dus zo'n 75 keer hoger bij GPU. En dit kan oplopen tot 100 keer als je de GPU ook overclocked... Trek uw conclusie

[Reactie gewijzigd door Iska op 24 juli 2024 05:32]

[Verwijderd]

Je vergelijking slaat nergens op. Ten eerste vergelijk je praktijkresultaten van de CPU met theoretische prestaties van de GPU.

Een 4515 MHz Core i7 kan 108,36 DP GFLOPS, sustained. Of de software dat eruit haalt is weinig relevant, een Radeon 5870 ga je in praktijk ook nóóit z'n 544 GFLOPS kunnen doen behalen.

Qua hardware een factor 5 verschil met een Radeon 5870 dus. De binnen enkele maanden verkrijgbare Sandy Bridge processors voegen de AVX instructieset toe, waarmee de vectoren twee keer zo breed worden. Het verschil in rekenkracht daalt dus naar een factor 2,5.

Vervolgens moet je ook kijken naar het aantal transistors om de hardware eerlijk te vergelijken. De six-core i7 beslaat 1,17 miljard transistors, de Radeon zo'n 2,15 miljard. Dat brengt ons tot een factor 1,36. Lang niet zo indrukwekkend meer he, die rekenkracht van een GPU?

En ja een Core i7 980 (of twee) is erg duur, maar bemerk dat bijvoorbeeld een Core 2 Quad vele malen goedkoper is terwijl de DP prestaties per core gelijk zijn. Vervolgens is een consumer GPU helemaal niet geschikt voor wetenschappelijke berekeningen. Daarvoor heb je er een met ECC geheugen nodig zoals de Tesla van NVIDIA. En laat die nu net duizenden euro's kosten. Het is dus zeker geen factor 75 verschil voor FLOPS/prijs tussen CPU en GPU.

En last but not least, de CPU is nog steeds tot veel meer in staat dan de GPU. Je kan niet zomaar een willekeurig programma op de GPU draaien. Een GPU is ook belachelijk traag als het op single-threaded prestaties aankomt. Door Amdahl's Law komt een heel gamma algoritmes dan ook nooit in aanmerking om efficient op een GPU te draaien.

Er zijn dus zeer goede redenen waarom supercomputers nog gedomineerd worden door CPUs. Af en toe stopt men er nu ook GPUs bij maar die kan men slechts inzetten in zeer beperkte gevallen, en de snelheidswinst is niet eens zo hoog.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 05:32]

[elteck]

De getallen ken ik niet up m'n hoofd. Natuurlijk is een CPU veel algemener dan een GPU. Maar bijna alle simulatie software, en dan praat ik dus over finite element pakketten, of Greense Functie gebaseerde software, moeten grote matrices door rekenen. En daar blijkt de GPU uitermate handig voor, want het zijn vrijwel dezelfde bewerkingen die ze voor de shaders uitvoeren. De kracht van de GPU is inderdaad niet z'n single threaded rekenkracht, maar het fijt dat ze geoptimalizeerd zijn voor massaal parrallel rekenen. Daarbij is niet alleen het aantal parrallele eenheden in de GPU belangrijk, maar ook z'n brede geheugen bus. Bij dit zoor simulaties gebruik je zoveel geheugen, dat bijna geen enkele proc. het in z'n cache krijgt, en dan is juist die grote geheugen bandbreette van de Video proc handig. Voor een kantoor applicatie onbelangrijk, maar voor computer simulaties, ideaal.

Jou bewering dat supercomputers geen gebruik maken van de GPU is onjuist. De snelste super computers van de laatste tijd, zijn allemaal GPU gebazeerd:

De laatste Chinese supercomputer is door Nvidia gebouwd:
http://www.physorg.com/ne...r-world1101s-fastest.html

Hier nog een:
http://www.electronicsnew...r-csiros-gpu-based-superc

En als je de top 4 ziet in dit rijtje, dan is de Jaguar van Cray de enige die niet op de GPU gabazeerd is:
http://www.top500.org/

[Alex_dragon]

De relatief goedkope HD5000 series (namely de 5870/5970) EN GTX400 (je tesla dus) series bevatten ECC geheugen. (google maar, je merkt het vanzelf als je ze overclockt, geen artifacts, maar slowdowns, da's ECC at work)
Ook is het waar dat een GPU meer transistors heeft, maar dat betekent niet dat dat een oneerlijke vergelijking zou zijn, dat is meer gewoon een van de tekortkomingen van de CPU, AVX is een mooie toevoeging, maar net als op de GPU, moet je libraries (OpenCL) gebruiken om het te benutten.
Het is WEL waar dat je een programma 'super multi threaded' moet schrijven als je het efficient op een GPU wil uitvoeren, voor de rest is het echter gewoon een extra CPU in een PC die normaal gesproken vrijwel niet benut word, en daarom is OpenCL zo vet

[sjaakwortel]

prijs/flop is dus veel lager voor de GPU

[SG]

Daarnaast de CPU range gaat van goede naar slechte prijs prestatie verhouding aangezien de prijs prestatie verhouding niet lineair is.

Als je 2de of 3de plaats CPU pakt dan valt die prijs verhouding mee.

Daarnaast heeft nV de Double Float power een heel stuk beperkt voor consumenten GPU.
Wat inhoud dat consumenten GPU concurerend zijn met single presision. Maar voor DF de Tesla lijn moet hebben maar die is rete duur.

Maar voor bepaalde wetenschappelijke taken, die goed te parrallelizeren zijn. VErvang je met een paar Tesla's een hele cluster Opteron servers.

Dus in die gevallen is een quad Tesla kwa prijs performance en watt een heel stuk goedkoper.

Dus dat theoretische verschil is toch wel grotendeels haalbaar en in die gevallen gaat men voor GPGPU.

Want dat is vaak bij custom software toepassing waar men dus zwaar optimaliseerd zodat het meeste uit GPGPU gehaald wordt.

En gebruikt men vooral Cuda in die markten.
En loopt OpenCL nog niet zo lang mee en is meer algemeen. Waarbij Cuda nV gPU specifiek is en die overhead niet heefd.

Dus om nou AMD GPU als voorbeeld te nemen.

[Verwijderd]

Een GPU is niet per definitie sneller dan een CPU. Het is alleen zo dat sommige taken die parallel uit te voeren zijn, beter uitgevoerd kunnen worden op de GPU. Maar ook daar bestaan uitzonderingen op. Sowieso is het maximum uit een GPU halen, vele malen moeilijker dan bij een CPU. Dus ook al bezig een GPU meer raw processing power dan een CPU, die er daadwerkelijk uitkrijgen is een heel ander verhaal.

[TD-er]

Sowieso is het maximum uit een GPU halen, vele malen moeilijker dan bij een CPU. Dus ook al bezig een GPU meer raw processing power dan een CPU, die er daadwerkelijk uitkrijgen is een heel ander verhaal.

Neemt niet weg dat je bij taken die veel rekenkracht vergen, waar je dus veel tijdswinst zou kunnen halen, ook best wel wat tijd mag steken in de ontwikkeling van de software.

* TD-er heeft op het werk ook wel een aantal rekenkundig complexe algoritmen lopen optimaliseren, maar zou die toch wel wat sneller willen zien.

[OverSoft]

Klopt, op een hoger niveau kom ik die vaak tegen. Kleine webapplicaties die in eens populair zijn geworden bijvoorbeeld. Vaak hebben deze zoveel mogelijk logica in de SQL statements gestopt, terwijl het vaak veel sneller is om een gedeelte te offloaden naar de applicatie zelf.
Loop unrolling kan ook veel snelheid schelen of het onnodig gebruik van objecten ipv simpele integers of strings. (hoewel de compiler hier veel in kan doen!)

[mimic]

Betekend overigens niet dat je deze technieken zomaar van een CPU kan verwachten. Een CPU moet veelal veel meer en moeilijkere taken doen dan een GPU.

Tegenwoordig heb je al wel de geintegreerde GPU in de CPU's. Maar dat zijn fysiek als nog losse GPU en CPU. Wel onder één dak.

[CAPSLOCK2000]

lol, we zijn het kringetje weer eens rond, en deze keer behoorlijk snel.
Men begon met op GPU's te rekenen omdat die voor bepaalde dingen sneller zijn dan CPU's. Nu gaan we weer integreren en die GPU met je CPU samenvoegen. Het taaltje dat dus nu net _niet_ bedoeld was om met CPU's te werken komt alsnog op je CPU terecht.

Het hele integrated-circuit vs dedicated-hardware rondje hebben we al een paar keer gelopen maar volgens mij nog nooit zo snel als nu.

[johnbetonschaar]

Het idee van OpenCL is altijd al geweest dat het ook op CPU's kon draaien, er is bijvoorbeeld ook een Cell CPU versie van die de enorme rekenkracht van de SPE's van die processor gebruikt. Dat is juist het mooie van deze standaard, dat je een zware rekentaak 1x kunt schrijven en dat er op verschillende platforms beter gebruik gemaakt kan worden van de hardware dan wanneer je je code er zelf voor moet optimaliseren. Een niet-hand-optimized stuk CPU code zal dan trager zijn als een met OpenCL geschreven stuk code, of je het nou op een GPU uitvoert of niet.

[mashell]

Logisch toch? Wanneer de losse chipjes (FPU, GPU etc) standaard en onmisbaar geworden zijn moet je ze integreren in de CPU want dan kan je er makkelijker en sneller mee communiceren.

[CAPSLOCK2000]

Zeker logisch, ik klaag ook niet, ik verbaas me alleen over het tempo.

[dmystic]

zo snel is het toch niet? grafische kaarten bestaan al aardig lang hoor

[arjankoole]

zo snel is het toch niet? grafische kaarten bestaan al aardig lang hoor

Dat klopt, maar OpenCL is erg jong. Het werd nog geen 2 jaar geleden voor het eerst gedemonstreerd, en zit ook pas sinds Mac OS X 10.6 (Snow Leopard) in Mac OS.

In dat opzicht is het heel erg snel gegaan met de taal en vooral het brede draagvlak. (zowel nvidia als amd als intel, en dan rekenen we Apple en IBM nog niet eens mee)

[arjankoole]

Nee, ze voegen nu het GPU deel toe aan dezelfde Die als je CPU al op zit. Het taaltje gaat dus draaien op het deel wat prima is, namelijk de GPU sectie van je CPU.

[Xorifelse]

Kijk naar de xbox, deze techniek gebruiken ze al langer. Maar dan nog niet zo uitgebreid.

[DukeBox]

Ik vraag me af of we iets gaan merken aan distributed computing clients.. in /5 zouden we daar erg blij mee zijn

[simplicidad]

Ik moet zeggen na al een lange tijdje met luxrender (en om duidelijker te zijn SmallLuxGPU http://www.luxrender.net/wiki/index.php?title=SLG ) te hebben gespeeld ben ik eigenlijk helemaal verkocht aan het OpenCL gebeuren. Het verschil GPU versus CPU is gewoonweg indrukwekkend... .

Ik zie trouwens dat er wat hardware sites die SmallLuxGPU ook al opnemen in hun benchmarks.

[Neverwinterx]

Het vraagt minimum de SSE 4.1 instructieset dus het werkt (voorlopig toch, mss komt daar nog verandering in?) niet op oudere Core reeksen.

[Maurits van Baerle]

Op zich zijn er hele mooie dingen te doen met OpenCL. Er is bijvoorbeeld een experimentele FLAC encoder met OpenCL ondersteuning die indrukwekkende prestaties begint neer te zetten.

Mooi dat, na AMD en Nvidia, Intel eindelijk ook mee begint te doen.

[Reactie gewijzigd door Maurits van Baerle op 24 juli 2024 05:32]

[Gamebuster]

Wat leuk

Zo kunnen devs dus 1 lapje schrijven dat OpenCL gebruikt, wat ook werkt op computers die geen OpenCL-capable GPU hebben door de CPU te gebruiken (al is dat waarschijnlijk wel wat trager)

[stewie]

intel=software slak.

[Verwijderd]

Inderdaad, AMD heeft al járen OpenCL op z'n CPUs draaien.

[Dreamvoid]

Hmm nu Intel ook OpenCL support heeft is de weg vrij voor Apple om nVidia discrete kaartjes te dumpen voor de low-end Macbooks en de IGP van de i3/i5 Sandy Bridge te gebruiken. Gunstig voor de prijs en accuduur...

[Reactie gewijzigd door Dreamvoid op 24 juli 2024 05:32]

[stewie]

niet dus, want OpenCL heeft niets met graphics te maken.

[Dreamvoid]

De onofficiele reden dat Apple op al hun recente modellen een nVidia gpu gebruikte was dat Intel geen OpenCL deed (niet in de cpu en niet in de igp). Dat gaat dus nu veranderen.

[Countess]

eigenlijk gaat dit om het laten draaien (of eigenlijk kunnen ontwikkelen van) van openCL code die werkt op intel's CPU's, en dus niet op het GPU deel.