[Re:] A fejlesztőknek már elérhető a C++ AMP többplatformos verziója

LOGOUT témák

PROHARDVER! témák

Mobilarena témák

IT café témák

GAMEPOD témák

Új hozzászólás Aktív témák

#8 tocsa senior tag LordX #7

Új Válasz 2014-08-29 20:16:40 #8
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

tocsa

senior tag

válasz LordX #7 üzenetére

LordX - nagyon igazad van az "owning container" kerdesben.
Mindenkinek nagyon ajanlom megnezesre Herb Sutter "Modern C++: What You Need to Know" cimu eloadasat ami az idei GoingNative konferencian hangzott el, on-line nezheto volt.
Itt egy link a felvetelre, Channel 9: Herb Sutter - Modern C++: What You Need to Know
Bar az egeszet *nagyon* erdemes vegignezni (pl az elejen beszel value es referencia tipusokrol, es kepet kaphatsz arrol is, hogy mi az az owning container), es 23:35-tol kezd el beszelni az "igazi tombokrol" ("real arrays"). Ugyanis az std::vector valoban "igazi" array, olyan szempobntbol, hogy az elemek valoban sorban egymas utan jonnek. Es ha vegignezed az eloadast, meg fogsz dobbeni, hogy egy egyszeru indirekcio, ami dinamikus (python, JS) vagy GC nyelveknel (Java, C#) tuti bejatszik (akar tobbszoros indirekcio is), milyen drasztikusan rombolja szet a sebesseget, mert az osszes soros eleresre kihegyezett cache, interleaving es egyeb hardware rasegites nem tud megfelleoen mukodni.
Az std::vector viszont jol teljesit!
Amugy a C++AMP multi platformossaga csak egy azon hirek kozul, ami egy jobb fajta jovo fele mutatnak GPGPU szempontbol. Biztato a dolog.
#7 LordX veterán Meteorhead #6

Új Válasz 2014-08-27 10:27:46 #7
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

LordX

veterán

válasz Meteorhead #6 üzenetére

A concurrency::array az egy owning container, mint a vector, ott halt volna meg helyben, ha C++-ra egy referencia szemantikájú kiegészítést csináltak volna. Mint minden value semantics cucc, akkor szabadítja fel az erőforrást, amikor lefut a destruktor.
Ha tud no-copy-t a hardver (nem kell SVM) és úgy konstruálod az concurrency::array-t (vannak mindenféle flagek, nézd meg a doksit), akkor a benne levő cl::buffer a host memóriára mutat.
#6 Meteorhead aktív tag LordX #5

Új Válasz 2014-08-27 08:52:38 #6
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

Meteorhead

aktív tag

válasz LordX #5 üzenetére

Én nyílván nem látok bele a működésébe, de úgy tippelem, hogy a libcxxamp.so nem csinál sokkal többet, mint a libopencl.so, ami csak az ICD-t tartalmazza, azaz csak az implementációk futásidejű betöltéséért felelős (amit OpenGL alatt kvázi pl. a GLEW pótol). Ettől még a runtime, ami a munka kemény részét végzi, az a libamdocl64.so és társai libekben vannak.
Lehet ez csak szőrszál hasogatás.
Arra egyébként kíváncsi lennék, hogy OpenCL 2.0 hogyan is fogja AMP esetében automatikusan eltűntetni a másolásokat? Az addig ok, hogy a concurrency::array az std::vector-hoz hasonlóan tartalmaz egy host oldali pointert is, de számomra sosem volt tiszta, hogy milyen kapcsolatban van a concurrency::array, az std::vector, és a cl:uffer egymással. A cl:uffer csak egy handle, ha lemásolom nem történik semmi. A concurrency::array esetében a spec szerint deepcopy történik, ahogy az std::vectornál is.
Mennyiben állja meg a helyét az a hasonlat, hogy a concurrency::array a vectorhoz hasonlóan konkrétan tárolja is az adatot (minden szempont szerint)? Engem a host oldali pointer része zavar, mert ha egyszer visszakértem az adatot host oldalra, akkor lefoglal magában egy akkora területet. De ez mikor szabadul fel? Ki vagyok vele segítve, ha OpenCL 2.0 megtehetné, hogy ne másolgasson, de cserébe adatduplikál (és evvel tulajdonképpen másolnia is kell, még ha nem is BUS-on keresztül).
#5 LordX veterán Meteorhead #4

Új Válasz 2014-08-26 19:53:43 #5
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

LordX

veterán

válasz Meteorhead #4 üzenetére

Olyan szinten, mint a C-nek, ennek is van egy runtime-a. Pár nagyságrenddel kisebb, mint a .NET, de létezik.
Ha akarsz futtatni szűz Windowson C++AMP kódot, akkor fel kell telepíteni vagy mellékelni kell a program mellé a VC10 / VC11 / VC12 runtime-ot, ami konkrétan 4 db .dll. A környezet maradék része meg igen, a grafikus driver és a DirectX része.
Linuxon ugyanúgy fel kell tenned a libcxxamp.so-t, meg a backendet biztosító OpenCL vagy HSA környezetet.
#4 Meteorhead aktív tag LordX #3

Új Válasz 2014-08-26 19:11:49 #4
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

Meteorhead

aktív tag

válasz LordX #3 üzenetére

Windowson a runtime a grafikus meghajtó, ami tartalmazza a DirectX compute shader fordítót. Linuxon vagy a HSA driver oldja majd meg, vagy egy OpenCL implementáció. C++AMP-nak nincs külön runtime-ja egyik platformon se.
#3 LordX veterán $p@rr0w #2

Új Válasz 2014-08-26 16:44:17 #3
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

LordX

veterán

válasz $p@rr0w #2 üzenetére

Hát, igen is meg nem is.
Windowson nincs külön runtime, a Visual C++ runtime része, meg 4 darab .dll.
Linuxon meg a a libcxxamp.so kell hozzá (vagy amit az AMD most összerakott, ha az nem ez).
#2 $p@rr0w őstag

Új Válasz 2014-08-26 16:37:58 #2
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

$p@rr0w

őstag

Ésa gyakorlatban úgy kell majd telepítenünk mint egy net frameworkot?
#1 #39560925 törölt tag

Új Válasz 2014-08-26 16:32:30 #1
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

#39560925

törölt tag

Gondolom a szoftveripar elég szűk területén lesz használva ez a keretrendszer.