MICROSOFT C++ AMP: AZ OPENCL ALTERNATÍVÁJA?

A Microsoft egy újdonsággal rukkolt elő az AMD Fusion Developer Summit alkalmával, amely lehetővé teszi, hogy C++ nyelven írt alkalmazásokkal egyszerűen igénybe vegyék a fejlesztők és a felhasználók a GPU által kínált hatalmas párhuzamos számítási teljesítményt. A C++ AMP (C++ Accelerated Massive Parallelism) névre keresztel újdonság használatához DirectCompute kompatibilis grafikus processzorra van szükség, ha ez adott, akkor a GPU könnyedén befogható általános célú számítási feladatok elvégzésére. Külön jó hír, hogy a Microsoft újdonsága nyílt szabványnak minősül, így a tervek szerint a jövőben nem csak Microsoft platformokon és nem csak a Microsoft által készített fordító alkalmazásokkal lehet majd használni.
Víg Ferenc (J.o.k.e.r)
Víg Ferenc (J.o.k.e.r)
2011. jún. 17. 10:01
Microsoft C++ AMP: az OpenCL alternatívája?

A Microsoft egy újdonsággal rukkolt elő az AMD Fusion Developer Summit alkalmával, amely lehetővé teszi, hogy C++ nyelven írt alkalmazásokkal egyszerűen igénybe vegyék a fejlesztők és a felhasználók a GPU által kínált hatalmas párhuzamos számítási teljesítményt. A C++ AMP (C++ Accelerated Massive Parallelism) névre keresztel újdonság használatához DirectCompute kompatibilis grafikus processzorra van szükség. A Microsoft újdonsága nyílt, így a tervek szerint a jövőben nem csak Microsoft platformokon és nem csak a Microsoft által készített fordító alkalmazásokkal lehet majd használni.

Az újítást a Microsoft egyik szakembere, Herb Sutter mutatta be. A heterogén rendszerekben rejlő lehetőségek egyszerű kiaknázását segítő C++ AMP a C++ programnyelv kiegészítésének, egyfajta bővítménynek tekinthető, amely a DirectCompute technológiát próbálja majd minél hatékonyabban munkára fogni. A lenti prezentációs képkockán a heterogeneitás dzsungele látható - ahogy Mr. Sutter nevezi.

Galéria megnyitása

A következő diagram már azt mutatja, hogy a C++ jelenleg milyen mozgásteret biztosít a fejlesztők számára.

 

Galéria megnyitása

Ez a mozgástér a C++ AMP érkezésével jelentősen kibővül. A Microsoft tervei szerint a C++ AMP következő kiadásai még több specializált processzort támogatnak majd, így a mozgástér idővel még inkább kibővülhet.

A Microsoft illetékeseinek elmondása szerint a Visual Studio következő kiadásában már elérhető lesz a C++ AMP támogatás. Mivel nyílt szabványról van szó, így nem a Visual Studio lesz az egyetlen olyan alkalmazás, amely lehetőséget ad a C++ AMP szabvány alkalmazására. A Microsoft és az AMD együttműködésének köszönhetően már készülnek azok a fordítók, amelyeket a cégek nem Windows-ra, hanem egyéb operációs rendszerekre szánnak. Ezzel egy időben arról is lehullott a lepel, hogy a Microsoft nem csak az AMD-vel, hanem az Nvidiával is együttműködik a C++ AMP sikerének érdekében.

Hírlevél feliratkozás
A feliratkozással elfogadom a Felhasználási feltételeket és az Adatvédelmi nyilatkozatot.

27 hozzászólás

A komment írásához előbb jelentkezz be!
sanyix
sanyix
2011. jún. 19. 15:24
#26

Ez a cucc egy valamire jó, pont arra amire anno a directx készült. Multiplatform, jól elterjesztik akár zsebpénzzel is, majd hopp x verziótól már nem lesz multiplaform. Viszont a fejlesztők már ráálltak, így onnantól a programok saaaajnos csak winen fognak működni.

Mindig is így volt.

Ha van valami nyílt és multiplatform, az ms csinál hozzá egy saját platformfüggő változatot, ugyanis a sikerük ebben rejlik, hogy ha akarsz sem válthatsz winről mert a szabványtalanított szabványokkal, platformhoz láncoló saját marhaságokkal, úgy is szopni fogsz ha megpróbálod.

Lásd az IE6 szabványtalan html-jével sokáig ie6-hoz láncolták főleg a nagyvállalatokat, vagy a directx ami szintén multiplatform volt aztán mikor elterjedt nem lett, és a linux és macen futás legnagyobb gátja a directx, vagy ott a doc is amiről semmi leírás nem volt, viszont jó ideig csak abban lehetett menteni az ofiszban, és ezeket az ms ofiszon kívül semmilyen más szoftver nem tudja megnyitni tökéletesen. A webgl-t sem akarják használni (mert nyílt és multiplatform), helyette bullshiteket gyártanak hogy nem biztonságos, ők akik az ie6-ot, és az activex-et nyomatták/ják, és a flasht is támogatják, amelyek a legnagyobb biztonsági kockázatot jelentik a számítástechnikában.

