Ez milyen területeken gyorsíthat? Gondolom egy normál adatkitöltős, grafikonos, táblázatos (max 100 soros) website esetén nem sokat.

Azt tudom elmondani, hogy a demók között volt a kihagyhatatlan nbody, és volt program szavak keresésére egy brutális adatbázisban, ami egy rakás könyv digitális másolatát tartalmazta. Utóbbiban olyan 4-5x-ös gyorsulás volt.

[ Szerkesztve ]

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

Fedora? Nem a Red Hat?
Köszi a cikket, nekem mint usernek annyi jött le, hogy gyorsul. Mondjuk eddig veszett gyors volt

Hold on, trying to give a fuck... Nope, not Happening • Powered by Fedora Linux • "Az élet olyan sz@r, szerencsére a felén már túl vagyok" Al Bundy

A Minecraft is java nem? Az is gyorsulhat?

"Minecraft was created in Java, so it must also be installed to run the game."

[ Szerkesztve ]

Kinőhetnétek már abból, hogy leírogatjátok miből nőttetek ki.

Végre, végre!
Remélem ettől majd lassan beindul az asztali és mobilos linux-kerneles környezetek hatékonyítása is. Nagyon kellett már ez a HSA! És java-kóddal is közelebb lehetünk az ideálishoz, nem muszáj GPGPU-nindzsának lenni.

Csak ha átírják az öreg kódot, amit nem hiszem, hogy megtennének.

[ Szerkesztve ]

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

Mielőtt nagy ujjongsba kezdene mindenki, nem a java kóüdok futnak majd jobban, hanem a lambda api-t használó kódik. (arc/képfelismerést csinálnak)
Szóval a nagy ujjongás az eddig is elég döcögősen megírt gpgpu-val gyorsított dolgokat érintik. Talán most egy fokkal könnyebb lesz rájuk programozni. (de biztos nem fog gyorsabban futni a progi, mint opencl-el vagy cudaval)

A hozzászólási jogosultságodat 2 hónap időtartamra korlátoztuk (1 hsz / 10 nap) a következő ok miatt: Az ÁSZF III 10/8. pontjának megsértése - trollkodás - miatt. Többször és többen is kértek már, hogy hozzászólás írásakor használd a linkelés funkciót, mert ennek elmaradása sokak számára zavaró.

Nem nagyon, a Minecraft alapvetoen azert lassu, mert mert nagyon reszletes* a grafikaja es egyszeruen a GPU-t ennyire leterheli.

*: igen, az. Az osszes tobbi jatek azt csinalja, hogy a kozeli objektumokat (amikbol keves van) reszletesen rajzolja ki, a tavolaiakat (amikbol meg sok) meg elnagyolva ill. jo reszuket ki se rakja. A Minecraft meg a tavolabb levo dolgokat is mind ugyanugy kirajzolja, mint amikor kozel vannak, es hiaba csak egyszeru kockak, ha sokmillio van beloluk.

DRM is theft

Bár a korábbi Aparapi verzióhoz képest a működésben lényegében csak az a különbség, hogy a rendszer a bájtkódot nem OpenCL-re, hanem HSAIL-re konvertálja, ami nem tűnik sok változásnak, valójában viszont komoly jelentősége van.

Szóval átfordítja byte-onként a kódokat, nesze semmi fogd meg jól, sime java-ban írt alkalmazások nem fognak gyorsabban futni semmivel sem.

Mert ezek mérések. Ott ki lehetett próbálni. Az nbody ennyit gyorsult, de 16k szimulációval 12x is gyorsabb volt. Ez az oka, amiért a heterogén többmagos dizájnban látja minden piaci szereplő a jövőt.

[ Szerkesztve ]

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

Mennyit ment only gpu-val?

A hozzászólási jogosultságodat 2 hónap időtartamra korlátoztuk (1 hsz / 10 nap) a következő ok miatt: Az ÁSZF III 10/8. pontjának megsértése - trollkodás - miatt. Többször és többen is kértek már, hogy hozzászólás írásakor használd a linkelés funkciót, mert ennek elmaradása sokak számára zavaró.

A HSA-s Aparapi az only GPU-t nem támogatja. Maga a rendszer koncepciója igényli a hUMA-t, a hQ-t és a Platform Atomicset. Az OpenCL-es Aparapi fut only GPU-val. Az nbody azon jól megy, gyakorlatilag Kaveri/Berlin IGP teljesítményével rendelkező GPU hozza a 10-12x-es gyorsulást. Ezzel szemben a szókeresés akármilyen GPU-val lassabb a CPU-s módhoz képest. Persze ez azért van, mert a feldolgozás 90%-a csak adatmásolás a két különálló memóriaterület között. Ezért is nincs HSA-s Aparapi dedikált GPU-ra.

