1, Ha lehetne, akkor senki. De nem lehet hatékonyan. A C++AMP 100% C++ szintaxis, csak a függvénykönyvtárak mások (és próbál minél jobban hasonlítani az STL-re).

2, SMP-re lehet data parallel programot fordítani, miért ne lehetne? Sőt, single processzorra is lehet írni, max nem lesz gyorsabb, mint a natív megvalósítás Fordítva van a probléma. Egyszerűen azért, mert a GPU-ban úgy vannak a végrehajtó egységek, hogy (pl.) 32 darabonként van egy darab közös vezérlőegység. Tehát 32 szálanként egy adott órajel alatt pontosan ugyanazon utasítás hajtódik végre mind a 32 szálon, nem működik az, mint SMP esetében, hogy egyik szállal ezt, másikkal azt csinálom. Egy standard SMP esetében ha van 32 darab végrehajtó egységed (processzorod..), akkor az 32 különböző dolgot csinálhat. (sőt, fog csinálni, mert még processzoron belül is gyakorlatilag kivitelezhetetlen az utasítás szintű szinkronizálás.)

3, Mert miben legyen, a C++ is egy textfájlban van, mielőtt lefordítod. A probléma az, hogy nem fordíthatsz máshol, csak a kliens gépén.

2.) Pont azt magyarazod, hogy miert lehet letjogosultsaga egy ilyen many-core x86-os architekturanak. A 32-es warp size miatt ha a thread-ek futasi ideje nagyon kulonbozo, akkor az nagyon betehet az ossz teljesitmenynek a GPU-nal. Vegyunk peldaul egy kepfeldolgozasi algoritmust, ami maszkolt, azaz a kep csak bizonyos reszeire kell lefuttatni, es ezek a reszek amorfak. Namost egy data parallel algoritmust siman raszabaditok 8 magra, ugy ahogy van, ezek szepen kiszamolnak minden, ha valamelyik pixel es kornyezete hatarertek alatti, akkor nyomul a kovetkezore. Ellenben a GPU nagyon megszivhatja. Most csak emiatt strukturaljam at az adatot? De az egesz tili-tolival nagyon elmegy az ido. Mar az adat mozgatas a GPU es a rendszer kozott is problema, es ezt meg meg kene fejelni megegyszer annyival, hogy atrendezgessek, hogy a GPU-nak kegyeskedjen jo lenni a bemenet.

(Azt is tegyuk hozza, hogy a legujabb generacios nVidia GPU-knak mar fejletteb utemezoje van es ilyen kiegyensulyozatlan feladatok eseten jobban teljesitenek, de nekem meg nincs ilyen kartyam).

(Meg azt is tegyuk hozza, hogy az AMD legujabb tervezett APU-inal pedig az adat mozgatas a CPU es a GPU kozott nem lesz gond, mivel nem lesz szukseg ra, mert mindketto ugyanazt a kozos cimteret es GDDR5 memoriat latja majd.)

3.) Varjunk azert. Egy darab string tipusu valtozo, karakter halmaz egy fajlon belul != maga a text fajl. Az a C++ text fajl az IDE-ben megnyitva syntax highlight-olt, debuggolod, sorokra ugrassz, stb. Mig egy stringbe belehanyva az egesz source... hat... nem kis kulonbseg van. Pl a syntax highlight esetleg felesleges funkcionak tunhet, de valojaban nagyon sokat jelent ahhoz, hogy jobban atlassad a kodot es konnyebben eszrevedd a hibakat. Majdnem erre megy ki az egesz jatek, hogy kikuszoboljuk a hibakat, amiket vetunk! Minden lepes szamit ehhez.

Acer Predator Helios 500 Ryzen, Samsung 960 Pro NVMe + GeChic 15.6" kulso monitor a mobil irodahoz

Nem az adatot kell átstrukturálni, hanem az algoritmust. Akárhogy is, a natív megoldás még ha le is fordul, nem lesz gyorsabb. Lehet, hogy e miatt jó lehetne a many-core x86, de ha sok CPU mag kell, tegyél a gépbe sok CPU-t. Ezek a kártyák sose akartak mást, mint amit tudnak, ha programozni akarod őket, azt úgy kell csinálni, hogy nekik jó legyen.

Nem tudom te milyen IDE-t használsz, de mind a Visual Studio és az Eclipse is .cl fájlban is highlightol, és debuggolni is tudom (bár ez utóbbi erősen SDK függő).. A szögnél bonyolultabb kódokat amúgy is ki kell szervezni külön fájlba, gyakorlatilag semmi sincs .cpp forrásban idézőjelek között.

