Új hozzászólás Aktív témák
-
veterán
Gondolom a szoftveripar elég szűk területén lesz használva ez a keretrendszer.
-
$p@rr0w
őstag
Ésa gyakorlatban úgy kell majd telepítenünk mint egy net frameworkot?
Kinőhetnétek már abból, hogy leírogatjátok miből nőttetek ki.
-
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.
-
Meteorhead
aktív tag
É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).
-
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.
-
tocsa
senior tag
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.
[ Szerkesztve ]
Acer Predator Helios 500 Ryzen, Samsung 960 Pro NVMe + GeChic 15.6" kulso monitor a mobil irodahoz