MacAndor
MacAndor
2011. jún. 19. 14:56
#25

Eroteljesen foglalkozok parhuzamositassal, es azert nem ennyire egyszeru. Amint szobakerul a memoriamenedzsment, mar fel is tudja borittani az egeszet. Egy olyan egyszeru dolog, hogy egy valtozoba egyszerre ket szal akar irni, ki tudja fagyasztani az egesz progit. Nehezebb algoritmusoknal eleg nehez jol es optimalisan parhuzamosittani.

thedeveloper
thedeveloper
2011. jún. 19. 14:12
#24

Az a baj, hogy a mostanában készülő alkalmazások készítői egyszerűen nem foglalkoznak a témával. Pedig nem lenne sokkal bonyolultabb a kód, ha legalább néhány, nagy erőforrásigényű és jól párhuzamosítható ciklust párhuzamosítanának.

OpenMP-ben ilyen bonyolult feladat:

pragma omp parallel for

for (...) {

...

}

MacAndor
MacAndor
2011. jún. 19. 14:10
#23

fbi1984:

Ez igy nem teljesen igaz, egy programot cpu-n vagy gpu-n futtatni nem ugyanaz, meghozza a gpu felepitese miatt mas, a gpu a vector alapu muveletekre van optimalizalva, igy kepfeldolgozasra, fizikai es egyeb tudomanyos szamitasokra sokkal alkalmasabb.

Egy csomo profi program mint a photoshop, after effects, stb. ki is hasznalja ezt az elonyt.

Leegyszerusitve, akar egy 32 magra optimalizalt es azon futo programot is sokkal gyorsabban meg tud csinalni egy gpu ha olyan szamitasok vannak benne (vektor es matrix alapu). Vice versa...

A lenyeg, hogy okosan kell programozni. :)

fbi1984
fbi1984
2011. jún. 19. 13:03
#22

Jó hogy lesz lehetőség a GPU-n futtatni párhuzamos számításokat, de szerintem ez megmarad amolyan egyetemi szakdolgozat témának, vagy egyetemi kísérletezgetésnek.

A jelenlegi alkalmazások nagy része még a CPU több magját sem használják ki, ezért is tette bele az MS a Parallel API-t a .NET 4. be.

Ha már tényleg kihasználjuk a 4-8 CPU magot, és ez sem elég, akkor lesz értelme a GPU-n való futtatáson gondolkodni.

MacAndor
MacAndor
2011. jún. 19. 12:04
#21

Juliska: 100%-osan korrekt valasz!

Kben eleg fun, hogy a forumozok nemelyike azt hiszi, hogy ugy szolunk hozza a hirhez, hogy 1, nem olvassuk el, 2, nem ertunk hozza...

Juliska
Juliska
2011. jún. 18. 19:36
#20

MacAndor: Én is így gondolom. Ha valami Microsoft, akkor az erősen kötődni fog a Windows-hoz. Az open szöveg csak mézesmadzag.

Az API-t nem ítélem el előre, majd megnézem a következő Visual Studio-t, de ha most kellene választani, akkor OpenCL.

Az OpenCUDA-t én is támogatnám, de szerintem hiú ábránd. Imádom az NV felületét, azon is kezdtem, de nincs jövője zártan.

MacAndor
MacAndor
2011. jún. 18. 17:59
#19

flameKing:

1, Garantalom, hogy a microsoft nem fogja tenylegesen megcsinalni a multiplatformot, semmi okot nem adnak ra, hogy csak egy kicsit is bizzak ebben.

2, Igen, az OpenCL-t hasznalom, mert programozo vagyok, a masikat termeszetesen meg nem hasznaltam, de mivel microsoft termekrol leven szo, eros 80%, hogy se gyors se stabil es legfobbkent multiplatform sem lesz.

Az OpenCUDA tilleg jo otlet lenne! :D

thedeveloper
thedeveloper
2011. jún. 17. 21:45
#18

C fordítóból is létezik többféle, mindegyiknek megvan a maga sajátossága, assembly fordítóból pedig egyenesen Dunát lehet rekeszteni, mindegyik más fordítási direktívákat használ.

Az előállított bináris kód is nyilvánvalóan különbözik.

Mindezek ellenére a tárgykódok mindegyike futtatható.

jozsefm
jozsefm
2011. jún. 17. 20:48
#17

A májkrémszoft-é krémesebb

Juliska
Juliska
2011. jún. 17. 20:46
#16

Hurrá. Még egy alternatíva ugyanarra. Azt lehetne részletezni, hogy miben jobb, mint az OpenCL, mert nekem majdnem ugyanannak tűnik.

bszoke88
bszoke88
2011. jún. 17. 20:41
#15

14

személy szerint prog. infót tanulok jelenleg, szóval elég elképzelhető, h mire sikerül elvégezni (remélem mihamarabb), addigra a legfőbb programozói 'profil' ez lesz.

egyébként meg akárhogy is nézzük, a GPU-kban nem kis számítási kapacitás van, lásd a tesla szerverek...