Nem veszed számításba, hogy az x86 nem skálázhatóságra épített ISA. Amikor tervezték, akkor sosem merült fel, hogy lesz többmagos korszak. Ezért módosították a MIC-ben, mert a hagyományos x86 nem skálázódik jól egy bizonyos szint után, a változásokkal viszont megszűnt a bináris kompatibilitás, de ez mindegy is. A jelenlegi MIC-ben a rendszer úgy skálázódik megfelelően, ha a magok által futtatott feladathoz az adat ott van a magokhoz rendelt L2 cache-ben. Ha a memóriába kell menni érte, akkor sokat veszít a rendszer. Ezért van a Knights Cornerben 30+ MB L2 cache, miközben a többi GPU-ban 1 MB körüli L2 van, de csak azért, mert az ISA-ba beletervezték a skálázhatóságot. Ez az oka annak is, hogy az AMD és az NV, illetve a többi GPU fejlesztő cég 3-4-5 évente kompletten lecseréli az ISA-t. Ezek nem olyan hardverek, hogy évtizedekig lehet ugyanahhoz az ISA-hoz ragaszkodni. Lehet, csak nem fog skálázódni.

[ Szerkesztve ]

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

Mindenki tudja, mire gondolt, de egy ehhez hasonló hw nem lenne jó arra. Teljesen beállna az egész.