[ Szerkesztve ]

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

A Berlin APU egy szerverbe szánt fejlesztés. Senki sem fogja asztalba rakni. Korábban írtuk már, hogy a HSA első körben a szerverekben terjed el. Itt van a legnagyobb igény rá, illetve az Oracle is nagyon felkapta már. A többi jön sorban, de valszeg a konzol a következő, ahol ez a fajta koncepció tömegesen megveti a lábát, míg a PC lesz az utolsó. Szerintem még a mobilon is hamarabb lesz, mert az ARM-os gyártók egyetértenek, hogy a HSA-t kell tolni, és a Google is ezt akarja az OpenCL helyett.
Persze PC-n már reménysugár, hogy a Crytek elemzi a HSA-t, tehát lehet, hogy nem kell rá sokat várni. Ha mákunk van, akkor az év végére már beépítik a motorba. Ha nem, akkor csak a konzolon lesznek elérhetők az extrák.

[ Szerkesztve ]

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

Ujabb feszult varakozas

facebook.com/mylittleretrocomputerworld | youtube.com/mylittleretrocomputerworld | instagram.com/mylittleretrocomputerworld

Pedig itt szakertok mar elmagyaraztak, hogy ez egy halott ugy, mert 2 het alatt meg nem lattak semmi eredmenyt...

Gyerekek! Nem Abu-t kell meggyőzni arról, hogy ez az egész GPGPU mizéria hülyeség. Ő híreket közöl, nem piacot diktál. Elhiszem, hogy rossz egy változást olyan részvevőjének lenni, akinek sok belszólása nincs a helyzet alakulásába, de be kell látni, hogy minden piac akkor tud ténylegesen fejlődni, ha időnként nézőpontváltáson esik keresztül. Ehhez meg először egy hardver kell, amin ezt végre kell vinni. Anno megjelenésükkor a kétmagos processzorok se pofozták a földbe valós progaromkban az egymagos verziókat, mégis azóta lett értelme még a 8 szálas cuccoknak is. Érdekes.