Ragnarr
Ragnarr
2011. jún. 17. 19:10
#14

LOL eggyesek itt ugy panaszkodnak mint ha nekik kelle GPU-ra fejleszteni :D

Terror
Terror
2011. jún. 17. 19:16

Mert nem valószínű, hogy egy számítástechnikával foglalkozó fórumra számítástechnikával foglalkozó emberek tévednek be, nem? (én hál' Istennek nem programozok, csak úgy kérdem)

bszoke88
bszoke88
2011. jún. 17. 18:27
#13

9

"ez a C++ AMP nem egy új nyelv"

ok, azt értem. az openCL sem nyelv, legalábbis:

http://en.wikipedia.org/wiki/Opencl

siriq
siriq
2011. jún. 17. 16:07
#12
jozsefm
jozsefm
2011. jún. 17. 14:23
#11

Na majd az OpenCUDA AMP++:D:D

Ez jó volt,de számukra ebben a környezetben nem lesz humoros.

rini
rini
2011. jún. 17. 14:14
#10

Az sosem baj ha van több válaszható alternatíva is. Az idő majd megmondja, hogy melyik életképes. Lesznek egyesek melyek majd eltűnnek és lesznek megint újak amelyek még fejlettebben fognak megjelenni.

thedeveloper
thedeveloper
2011. jún. 17. 13:52
#9

Ez szerintem is probléma, hogy túl sok alternatíva lesz a párhuzamosításnak, és minden fejlesztő más és más rendszert fog favorizálni.

Bár nem tudja ezt a homogén CPU-GPU párost, de ott van még az OpenMP és az MPI is, amik szintén elsősorban C++ / C orientáltak.

Majd meglátjuk, hogy melyik válik be a legjobban.

Azt csak halkan mondanám, hogy ez a C++ AMP nem egy új nyelv, csak egy függvénykönyvtár, mint az OpenMP.

bszoke88
bszoke88
2011. jún. 17. 13:27
#8

még jó, h az OpenCL-t azért csinálták/csinálják, h 1 azaz egy, egységes programozói felület legyen. de neeeem. még adjunk ki 10 különböző programozási nyelvet, ugyanarra.

legyen már elég mindenre assembly, C, Java, C++! vagy még kevesebb. nem új prog. nyelvek kellenek, hanem meg kéne tanulni programozni. (ezeket)

Bla255
Bla255
2011. jún. 17. 13:21
#7

Na majd az OpenCUDA AMP++ azmár mindenkinek megfelelő lesz, főleg akinek szüksége is lesz rá.

rini
rini
2011. jún. 17. 13:00
#6

Még tovább menve:"Ezzel egy időben arról is lehullott a lepel, hogy a Microsoft nem csak az AMD-vel, hanem az Nvidiával is együttműködik a C++ AMP sikerének érdekében."

Röviden ők is támogatják ezt a lehetőséget. Az is biztos, hogy csak egy maradhat idővel.

flameKing
flameKing
2011. jún. 17. 12:24
#5

Te jó ég, ez a 2 hozzászólás önmagáért beszél! El kéne olvasni a hírt, mielőtt kitörne a tipikus magyar troll. ;/

MacAndor: honnan tudod zsenikém, hogy szarabb, tán dolgoztál már vele (sőt, mindegyikkel!), és ismered minden csínját-bínját (az összesnek)?! :D Maradjunk annyiban, hogy az idő el fogja dönteni, melyik marad életben, bár nem értem, miért ne férnének meg egymás mellett. :)

tomchee
tomchee
2011. jún. 17. 12:09
#4

somakb:

...és szerinted nem fog az ms inkább mindent úgy fejleszteni, hogy bár többi oprendszere/platformon is jó legyen, de ezért mégis csak az ő temékeit támogassa leginkább?... :) DE! Ismerjük őket ők már csak ilyen zs***k :D

Akkor lenne teljesen hatékony egy ilyen project ha teljesen ms független lenne... :/

somakb
somakb
2011. jún. 17. 11:52
#3

MacAndor: "Ekkora kreteneket, ahelyett, hogy egy multiplatform API fejlestesen dolgoznanak, kihozzak a sajat cuccukat"

figyelmesebben olvasd el a hírt, ugyanis ott olvsható hogy :

"A Microsoft újdonsága nyílt, így a tervek szerint a jövőben nem csak Microsoft platformokon és nem csak a Microsoft által készített fordító alkalmazásokkal lehet majd használni."

"A Microsoft és az AMD együttműködésének köszönhetően már készülnek azok a fordítók, amelyeket a cégek nem Windows-ra, hanem egyéb operációs rendszerekre szánnak"

MacAndor
MacAndor
2011. jún. 17. 11:34
#2

Ekkora kreteneket, ahelyett, hogy egy multiplatform API fejlestesen dolgoznanak, kihozzak a sajat cuccukat, ami szarabb, de mivel mas nem all majd a fejlesztok rendelkezesere, ezert azt kell hasznalniuk...

/ 2
Vissza az oldal tetejére