(#50) Pikari: Az nem lehet, hogy csak neked nem sikerült, azért vagy ilyen frusztrált?

Azt kellene már megérteni, hogy CPU alapon sokkal nagyobb fogyasztással lehetne kihozni hasonló számítási teljesítményt.

Koszi egyebkent a "vitat", eszmecseret.
Szandekosan helyezkedtem egy kicsit a kartya oldalara, es probaltam felhozni erveket mellette. Vegul ugyos a piac dont. A CUDA miatt meg amugy is at kell strukturalni kicsit a programot. Ami architekturalisan az elonyere is valik, hogyha nem olyan bonyolult az akernel es nem include-ol be foloslegesen dolgokat.

Acer Predator Helios 500 Ryzen, Samsung 960 Pro NVMe + GeChic 15.6" kulso monitor a mobil irodahoz

Igaz, sajnos a skalazodas az problema lehet. Ezen javithat az, hogyha a feladat szerencses, es nagy CPU de keves memoria mozgatasi igenyu. De ez ritka. x86-nal Intel eseteben a QPI segitene (bizonyos feladatoknal), de a Phi-ben nincsen QPI.
A savszelesseg a GPU-knal is problema amugy, az nVidia cross-bar memoriat tervezett az AMD pedig ring buszt. (javitsd ki ha forditva van), mindkettonek megvan a maga elonye es hatranya.

Acer Predator Helios 500 Ryzen, Samsung 960 Pro NVMe + GeChic 15.6" kulso monitor a mobil irodahoz

Ezek a kártyák jók, mert első blikkre iszonyat teljesítményük van - céges gépemben van egy i7-i3667U, a benne levő értékelhetetlenül hipergyenge HD4000 is 8-10x gyorsabban szoroz össze nagy (~3000x3000) mátrixokat. Viszont helyén kell kezelni őket, különben pofára esés lesz az egész - kis mátrixokra (~8x8) már lekörözi a proci, mert csak 64 szálat lehet indítani az eredmény kiszámolására, ami kevés.

Nem úgy tűnt, mintha mindenki tudná.
...és miért is állna be az egész rendszer? Anélkül, hogy tudnád, mit is kell számolni, te megmondod, hogy nem működne

Abu pl. tudta, ez a válaszából is kitűnik.

Nem csak én mondom meg. Szerinted miért hagyta ki az Intel az x86 kompatibilitást? És nyomatja hozzá az OpenCL-t?

De amúgy könnyű belátni:
- Egy 8 v. 16 procis, egyenként 8 v. 4 magos E5-46xx cluster össz-memóriasávszélessége ~400/600 GB/s, de ami fontosabb, összesen 2048/4096 biten! Alacsony késleltetésű DDR3-mal. Phi: 352 GB/s, 512 biten, nagyobb késleltetésű GDDR5-tel.
- A fenti clustereknél összesen 176MB L2+L3 áll rendelkezésre, a Phinél 31MB L2.
- A fenti clusterekben összesen több TB memória lehet, Phi: 8GB.
- A Phi magjai nem teljes értékű procimagok, valószínűleg nem annyira szeretik az ugribugrit, ráadásul in-orderesek. Ugyanakkor a hatékony kihasználásukhoz masszívan SIMD-ezett kódra van szükség.
- A clusternél nem kell, hogy különösebben össze legyenek hangolva a procik (még az egyes magok sem annyira), a Phinél azonban ez megkerülhetetlen.

Mert nem ideális _általában_. Viszont tudom mire akarná használni helkis, és oda ez tökéletes lenne.

Annál a feladatnál ~30MB adat van gyilkolás alatt, egy darab 4GHz-es Ivy maggal kb 5-6 perc egy lefutás, aminek az eredménye mindössze két darab double érték, viszont minimum 10.000 lefutás kell (de ha meglenne a szükséges teljesítmény, akkor ez milliárdos nagyságrend inkább), és ezek teljesen függetlenek. Gyanítom bőven elég lenne a memória méret és sávszélesség.

Ha általánosságban kijelented, hogy nem volt ideális az x86 ehhez, és azért kukázták, akkor egyetértek, de az adott feladat és a megvalósító x86-os kód ismerete nélkül nem kéne ilyet kijelenteni...

"de ami fontosabb, összesen 2048/4096 biten" Őőő... ha a sávszélességeket hasonlítgatod össze, akkor annak nem sok jelentősége van, hogy az adott sávszélesség hány bites busszal jön ki. Vagy szerinted 100MHz 128bit gyorsabb, mint 200MHz 64 bit? A késleltetésnek már inkább van szerepe (meg persze annak, hogy mekkora adatot akarsz átpréselni egyszerre az adott buszon).

Jó, de ez már nagyon speciális eset! Amúgy meg lehet tudni, hogy ez mi a "fene"?

A #2-esben normál programokat, taszkokat említett. Később is csak jól párhuzamosítható feladatokat, így a kettő együtt pl. renderelést sejtet.

Nem csak a sávszélességet hasonlítottam össze, mint láthatod, hiszen nem csak az számít. Pl. egy sok szálon futó, nem külön GPU-ra fejlesztett renderelés esetén, ahol az egyes szálak egymástól nagyrészt függetlenül dolgoznak, eltérő memóriahozzáférési patternnel, nagyon nem mindegy, hogy hány biten és csatornán érik el a ramot a magok. Ilyen esetben az 512 bites GDDR5 (neki megfelelő 5 GHz körüli effektív órajellel) sehol sincs a 32-64 csatornás, 2048/4096 bites DDR3-hoz képest (hiába csak ~2 GHz).

azért itt a gondolatmenetet még bonyolítja a random memory read kérdése, pontosabban az, hogy az algoritmusodnak mennyire van szűksége rá.

A Dunning−Kruger-hatás az a pszichológiai jelenség, amikor korlátozott tudású, kompetenciájú vagy képességű emberek rendkívül hozzáértőnek tartják magukat valamiben, amiben nyilvánvalóan nem azok.

Igen, bár a memóriahozzáférési patternbe ez is beleértendő.

Igen, spec eset, de nekünk pont ez van Ezért mondom, hogy általánosságban igaz amit írsz, de ebben a konkrét helyzetben nekünk jó lenne az x86 kompatibilitás.

Szerintem ez nincs feltétlenül így, de rendereléssel és hogy ott mi az előnyös, azzal nem foglalkozom, így inkább nem mennék bele.

szerintem igazából végső soron lényegtelen, hogy x86, arm, vagy mips. a linuxnak mindegy. a lényeg, hogy monolitikus legyen, hogy pthread_createval le tudja rakni a szoftvered a petéit.

A Dunning−Kruger-hatás az a pszichológiai jelenség, amikor korlátozott tudású, kompetenciájú vagy képességű emberek rendkívül hozzáértőnek tartják magukat valamiben, amiben nyilvánvalóan nem azok.

Ha az egész újra írható (és a költségvetésbe, időbe belefér), vagy még nincs meg, akkor mindegy, persze.

miért kéne újraírni? semmit sem kell újraírni, lefordítod és kész.

A Dunning−Kruger-hatás az a pszichológiai jelenség, amikor korlátozott tudású, kompetenciájú vagy képességű emberek rendkívül hozzáértőnek tartják magukat valamiben, amiben nyilvánvalóan nem azok.

Erm? Még mindig GPU-n futtatásról beszélsz?

már rég nem arról beszélünk, jóreggelt

A Dunning−Kruger-hatás az a pszichológiai jelenség, amikor korlátozott tudású, kompetenciájú vagy képességű emberek rendkívül hozzáértőnek tartják magukat valamiben, amiben nyilvánvalóan nem azok.