(#7) Jack@l: Nem vagyok IT szaki, de azért annyit én is tudok, hogy állami/ipari/kutatási viszonylatban egy-egy szerkezet árán $100.000-ket dobhat fel és le a zárójelbe fitymált képességpárosban nyújtott teljesítmény. Nem véletlen, hogy az Intel is annyit költ a MIC-re.

(#11) Zso2: A Kaveri/Mantle piacán a vásárlóknak belengetett "up to +45%" annyit tesz, hogy megfelelő programban, megfelelő összeállításban ennyit is hozhat pluszban az alap, meglévő állapothoz képest. Azaz kaphatsz ennyi pluszt ingyen, ha szerencsés vagy. Mi voltunk hülyék, hogy az "up to" részt nem vettük komolyan.

Ellenben a Berlin piacán azért az adott feladatbeli 300-1000%-os teljesítményugrásért a vásárló meg tud dolgozni megfelelő szoftverek fejlesztetésével. Ezt meg többnyire megelőzi rengeteg saját teszt, kockázatfelmérés. Senki le se szrja, hogy az AMD marketing címszó alatt mit akar lenyomni a nép torkán.

Meglátjuk mennyire és mivel lesz frankó a hsa apu-n, meg mondjuk opencl gpgpu-n. (gyanítom a feladatok nagy részénél elvérzik majd az apu)
Nem a hsa ellen vagyok, sőt, eléggé szorosan követem a gpgpu-s fejlesztéseket, nagy ötletnek tartom. Ugyanakkor a hype-ot nem értem mögötte, nem lesz megváltás, nem fog minden 10x-es sebességgel működni varázsütésre. Nem vletlenül nincsenek még mindig ezerszámra ilyen programok.

A hozzászólási jogosultságodat 2 hónap időtartamra korlátoztuk (1 hsz / 10 nap) a következő ok miatt: Az ÁSZF III 10/8. pontjának megsértése - trollkodás - miatt. Többször és többen is kértek már, hogy hozzászólás írásakor használd a linkelés funkciót, mert ennek elmaradása sokak számára zavaró.

Nyilván ekkora gyorsulásokat egy-egy program nem fog teljességében felmutatni, hiszen (ha jól értettem anno Fiery-t) csak egy-egy kódsor fut le ekkora plusz sebességgel a CPU-s eredményhez képest. Szóval ha eddig 1 perc volt egy program futása és ebből 20 másodpercet tett ki a gyorsított rész, akkor nyilván csak 42 másodpercre csökken a futási idő, ami azért messze nem általános 10x-es gyorsulás, függetlenül attól, hogy az adott szakasz 10x gyorsabban lefutott.

Ehhez kell hozzátenni, hogy még az AMD által kalapált képdekódoló (vagy mi volt az), amit a Kaveri kapcsán mutogattak is "csak" kétszeresére gyorsult HSA alapokra helyezve.

Programokat nem teljesen fair még várni erre egyébként, hiszen szerver/vállalati piacon még most nincs is HSA képes hardver, desktopon is csak 2 hónapja van és ott is induláskor jól le lett járatva. Erre nem lehet tömegével szoftvereket várni. Az Intel által nyomatott AVX-re sincs tudomásom szerint tömegével program, pedig van már alá mindkét oldalról hardver 2-3 éve.

A HSA-s JPEG dekódoló nagy része nem párhuzamosítható. Abból nehéz nagy gyorsulást elérni. Annak már van amúgy egy OpenCL verziója is, de csak a nem HSA-s APU-khoz. Persze az eléggé speciális kód.

Az AVX-szel nem érdemes a HSA-t hasonlítani. Az AVX hatékony kihasználása a legtöbb cég számára vállalhatatlanul nehéz, és nem fér bele erre költeni. Egyszerűbb HSA-t vagy ma még C++ AMP-t használni és az automatikusan használ AVX/AVX2-t, kiemelten hatékony autóvektorizálással. Annál kézi optimalizálással a gyakorlatban nem lehet 10%-nál nagyobb gyorsulást elérni.

Az AVX1/2 egyébként lényeges lesz, ahogy érkezik az OCL 2, az új C++AMP és a HSA runtime. Mindhárom nagyon jól tud kódot generálni rá. Sokkal jobban, mint az Intel gyári fordítója.

[ Szerkesztve ]

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

Nekem meg az nem vilagos, hogy szerveren sokszalu dolgok szoktak futni, ha ilyen hsa kod van minden szalon, akkor pontosan mi fog tortenni? Mert cpu eseteben eleg jol ki van talalva, de gpu eseten eleg komolyan szoktak akasztani egymast, egy szervernel ez katasztrofa.

Épp ezért rendelkezik a HSA runtime QoS-sel.
A Fedora elmondta, hogy a GPU mint megfogalmazás itt már rossz. Az IGP csak a nevében grafikus. Valójában pont olyan processzor, mint a Steamroller, csak más felépítésű, hogy bizonyos feladatokban sokkal hatékonyabb legyen. A mostani modellben az akadályozza a jó működést, hogy az IGP egy szolga. A HSA alapvetően azonos értékű erőforrásként tekint a CPU-ra és az IGP-re. Ez jelentősen növeli a rendszer használhatóságát.

[ Szerkesztve ]

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

Épp ezért rendelkezik a HSA runtime QoS-sel.

Az elmeletet ertem, a gyakorlat erdekelne. Mi tortenik a valosagban? Ha van egy szervered, ami sok klienst kell egyszerre kiszolgaljon erdemes-e ezekbe a kodokba hsa-t rakni vagy jobban jarnak a kliensek, ha nincs? Egy workstation jellegu mukodesnel vilagos, hogy erdemes, lehet tudni, hogy a usernek milyen scenarioban mire van szuksege, de egy szerver jellegu mukodesnel nincs ilyen. Oke, HSA szerint kell definialni quality of servicet, de hogy van implementalva ezen az apun? Milyen overheadje van egy context switchnek?

Az IGP csak a nevében grafikus.

Nincs az elnevezesnek jelentosege.

Sajnos a HSA runtime QoS részét nagyon titkolják az alapítványi tagok, mert ez leginkább egy szoftveres technológia, és itt nagyon sok "mágiát" dobtak be, hogy ez működjön. Ezt a részt főleg az ARM, a Codeplay, a Canonical, az Oracle és a MultiCore Ware fejlesztette.

A Fedora eddigi gyakorlati tapasztalatai szerint sokkal jobban járnak HSA-val a kliensek. Sokkal gyorsabban van válasz a lekérésekre.

A context switch főleg a hardvertől függ. GCN-en ez veszettül gyors. Ami nincs az a grafika preempció. Az valóban nem ideális ma, hogy egy szervertől egy kliens mondjuk OpenGL munkát kér, míg egy másik valami mást.

Alapvetően van jelentősége. Sokan gondolnak még grafikára az IGP-ről, pedig ezek semmivel nem butább processzorok, mint a CPU rész.

[ Szerkesztve ]

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

GCN-en ez veszettül gyors.

Van rola valami doksi? En azt tudtam, hogy egy gpu contexten belul x (pl. 2) kernel kozott gyors context switch van, de ez nyilvan nem ugyanaz, mint egy szervernel sok thread, sok context kozott.

Hat szamomra nincs jelentosege az elnevezesnek. GPU-nak hivtam, mire te irtad, hogy nem is GPU, nem is jo az IGP elnevezes se. Nekem mindegy, tolem hivjuk ahogy te akarod, csak ezen ne lovagoljunk.