Hirdetés
- Star Wars: The Old Republic - MMORPG
- Nintendo Switch
- Fortnite - Battle Royale & Save the World (PC, XO, PS4, Switch, Mobil)
- Elite: Dangerous
- Xbox Series X|S
- WoW avagy World of Warcraft -=MMORPG=-
- Úgy tűnik, hogy elkészült a S.T.A.L.K.E.R. 2 Heart of Chornobyl
- EAFC 25
- Call of Duty: Black Ops 6
- PlayStation 5
-
GAMEPOD.hu
OLVASD VÉGIG ALAPOSAN MIELŐTT ÚJ HOZZÁSZÓLÁST ÍRNÁL!!!
Új hozzászólás Aktív témák
-
#14152
Vitamincsiga
tag
dezz
#14126
Vitamincsiga
tag
Az APU CPU/IGP ALU/FPU/CU optimális arányát - legalább is azok a programok közül, amelyek képesek kihasználni ezt az architektúrát - tényleg csak a jövő fogja tudni megmondani...
Bár ahogy írod és én is eltöprengtem rajta, nem valószínű hogy lesz "optimális arány", még kiátlagolva sem. Főleg eleinte!
Inkább nagy szórás lesz az egyes gyártók termékei között az adott programra.Ami az Intelen hasítani fog, az az AMD-n vánszorog majd, vagy fordítva. Az ARM pedig sötét ló.
De majd meglátjuk!Jó lenne egy varázsgömb ;-)
-
#14154
Fiery
veterán
Vitamincsiga
#14153
Fiery
veterán
válasz
Vitamincsiga
#14153
üzenetére
Rendkivul specifikus kod kell ahhoz, hogy egy Kaveri le tudjon nyomni egy eros dGPU-t compute-ban. Az ilyen specifikus kodok pedig leginkabb olyanok lesznek, amiket eddig meg sem probaltak (d)GPU-ra portolni, tehat nem is lesz osszehasonlitasi alap igazandibol.
Az 1500 wattos tapok pedig az SLI/CrossFire konfigoknal jonnek jol, azoknak nem sok kozuk van ahhoz, hogy a CPU foglalat onmagaban mennyi aramot vesz fel. Egy 300W TDP-ju kepzeletbeli 1 utas APU-hoz is eleg lenne egy 5-600W koruli tap, amennyiben ugye nincs dGPU a rendszerben.
[ Szerkesztve ]
-
Vitamincsiga
tag
válasz
leviske
#14128
üzenetére
A 4 csatornás memóriavezérlővel kapcsolatban némileg visszakozom - ha lesz is, az csak az Intel hasonló terméke ellen fog kijönni; aranyáron.
A miért, az a Hynix-szel közös HBM memória fejlesztés. Tény és való, hogy az AMD innováció terén mérföldekkel mindenki előtt jár! Szerintem - rajtuk kívül - még most sem fogtuk fel igazán annak a döntésüknek a súlyát, ami az ATI felvásárlása jelentett. /HSA, Mantle, konzol APU-kstb.; nem tétlenkednek és jó kérdés, hogy mi van még a tarsolyukban, amiről nem tudunk semmit sem
/
Biztos lesz sokkal gyorsabb memória átvitel, de mikor és a hogyan még képlékeny.Hogy mi az optimális memória sávszélesség egy adott APU-t (ki)használó programnál?
Látod, én csak a CPUGPU arány firtatásáig jutottam el, de a te felvetéseddel teljes a kérdés!!
Mi az az APU konfiguráció, ami a legjobban lefedi a rá írt programok nagyobbik részét?!
Aki - gyártó - tudja, az kaszálni fog
A nagy "gémercégek" a PS4-ben is pár plusz CU-t láttak volna szívesen
Az elmúlt heti friss hír szerint az x86 és az ARM egyféleképpen történő házasítása a GNC-hez sok kérdésre egész más választ ad!
Lehet, hogy a Carizzo végállomás lesz, ami a csak a magas órajelre optimalizált magokat - modult - jelenti? /A modul elv ettől még reinkarnálódhat egy ALL-IN-ONE egységként, de az egy sokkal későbbi fejlesztés eredménye lehet./
Lehet, hogy egy kicsit magasabbról induló, jobban skálázható x86-os architektúrát akarnak? /Az ARM-os fejlesztés pedig kielégíti az alacsony fogyasztású cuccok követelményeit./ A csúcs konfigoknál pedig a látszólag kieső teljesítményt az alacsonyabb fogyasztás és a kisebb magméret miatt több maggal pótolják?A Carrizo és a Beema sínen van, a 32-28nm-en is lassacskán túljutnak; a teljesítmény pedig csak fog egyszer drasztikusan nőni már
Jó lenne egy varázsgömb ;-)
-
Vitamincsiga
tag
Ahol a PCI-E-en kell szaladgálni az adatoknak, ott egyértelmű a nyertes.
Meg ami még ma nem belátható, hogy a 4-8 GB dGPU memóriánál lényegesen nagyobb RAM - ha igényli a program - milyen változásokat fog hozni a programozástechnikában. Ahogy írtad, itt nem lehet összehasonlítási alap.Ami ma még kevésé látszik, hogy a dGPU-k korszakának lassan bealkonyul. /Az Intel lesz az egyik siettető; mert neki nincs.../
Az 1500W-os táp persze, hogy poén volt
Az 5-600W az általad említett 300 W-os TDP-jű APU-nak természetesen elég.Jó lenne egy varázsgömb ;-)
-
#14157
Fiery
veterán
Vitamincsiga
#14156
Fiery
veterán
válasz
Vitamincsiga
#14156
üzenetére
"Ahol a PCI-E-en kell szaladgálni az adatoknak, ott egyértelmű a nyertes."
Kozel sem egyertelmu. A PCI-E savszelessege es kesleltetese nem annyira rossz, mint sokan gondoljak. Raadasul, amint az on-board memoriaba atmasolasra kerult az adat, ott adott esetben sokkal gyorsabban elerhetoek az adatok a compute feladat kozben, mint ha a rendszermemoriabol kellene oket kezelni. Tedd csak egymas mellé a Kaveri es a Hawaii XT memoria savszelesseget
Plusz, ha az on-board memoriaban vannak az adatok, a szamitassal sokkal gyorsabban vegezhet egy dGPU, mint egy APU, es ez a trend me'g par evig fenn fog maradni.Sokkal lenyegesebb az, hogy egy adott feladatot mennyire konnyu portolni GPU-ra, legyen szo dGPU-rol vagy SVM-kepes APU-rol. Ha a portolas nehez, de mar bevallalta valaki dGPU-ra, akkor egy SVM-es APU-val nem fogsz tudni tul sokat nyerni. Ha a portolas nehez, es nem is vallaltak be dGPU-ra, es a portolas lenyegesen konnyebb egy SVM-es APU-ra, akkor meg nem lesz osszehasonlitasi alap, ha dGPU-ra nem is portoljak
"a dGPU-k korszakának lassan bealkonyul. /Az Intel lesz az egyik siettető; mert neki nincs.../"
Nincs bizony, de lesz helyette jobb, ld. Knights Landing
En inkabb ugy mondanam, hogy a GPU korszaknak lesz lassan vege, es onnantol teljesen relevanciajat veszti nehany ceg, koztuk az AMD es az nVIDIA is, ha nem vigyaznak. Szerencsere ezeket az cegeket nem kell felteni, idejeben lepni fognak.[ Szerkesztve ]
-
#14158
stratova
veterán
Vitamincsiga
#14155
stratova
veterán
válasz
Vitamincsiga
#14155
üzenetére
A 4 csatornás memóriavezérlővel kapcsolatban némileg visszakozom - ha lesz is, az csak az Intel hasonló terméke ellen fog kijönni; aranyáron.
A jelenlegi terveikben nem szerepel a 2/4P vonal frissítése, ami a 4 csatornás memóriát igényelné.
Ahol sok szál kiszolgálása a cél, oda Dense szerverekkel neveznek (erre van nekik a Freedom Fabirc a SeaMicro-tól).
HP ProLiant Moonshot 1500 (IGP-s Opteron X2150)
Seamicro SM15000 (AMD oldalon egyelőre IGP nélküli megoldás Opteron 4365EE)
Lehet, hogy a Carizzo végállomás lesz, ami a csak a magas órajelre optimalizált magokat - modult - jelenti?
EETimes szerint Puma+t szánják Kaveri közeli órajelre.
A csúcs konfigoknál pedig a látszólag kieső teljesítményt az alacsonyabb fogyasztás és a kisebb magméret miatt több maggal pótolják?
Ha csúcs konfigok alatt a HPC-t érted arra most nem nagyon van ütőképes alternatívájuk. Asztali vonalon A10 GPU-ját akarják bevonni ALU-igényes feladatok elvégzésére, ehhez viszont Mantle vagy Dx12 kell.
Erről volt helyi cikk, de most nem lelem. -
dezz
nagyúr
A szaladgáláson szerintem azt értette, hogy többször utazik ide-oda az adat, ilyenkor már nagyon is számít a PCIe késleltetése és sávszéle, amik persze nagyságrendekkel rosszabbak, mint akár a main ramhoz való hozzáférésé.
Utolsó bekezdésre: ahogy az Itanium is lesöpört mindenkit a Föld színéről?
-
Fiery
veterán
A tobbszori ide-oda utaztatas sem problema, ha a compute feladatot annyival gyorsabban oldja meg a dGPU. Nyilvan osszessegeben me'g igy is jobb lehet egy APU, ha a fogyasztas/teljesitmeny mutatot nezzuk. Tobb masolgatas de gyorsabb szamitas vs. nincs masolgatas de lassabb szamitas vegeredmenyben kilyukadhat ugyanahhoz az osszteljesitmenyhez is, csak kozben egy high-end GPU zabalja az aramot.
Az Itaniumot nemtom miert kell iderangatni. Ott pont az x86-ot akarta felvaltani az Intel es nem jott ossze. A KNL pedig pont az x86-tal akarja felvaltani a nyomoronc GPU-kat. Terjunk vissza a GPU-s dolgokra mondjuk 6 ev mulva. Barmennyiben le mernem fogadni, hogy addigra a PC-kben mar nem lesz semmilyen GPU, vagy legalabbis marginalis feladatra fognak visszaszorulni. A CPU fog mindent intezni, legyen szo ARM vagy x86 utasitaskeszletrol.
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
Túl nehéz az Intel koncepciójának hatékony programozása, hogy használható legyen a tömegpiac számára. A GPU-k különösen a SIMT rendszerűek nagyságrendekkel könnyebben programozhatók.
Andrew Richards többször mondta (és ő volt a Larrabee/MIC koncepció szoftveres vezéralakja), hogy az architektúra működhet, de csak akkor használható ki, ha a programozó úgy írja meg a kódot, hogy fixen 16 utasításonként mindig legyen egy scatter vagy gather operáció. Mindent ennek kell alárendelni, és ha ez nem teljesül, akkor a kihasználhatóság drámaian lecsökken. Ez pedig azért van, mert az eredetileg egy szálra tervezett memóriamodell működése túlságosan kötött ahhoz, hogy az efféle masszív párhuzamosságra tervezett rendszernél működjön a ma jellemző 3-4 utasításonkénti scatter/gather mellett.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Fiery
veterán
Igen, mert a HSA sokkal egyszerubb
Papiron, talan. Csak epp a problema az, hogy mig egy monolitikus sok-sok (72+) magos, sok-sok (288+) threades CPU-t tudsz HSA/OpenCL-lel _is_ programozni meg direktben (x86 + AVX-512) is, addig a GPU-knal marad a HSA/OpenCL, es kesz. Ha nem mukodik eleg jol, mert az adott gyarto (pl. AMD) sz*r implementaciot keszit (ha keszit egyaltalan), akkor megsutheted a vasat. Ez a legnagyobb problema mind a mai napig: az AMD jo vasat (GPU) keszit, csak nincs meg hozza a megfelelo, kiforrott, korrekt software stack. Anelkul meg nincs semmi. A kutya nem fog direktben GCN assemblyben programozni AMD GPU-t -- mig arra sokkal tobb esely van, hogy valaki, a szamara mar amugy is ismeros x86 assemblyt beveti mondjuk egy KNL-en.Arrol nem is beszelve, hogy me'g mindig nem ertem, miert kell ugyanazt a lemezt felrakni. Oke, volt/van egy MIC, ami nem mukodik igazan hatekonyan. De ki mondta, hogy ugyanez a koncepcio lesz a Skylake-ben vagy a KNL-ben? Ki mondta, hogy a near memory vagy egyeb trukkok (amit me'g nem ismerunk, pl. Skylake-rol szinte zero info van jelenleg) nem tudjak ellensulyozni azt, ami jelenleg problema a MIC kapcsan? A GCN persze tok jo, csak azt meg senki se tudja leprogramozni, mert nincs hozza normalis software stack. Mit er egy jo vas, ha nem tudsz vele mit csinalni?
Az meg plane szuklatokoru hozzaallasra utal, ha azert ignore-alod Te vagy mas az Intel "GPU" terveit, mert volt egy rossz koncepcio, egy-ket evolucios zsakutca (pl. MIC vagy IA-64) az Intel tortenelmeben. Anno mindenki kesz tenynek vette, hogy a K8 az istencsaszar es a NetBurst meg f*s, aztan lattuk mi lett abbol is. Az Intel evekig erolteti (talan feleslegesen), de vegul kepes kukaba dobni egy koncepciot, ha van helyette egy jobb megoldas. A NetBurst is ment a levesbe, mert volt Conroe helyette, ami jobb volt. Ha a MIC a gyakorlatban (KNL) nem mukodik eleg jol, majd lesz helyette mas. Az x86-ra mar 10 eve es 20 eves is azt mondtak sokan, hogy zsakutca, aztan milyen fura, hogy me'g mindig itt van velunk, es felfele mindent lesoport (az IA-64-gyel egyutt), lefele meg az ARM-ot szorongatja jelenleg. Ha pedig az x86 vegkepp nem valik be a compute temaban, akkor hosszutavon siman eldobhatja azt is az Intel, es lesz helyette mas. Anno az IA-64-gyel is ez volt a terv, abbol is lehetett volna adott esetben x86 utani architektura...
Amiben en maximalisan nagy fantaziat latok, az -- es most tegyuk zarojelbe az x86-ot mint architekturat, nem az itt a lenyeg -- a GPU felvaltasa egy olyan sokmagos processzorral, ami mindent hazon belul megold. Ha kell, altalanos feladatokra is hasznalhato remekul (mint most az x86 CPU magok), ha pedig az kell, akkor a compute-ot is gyorsan vegrehajtja.
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
A HSA csak egy vISA és egy egységes QL koncepció. Az csak arra van, hogy egyszerű legyen a programozás. A hatékonyság a hardverből jön.
Az Intel terve nem zsákutca. Más sem készít más felépítésű GPU-kat, mint a Larrabee/MIC/KNL. A különbség, hogy más ehhez tervezi az ISA-t, ami képes fenntartani a skálázható teljesítményt. A GCN rengeteg feladatban dettó ugyanúgy működik, mint az x86, csak az ISA memóriamodellje úgy van tervezve, hogy a lapkán belül 30ezer konkurens szál is futhat skálázási probléma nélkül. Az x86-ot eredetileg egy szálra tervezték.
Olyan architektúra nem lesz. A gond az, hogy a hatékonyságot nagyban befolyásolja az ISA. Vannak serial, task- és data-parallel feladatok. Nincs olyan univerzális rendszer, ami ezeket lefedi, így kell serial és parallel ISA is a hardverbe.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Még annyi, hogy a fejlesztők itt nem fognak alacsony szintű nyelvekkel szívni. Megírják C/C++-ban, Javában, stb. A HSA runtime majd mindenkinek fordít kódot. Az Intelnek például AVX/AVX2-t, de AVX3.x-et is fog később. Messze ez a legegyszerűbb a tömegpiac számára. Ráadásul a szabványosított runtime miatt garantált, hogy mindenkinél fut, és gyakorlatilag SSE2-ig visszamenőleg lesz finalizer.
Ezzel a koncepcióval egyetlen forrásból lefedik a 2005 után megjelent PC-ket, és ugyanazt a forrást vihetik mobilba, Linuxra, stb.
Sokan kötik össze a HSA-t a GPU-kkal, de valójában ez inkább egy olyan koncepció, ami csak annyit tesz, hogy egy forrásból kiszolgáld a temérdek platformot. Minden ami a gyorsítást végzi az csak extra.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
dezz
nagyúr
Egyébként hogy néz ki a HSA szoftver oldalról? Lesz valamilyen (saját) OpenCL alternatíva?
"ignore-alod"
Már írtam korábban, hogy ezt felesleges így írni, rendes szótári szó az ignorál.
"Anno az IA-64-gyel is ez volt a terv, abbol is lehetett volna adott esetben x86 utani architektura..."
Mint tudjuk, nem a véletlenen múlt, hogy végül nem lett az - pedig az Intel váltig hitt benne. Csak azért hoztam fel példának, hogy az Intel sem tévedhetetlen. Lehetne más példákat is mondani.
"Amiben en maximalisan nagy fantaziat latok, az -- es most tegyuk zarojelbe az x86-ot mint architekturat, nem az itt a lenyeg -- a GPU felvaltasa egy olyan sokmagos processzorral, ami mindent hazon belul megold. Ha kell, altalanos feladatokra is hasznalhato remekul (mint most az x86 CPU magok), ha pedig az kell, akkor a compute-ot is gyorsan vegrehajtja."
Rendre kihagyod a képletből a fogyasztást és a helyigényt: egy CPU jóval több tranyóból hozza ki ugyanazt a számítási teljesítményt. Az Intel jelenleg a gyártástechnológiai előnyében bízik, de nem biztos, hogy az még sokáig fennmarad.
(#14163) Abu85: "A GCN rengeteg feladatban dettó ugyanúgy működik, mint az x86"
Ezt kifejtenéd, mert én speciel eléggé másmilyennek látom.
"csak az ISA memóriamodellje úgy van tervezve, hogy a lapkán belül 30ezer konkurens szál is futhat skálázási probléma nélkül. Az x86-ot eredetileg egy szálra tervezték."
Meg a GPU szinte teljes belső felépítése, ami lehetővé teszi ezt a 30 ezer szálat...
(#14164): Ja, akkor ugye nem lesz (saját) OpenCL alternatíva, csak a HSA keretrenszer lehetővé teszi, hogy C/C++/Javában is lehessen compute feladatokat leprogramozni. Illetve, ott van még a MS-féle C++ AMP.
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
Az x86/AMD64-ben van full 32 bit UINT/INT támogatás. A GCN ezt átmentette, és lényegében ugyanazokat az integer matematikai trükköket teszi lehetővé, amiket a fejlesztők alkalmaznak a CPU-kon.
Persze van amiben eltér a GCN, de a dizájnja sokkal inkább hasonlít egy CPU-ra, mint egy hagyományos GPU-ra. Nagyon sok PS3 fejlesztő mondogatja az előadásán, hogy ami működött a Cellen az most működik GCN-en is, csak sokkal gyorsabban.Igaz a szálkommunikációt nagyon hatékonyan kell megoldani, de a fő előny a memóriamodellből jön. Amikor ISA-t cserélnek a cégek, akkor főleg ehhez nyúlnak hozzá.
Nem lesz. A HSA az OpenCL kiegészítése lehet és nem leváltója, ugyanígy egészíti ki a C++AMP-t is.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Fiery
veterán
"Egyébként hogy néz ki a HSA szoftver oldalról? Lesz valamilyen (saját) OpenCL alternatíva?"
Nem ertem, mit akarsz irni. A HSA nem egyenlo OpenCL-lel. Az OpenCL-nek meg miert kellene alternativat kesziteni? Teljesen jo cucc, amennyiben jo compilert ir hozza az adott gyarto. Az AMD compilere jelenleg f*s, az Intele meg hig f*s. Amig ez a helyzet nem valtozik, addig a fejlesztok nem fognak komolyabban foglalkozni a kerdessel. Ha pl. egy Visual C++ vagy gcc mellé teszel egy AMD vagy Intel OpenCL implementaciot, akkor jol latszik, hogy az egyik egy kiforrott kornyezet, kiforrott, lenyegeben hibatlan compilerrel, amihez sokfele jol bevalt, ismert tool is elerheto (debuggolas, profilozas). Ezzel szemben az OpenCL alapu fejleszteshez nincs rendes, egyseges fejleszto kornyezet, nem lehet rendesen debuggolni es profilozni, nem jol mukodnek a compilerek. Gyakorlatilag sz*pas az egesz. Nyilvan az SVM sokat konnyit azon, hogy az egesz GPU-s mizeriat konnyebben ki tudd hasznalni. Azzal legalabb az adatmasolgatast el tudod kerulni, kicsit konnyebben atlathatova tudod tenni a komplexebb feladatokat (foleg a lancolt listaknal jon jol az SVM). Viszont, a compiler ugyanugy problema marad, a debuggolas es profilozas ugyanugy megoldhatatlan a jelenlegi eszkozokkel. Es a legfobb problema: tovabbra is koprocesszorkent kezeled a GPU-t, holott annak mar reg a CPU reszenek kellene lennie. Engem mint fejlesztot szemely szerint nem erdekel se az ISA, se a threadek szama, se az egysegnyi tranzisztorra juto fogyasztas. Nekem egy olyan CPU kellene, amivel a mostani CPU-k es a GPU-k teljesitmenyet egy tokban tudnam latni, es a jol megszokott eszkokkel lehetne fejleszteni ra, a debuggolassal es a profilozassal egyetemben. Az Intel-fele KNL megkozelitesnel azt erzem, hogy az Intel is ebbe az iranyba szeretne menni, mig az AMD-nel azt erzem, hogy 3-4 kulonfele iranyba mennek, es egyik platformra, egyik megoldasra se tudnak letenni kiforrott, teljes erteku fejleszto eszkozt. Nincs tovabbra sem jo OpenCL compileruk, nincs mukodo HSA implementaciojuk -- de kozben nyomjak az x86-ot, nyomjak a GCN-t, nyomjak a konzolokat, nyomjak mar az ARM-ot is. Ertem en, hogy sok labon akarnak allni, meg ok sem latjak igazan, hogy melyik vonalbol lesz a jovo, de a jelen allas szerint mekkmester lesz beloluk. Mindenbe beleszagolnak, mindenre azt mondjak, hogy van kesz megoldasuk ra, csak kozben az sosem lesz igazan kesz, igazan jol hasznalhato. Felolem csinalhatnak azt is, hogy a GCN-bol keszitenek egy CPU-t -- ugyis szeretik hangoztatni, hogy a GCN tulajdonkeppen most mar egy teljes erteku processzor, ennyi erovel OS-t is be lehetne bootolni rajta. Nosza, akkor legyen az, csinaljanak egy ilyen megoldast, felejtsek el az x86-ot, ugysem az a fokusz mar naluk. Az Intelben azt dijazom, hogy legalabb kiallnak egy adott platform (x86) mellett, azt nyomjak, azt eroltetik, arra fokuszalnak. Lehet, hogy a vegen besz*pjak, es az ARM meg a HSA lesz a tuti megoldas, de legalabb nem 50 fele iranyban kapaloznak, es a vegen a delivery vagy kesik vagy meg sem tortenik normalisan.
-
Abu85
HÁZIGAZDA
Ezért értékes annyira a HSA a fejlesztőknek. Ott nincsen több gyártói implementáció. Egy lesz, amit HSA alapítvány biztosít. Erre lesz a runtime, amit szintén a HSA alapítvány biztosít. Egyedül a finalizer térhet el, de akkor már nem lehet hibázni, hiszen a kód lefordult.
Nincs többféle irány az AMD-nél. Az x86, az ARM csak a serial ISA. Az ARM azért fontos, mert egy csomó szerverpiaci szereplő ARM-ot akar. Nem azért mert az x86 nem jó, hanem mert saját hardvert akarnak. Az AMD lepattanókat akar, hogy ha nincs erre erőforrása a cégnek, akkor megtervezik nekik a hardvert (semi-custom).
Konzolokon nem HSA van? Való igaz, hogy azokra az AMD és nem a HSA alapítvány tervezi az implementációt, de amit megírsz rájuk hozhatod át helyből HSA-ra.
Minden a HSA-ban fut össze.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A GCN-re egyébként sosem lesz semmi megírva natívan. Nagyon egyszerű, hogy miért. A parallel ISA-kat le kell cserélni minden 5. vagy 7. évben. Ezt nem azért teszik meg, mert olyan szuper dolog erre pénzt költeni, hanem azért, mert minden GPU ISA határok közé van szabva. A működése úgy van megtervezve, hogy minimum x ezer és y ezer szál között működjön jól. Ha alulról vagy felülről ettől eltérsz, akkor drámaian csökken a teljesítménye. Mivel fejlődünk, így 5-7 évente elérjük azt a szintet, amikor már az új GPU-ba több szál kellene, mint amennyit az ISA hatékonyan elbír. Ilyenkor jön az új ISA, ami új határokat teremt. Csinálhatnak a GCN-re bármikor C/C++ fordítót, csak azok a programok, amiket ma lefordítanak rá nem fognak futni 2017 körül, amikor a GCN helyére jön egy új architektúra.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Fiery
veterán
"Ott nincsen több gyártói implementáció."
Hogy a fenebe ne lenne?! A HSAIL kodot valahogy at kell forditani az aktualis CPU vagy GPU sajat ISA-jara.
"Egyedül a finalizer térhet el, de akkor már nem lehet hibázni, hiszen a kód lefordult."
Hogy a fenebe ne lehetne hibazni? A kod nem fordult le, a HSAIL-t me'g at kell forditani egyszer. Gazdagon van abban is hibalehetoseg. Hivhatod finalizernek, compilernek, barminek, attol me'g van egy forditasi lepcso, ami gyartonkent eltero es el lehet **szni egyenileg maskepp es mas mertekben.
Amugy meg, lesz HSA-hoz debugger es profiler? Nem lesz, mert az gyarto-specifikus lenne, hiszen vastagon az ISA szintjere kellene lemenni. Az AMD fejleszt ilyesmit? Ketlem, naluk mar az OpenCL rendkivul buta, egyszeru beepitett profilozoja is bugos. Vagy a Qualcomm, vagy a Samsung fejleszt ilyesmit?
"Nincs többféle irány az AMD-nél. Az x86, az ARM csak a serial ISA."
Nincs tobbfele irany, de csak a serial ISA-ra irsz 2-t
Furcsa dolgok ezek."Az ARM azért fontos, mert egy csomó szerverpiaci szereplő ARM-ot akar."
Talan meg kene oket gyozni egy utokepes x86 megoldassal, es nem lenne gond. Ha igy folytatja az AMD, lesz egy kozepszeru vagy annal sz*rabb x86 core-ja, meg egy hasonlokepp kimagaslo ARM core-ja is. Ha ez nekik igy jo...
"Minden a HSA-ban fut össze."
Marmint az AMD lazalmaiban legfeljebb
Mert amugy en nem latom a mozgolodast az Intelnel, nem latom az nVIDIA-nal, nem latom a Google-nal (Android) sem, de me'g a Microsoft sem tulzottan kardoskodik a HSA mellett. Egyedul az AMD nyomja, meg van nehany tamogato (Samsung, Qualcomm, VIA, stb), amik meg vagy csinalnak valamit, vagy nem, de leginkabb nem, mert mindenki csak var-var-var. Sz'al a nagy nulla fut ossze a HSA-ban, ami egyelore egy hatalmas nagy nulla, es nem latszik, hogy mikor lesz belole barmi is. -
Fiery
veterán
Ha a regebben leforditott programok ennyire nagy problemat jelentenek, es ennyire problema lecserelni X evente az ISA-t, akkor mi van az ARM vs. x86 kerdessel, az AMD-nel? Ott nem gond, hogy nem mukodnek ARM-on a legacy x86 szoftverek? Megjegyzem, ahhoz, hogy a HSA-t, az OpenCL 1.x-et vagy epp a Mantle-t ki tudd hasznalni, ahhoz teljesen uj szoftvereket kell kesziteni, tehat mar ott uj szoftverre van szukseg. Miben kulonbozik ez attol, mint ha a most megirt x86 szoftvereket 7 ev mulva ujra kellene irni? Egy 7 evvel ezelott irt x86 szoftver sem fog raszagolni sem egy GCN GPU-ra manapsag. Miert fontos akkor az, hogy ha most irnank egy nativ GCN szoftvert, akkor az nem futna a GCN utani generacion, 2021-ben? Ha ennyire fontos az ISA-hoz ragaszkodas, akkor az x86 a kiraly
![;]](//cdn.rios.hu/dl/s/v1.gif)
De a mai vilagban pont nem azt latom, hogy az ISA-hoz valo ragaszkodas lenne a legfobb kerdes, plane a mobil es ultramobil vonalon.[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
Nem tudom mennyire beszélsz ezekről a gyártókkal, de a legtöbb hiba nem a vISA->fizikai ISA fordításból ered. Itt szinte soha nincs probléma. Maximum a kezdetekben, de annyira low-level a fordítási szint, hogy a termék megjelenéséig javítják. A fordítási hibák zöme a programnyelv valamilyen formátumából a vISA-ra való fordításban van. Mivel a HSA-nál a vISA közös és a fordító mindenkinél ugyanaz, így vagy mindenkinél hiba lesz, vagy senkinél. De leginkább az utóbbi.
A finalizer lényegében csak annyi, hogy a vISA utasításait direkten cserélje le a fizikai ISA megegyező utasításaival. Itt ma sem hibázik senki, pedig a HSAIL-nél sokkal elavultabb IL-eket használnak a cégek.
Lesznek külön toolok, de a gyártók ezeket is szabványosítják.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
dezz
nagyúr
"Az x86/AMD64-ben van full 32 bit UINT/INT támogatás. A GCN ezt átmentette, és lényegében ugyanazokat az integer matematikai trükköket teszi lehetővé, amiket a fejlesztők alkalmaznak a CPU-kon."
Az jó, de ez még csak egy kisebb része az egésznek. Nem vitatom, hogy közelebb állnak, mint akorábban, de egy GCN CU így is eléggé más, mint egy normál CPU mag (kevesebb benne a "sallang", sokkal inkább párhuzamosított végrehajtásra optimalizált, mintsem skalárra), és az egész GCN alapú GPU is eléggé más, mint az Intel many-core CPU koncepciója (más a buszrendszer, kevésbé önállóak a CU-k, viszont külön egységek vannak az igazgatásukra).
Az Intel egy univerzális magokat akar, az AMD viszont úgy gondolja, a CPU jobb skaláris számításokra, a GPU pedig párhuzamosra. És ugyebár van egy olyan mondás, hogy ami mindenre jó, az semmire sem jó igazán. Mint írtam, ezt az Intel a gyártástechnológiai előnyével próbálja ellensúlyozni, csak kérdés, ez meddig sikerülhet.
(#14167) Fiery: Még ha nem is lesz valamilyen kimondott OpenCL alternatíva, később az is egyfajta alternatívát fog jelenteni, hogy C/C++/Javában is le lehet majd programozni ugyanazt. A Java részévé fog válni a párhuzamosítás.
"Engem mint fejlesztot szemely szerint nem erdekel se az ISA, se a threadek szama, se az egysegnyi tranzisztorra juto fogyasztas."
Ez így azért eléggé leszűkített látómező. Egy dolog, hogy mi lenne kényelmes a fejlesztőknek (a legjobb egy több THz-es CPU lenne) és egy másik dolog, hogy a fizikai törvények mit hagynak megvalósítani, jelenleg szilícium alapon. Egy a jövőről folyó eszmecseréből ez nem hagyható ki.
"Az Intelben azt dijazom, hogy legalabb kiallnak egy adott platform (x86) mellett, azt nyomjak, azt eroltetik, arra fokuszalnak."
Még jó, hogy ezt próbálják nyomni, ez a legfőbb ütőkártyájuk.
Az előzőből kimaradt: "lefele meg az ARM-ot szorongatja"
Ez vicces, inkább talán az ARM szorongatja őket alulról (úgy is mondhatnám, a töküket).
-
Fiery
veterán
Miert kellene, hogy megegyezzen a HSAIL utasitaskeszlete mondjuk a GCN utasitaskeszletevel? Vagy ha "teljesen veletlenul" megegyezik, azaz van direkt megfeleloje minden HSAIL utasitasnak, akkor mi a biztositek arra, hogy ez ugyanigy fog mukodni a GCN utani AMD ISA-nal, vagy mondjuk a Qualcomm vagy a Samsung sajat ISA-janal? Vagy mondjuk az x86-nal? Hiszen a HSA-nak mukodnie kene x86 CPU-kon is, vagy barmilyen x86 alapu GPU-n is.
"Lesznek külön toolok, de a gyártók ezeket is szabványosítják"
Hogyan fogjak szabvanyositani? Milyen toolok? Ki fogja kesziteni a toolokat? Konkretumokat kerek, nem papiron letezo igereteket.
-
Abu85
HÁZIGAZDA
Más dolog a parallel ISA és a serial ISA. Utóbbira nem építesz olyan hardvert, amin belül minimum 2048, de esetleg 45056 szál fut (a GCN adatait tetszőlegesen lehet cserélni másra, itt a sok szál a lényeg). Az AMD64/ARMv8 nagyjából 80-100 szálig bírja. Utána brutális cache kell, ami nem helytakarékos, és nincs jó hatással a fogyasztásra. A parallel ISA azért hoz meg olyan koncepciós döntéseket a szálak futtatására vonatkozóan, hogy mondjuk 45056 szál mellett is elég legyen 1 MB-os gyorsítótár.
Új szoftverek minden újdonsághoz kellenek, de feltétlenül muszáj lekorlátozni a szoftver élettartamát? Miben lesz rosszabb, ha például a C++ programod HSA-ra fordítod és nem natívan GCN-re? Talán abban, hogy futni fog más ISA-n is? Tényleg nem értem, hogy ezzel mi a gond.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A HSAIL-t szándékosan rendkívül egyszerűre tervezték. Mindössze 136 utasítás az egész, és ezek is úgy vannak kialakítva, hogy az alapítványban résztvevő gyártók mindegyik virtuális utasítást ki tudják váltani egy fizikaival. Még az Intelt és az NVIDIA-t is belevették, ha később be akarnak lépni. A későbbi architektúrák nem túl lényegesek, mert azokat lehet vISA-hoz tervezni. Évek óta megteszi ezt mindenki, hiszen minden GPU ISA egy gyártóspecifikus vISA mögött van elrejtve. Most annyi változik, hogy a vISA szabványos lesz, így lecseréli a gyártóspecifikus opciót.
A HSA alapítvány csinál minden szabványosítást. A toolokat főleg az AMD és az ARM csinálja. A Samsung a teszteket dolgozza ki. Igazából mindenkinek megvan a maga feladata. Elsősorban úgy, hogy mihez értenek leginkább.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Fiery
veterán
"Ez így azért eléggé leszűkített látómező."
Teny, de a fejlesztoket hidd el, hogy az erdekli elsosorban, hogy mikepp tudod megoldani a feladatot, es a hibakeresest, teljesitmeny optimalizaciot hogyan tudod vegezni. Az OpenCL pedig jelenleg nagyjabol pont ezen a 2 teruleten kalap sz*r. A HSA az igeri, hogy majd jobb lesz ezeken a teruleteken is, csak epp nem latni egyelore, hogy milyen konkret lepeseket fognak tenni. Egy C++-hoz es CPU-hoz (leginkabb x86 CPU-hoz) szokott fejleszto szamara az OpenCL jelenleg egy fekete lyuk, amibe belevagod a vegrehajtando feladatot, es aztan a vegen valami kijon. Hihetetlenul nincs sem ralatasod, sem rahatasod arra, hogy mikepp hajtja vegre a GPU az adott OpenCL kernelt, es hogy a vegeredmeny valojaban helyes-e vagy sem. Ha van otleted, hogy mitol lehetne gyorsabb a cucc, akkor elkezdesz probalgatni kulonfele technikakat (pl. unroll, inline, ilyesmi), amire aztan a kulonfele GPU architekturak a kulonfele compilerekkel teljesen maskepp reagalnak. Ami fekszik az egyiknek (pl. GCN), az a masikat lassitja (pl. Kepler). Az pedig kesz rohej, amikor kenytelen vagy tobbfele GPU architekturat tobbfele driver verzioval is tesztelni, mert az egyebkent helyes OpenCL kod hibas eredmenyt ad az egyik kombinacion (pl. AMD VLIW + Catalyst 14.x). Aminek az okara, gyokerere megint nincs se ralatasod, se rahatasod, kenytelen vagy az AMD-t molesztalni, hogy javitsak vegre a rohadt driveruket. Amit persze 5 honapon belul nem tudnak megoldani, es kidobjak WHQL minosites alatt a bugos OpenCL compilert. Ez a jovo? Tenyleg?
"Még jó, hogy ezt próbálják nyomni, ez a legfőbb ütőkártyájuk."
Nyilvan, de ha az AMD-nek meg ott a szuper GCN -- mert hardveres szempontbol tenyleg qrvajo --, akkor miert nem azt nyomjak, hanem minden egyebet, amiben nem eleg jok? x86, ARM, szoftver fejlesztes (= HSA es tarsaikhoz valo szoftver stack).
"Ez vicces, inkább talán az ARM szorongatja őket alulról (úgy is mondhatnám, a töküket)."
Nezz vissza az elso Atomig. Akkor hol allt az Intel az ARM konkurensekkel szemben, es hol all most. Eg es fold a kulonbseg. Az elso iPhone megjelenesekor me'g fel sem merulhetett, hogy Intel SoC keruljon egy mobiltelefonba. Az elso iPad megjelenesekor szinten szoba sem johetett volna egy Intel SoC az ARM helyett. Mostanra pedig mar lenyegeben azonos teljesitmenyt es fogyaszast tudsz elerni Intel es ARM SoC-okkal is. Ha ezt kicsit tovabbgondolod (vagyis hogy 7 ev alatt mennyit fejlodott ebben a szegmensben az Intel), akkor eleg egyertelmu, hogy ki kinek a tökét szorongatja kozeljovoben. Mar csak azert is, mert az ARM nem egy egyseges, vertikalisan integralt CPU-gyarto, hanem egy rendkivul toredezett "valami", sokfele architekturaval, sokfele ceggel, akik raadasul sok esetben egymas konkurensei vagy epp ellensegei. Az ARMv8 remekul probalja osszefogni, gatyaba razni, modernizalni az ARM vonalat, rendkivul erdekes lesz a kovetkezo 2-3 ev...
-
Fiery
veterán
Az, hogy egy adott architektura hany szalat kezel, az valahol teljesen mindegy. Ennyi erovel azt is feszegethetnenk, hogy melyik hany MHz-re skalazhato, az is teljesen mindegy. A lenyeg, hogy egy adott feladatot, pl. egy bazinagy adathalmaz AES-256 kriptalasat melyik architektura milyen gyorsan oldja meg. Ha ehhez mondjuk egy Hawaiinak 10000 szalat kell inditania, akkor annyi. Ha ugyanazt a feladatot azonos sebesseggel megoldja egy KNL mondjuk, de eleg neki 288 szal hozza, akkor nem tokmindegy, hogy hany szalig skalazodik az adott ISA?
"Miben lesz rosszabb, ha például a C++ programod HSA-ra fordítod és nem natívan GCN-re? Talán abban, hogy futni fog más ISA-n is? Tényleg nem értem, hogy ezzel mi a gond."
Elvben tok jo. Gyakorlatban vannak vele problemak, mint ahogy irtam is. De mindegy, hagyjuk, nem egy dologrol es nem egy problemakorrol beszelunk.
-
Abu85
HÁZIGAZDA
Félreértettük egymást. Igen igaz amit írsz. A GPU az valahol csak GPU. Sok szálra optimalizált, szörnyen sok regiszterrel, stb. Az x86(AVX)/ARMv8 ehhez képest valóban egy baromira regiszterszegény architektúra, kevés szálas működésre optimalizálva.
Egyelőre én még nem látom tisztán, hogy az Intel mit akar. A koncepcióikból kihozható egy olyan Skylake, amiben van négy nagyobb mag, amellett van kb. 12-16 MIC mag és még amellett van egy Gen9 IGP. Ez a lehetőségeket figyelembe véve egy reális opció.
(#14178) Fiery: A hatékony szálkezelés a hatékony skálázhatóság alapja.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Fiery
veterán
"A hatékony szálkezelés a hatékony skálázhatóság alapja"
Es kevesebb szalat nem konnyebb kezelni?
Miert kene egy adott feladatra sok szalat radobni, ha keves szal is gyors tud lenni? Plusz, ki mondta hogy a jovobeni, adott esetben x86 alapu Intel "GPU"-k csak negyszeres HyperThreadinggel fognak uzemelni? Miert ne lehetne 16x vagy 32x? Akkor mindjart tobb ezer szalrol beszelunk Tudom, sok-sok regiszter kell hozza, de hely van, legalabbis ha az Intel a 10 nanot is tudja hozni idoben...[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
Ez attól függ, hogy milyen architektúráról beszélünk. Például a SIMT modellnél nem kell foglalkoznod a szálakkal.
Ez nem olyan, hogy a mérnök eldönti, hogy a következő generációba 200 szál helyet 20000-et épít. Ahhoz előbb új ISA kell, mert a szálak közötti kommunikáció és a memóriamodell meghatározza, hogy effektíve mennyi szálat érdemes futtatni a hardverben. Akkor jó a data-parallel hardver, ha a beépített feldolgozókon pont az a mennyiségű szál fut, ami a hatékonysághoz szükséges és ezek a szálak is hatékonyan tudnak dolgozni egymás mellett, mert az ISA memória- és szinkronizációs modellje kellően kidolgozott ahhoz, hogy megbirkózzon a feladattal. Ha bármelyik eshetőség nem stimmel, akkor építheted be a millió szálat, a millió magot, a millió regisztert, de a hardver 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.
-
dezz
nagyúr
Oké, de a fizikai törvényeket (már ami a szilíciumra vonatkozik) ők sem tudják felülírni. Ezt a felvetést elintézted annyival, hogy "Tény." Aztán írsz egy panaszáradatot, mintha a szöveg mennyisége döntené el a kérdést.
Pedig hát nem."Ez a jovo? Tenyleg?"
Úgy néz ki, legalábbis amíg le nem cserélik a szilíciumot. De előbb-utóbb más technikánál is előjön a kérdés. A többmagúsítás sem nyerte el mindenki tetszését, de hát ugye eszi, nem eszi, nem kap mást.
Azt meg lehet érteni, hogy nem akarják kiadni a szoftverfejlesztést (mint ahogy az Intel is fejleszti a saját C compilerét), de valóban nem ártana most már gatyába rázni ott a sw-fejlesztő brigádot, komoly fejlesztőket ráállítani, komoly budgettel, stb.
Az, hogy mostanra beérték (ha valóban így van, nem tudom) az ARM-ot alacsony fogyasztásban, nem jelenti azt, hogy le is hagyják, hiszen a fizika itt is közbeszól. És hát legalább ilyen nehéz dolguk lesz ARM által birtokolt piacok meghódításával.
(#14180): "Miert kene egy adott feladatra sok szalat radobni, ha keves szal is gyors tud lenni?"
HA kevés szál is gyors tud lenni... Ez majd elválik.
[ Szerkesztve ]
-
Lenne egy kérdésem, ha már ennyire benne vagytok a témában, bár lehet kicsit nagyon előrefutok illetve orbitális baromság.
Tegyük fel hogy elfogy a nanométer, azonos területen kell majd sokkal jobbat kihozni a jelenlegi CPU ISA-kból. Viszont előbb-utóbb ezek a lehetőségek is elfogynak mindenhol, és mindenképp új ISA-kat kell kifejleszteni a nagyobb teljesítményhez, de a kompatibilitást valahogy meg kell oldani. Itt jön képbe a vISA, így nincs szükség natív kódra, azaz az ISA folyamatosan változhat az egyre jobb teljesítményért. Ha jól értelmezem, kicsit a jelenlegi Java / .NET-féle VM megoldásokhoz hasonlít ez, csak jóval mélyebben. Utóbbiak már bizonyítottak, így lehet lassan eljön a vISA-k kora, akár CPU-n is?
Ha egy kicsit még mélyebbre ások, akkor azt látom, hogy a x86 CPU-k belül gyakorlatilag RISC-ek (utasítás-szám szempontból, nem load / store), szóval ez valamilyen szinten belül már rég megtörtént. Pl ott az ősrégi AMD K5 architektúra, aminek a belsejében egy 29k RISC processzor van, de kívülről x86.
[ Szerkesztve ]
Make Asia Great Again!
-
Fiery
veterán
"A többmagúsítás sem nyerte el mindenki tetszését, de hát ugye eszi, nem eszi, nem kap mást"
Nem vagyok benne biztos, hogy a "többmagúsítás" alatt az x86 CPU magok sokszorozasat erted-e, pl. 16 magos Interlagos es tarsai. Ha igen, akkor az azert eleg egyertelmu, hogy jelenleg sokkal tobb szoftver kepes a sok CPU-mag kihasznalasara (me'g ha nem is mindig az osszes mag egyszerre, azaz nem 100%-os CPU-terhelessel), mint amennyi szoftver kepes mondjuk az OpenCL vagy CUDA segitsegevel a hagyomanyos x86 CPU-ra rott feladatot gyorsabban vegrehajtani a GPU segitsegevel. Nyilvan ez a helyzet barmikor megvaltozhat, ha berobban a HSA, de jelen allas szerint a sokmagos x86 CPU-k me'g egesz jol mukodnek, es sok szoftver ki is hasznalja oket. Az persze teny, hogy az AVX, AVX2, XOP es FMA nem terjed tul gyorsan. Azokkal egyutt tudnanak igazan szepen muzsikalni a modern x86 CPU-k.
"Az, hogy mostanra beérték (ha valóban így van, nem tudom) az ARM-ot alacsony fogyasztásban"
Erdemes utananezned
"nem jelenti azt, hogy le is hagyják, hiszen a fizika itt is közbeszól."
Az alapjan, hogy az ARM-os cegek es az Intel is folyamatosan fejleszti a gyartastechnologiajat, hozzaveve azt, hogy az Intelnel vegre az Atom vonal kerult fokuszba, plusz hogy az elmult evekben mekkorat lepett elore az Intel, plusz hogy az Intel masfel-ket ev gyartastechnologiai elonyben van a tobbi gyartoval szemben szamomra egyertelmuen azt sugallja, hogy a kozeljovoben le fogjak hagyni az ARM-ot. Ha nem igy fog tortenni, az csak ugy kepzelheto el, ha az egyik ARM-gyarto (pl. Apple vagy Samsung) behuz egy olyan gyartastechnologiat, amivel atugorja az Intelt. Ahhoz viszont olyan brutalis toke befektetes kellene, amit nem fog egyik gyarto sem felvallalni _szerintem_. (masik elvi lehetoseg, hogy az Intel elbaltazza mondjuk a 10 nanot vagy a 7 nanot... nem tartom valoszinubbnek, mint hogy egy barmelyik ARM gyarto ugyanugy elszurja)
"HA kevés szál is gyors tud lenni... Ez majd elválik"
Mar most is lehet keves szallal, x86 CPU-val is gyorsabban futtatni bizonyos feladatokat, mint sok szalas dGPU-val. Pl. AES enkriptalasban az AES-NI kepes processzorok siman lenyomjak a kozepkategorias GCN dGPU-kat is. AES-256 eredmenyek, OpenCL a GPU-n, nativ AES-NI kod a CPU-n:
Bonaire: 19968 MB/sec
Core i7-4930K: 21094 MB/secPersze ez egy szelsoseges pelda, tudom
[ Szerkesztve ]
-
-
dezz
nagyúr
válasz
lezso6
#14183
üzenetére
Nem kizárt, de CPU-knál egy kicsit nehezebb ügy, mert nagyobb különbségek vannak a mikroarchitektúrák és CPU-családok között. Másrészt ez leginkább esetleges új belépőknek lenne érdeke, a meglévőknek kevésbé.
(#14184) Fiery: Igen, arra gondoltam, és egy példa volt arra, hogy bár nem mindenkinek tetszett az sem, elkerülhetetlen volt.
A Samsung azért eléggé az élvonalban van chipgyártásban, azt sem lehet mondani, hogy kis összegeket fektetnek be, most már a GloFo is tőlük licencel gyártástechnológiát. Az Apple nem tudom, mit gyárt házon belül.
Az AES pont rossz példa, hiszen céláramkör végzi el a feladatot, amit GPU-kba is simán beépíthetnek.
-
Fiery
veterán
"A Samsung azért eléggé az élvonalban van chipgyártásban"
Csak epp ahhoz, hogy az Intel nyomulasat meg tudja allitani, nem eleg, hogy azonos, hanem jobb gyartastechnologian kellene gyartaniuk, mint az Intel. Jelenleg pedig epp forditva van a helyzet, sajnos.
"Az AES pont rossz példa, hiszen céláramkör végzi el a feladatot, amit GPU-kba is simán beépíthetnek."
Megsem teszik meg, mint ahogy az SHA gyorsitas is csak a CPU-kba (ARMv8 + Skylake) fog bekerulni hamarosan, a GPU-kba nem. A GPU-kban meg FMA celaramkor van ennyi erovel. Minden platformnak meg vannak a maga erossegei es gyengei. Csupan arra akartam ravilagitani, hogy nem feltetlenul kell baromi sok szal ahhoz, hogy egy adott feladatot gyorsan vegre lehessen hajtani. Lehetne egyebkent egy csomo specifikus kodot talalni, ami x86 CPU-n jobban fut mint mondjuk egy Bonaire-en vagy GK106-on (pl. dupla pontossagu lebegopontos szamitasok), de vegul is nem cel ez, csupan szemleltetni akartam egy -- felig-meddig jo -- peldaval.
Az igazi teszt az lenne, ha mondjuk jonne egy uj trend, egy uj divat, es arra kellene celaramkort pakolni a CPU-kba es GPU-kba is. Ott lenne igazan erdekes a verseny. Pl. a reszleges ray-tracinget felkapna a jatekipar
[ Szerkesztve ]
-
Fiery
veterán
GPU-kba nehezen tudjak berakni, tulzottan megbonyolitana a chipet. Max. valami olyasmi lenne elkepzelheto, hogy mondjuk CU-nkent 1 ilyen egyseg, de azzal meg nem lehetne eleg nagyot elorelepni a teljesitmenyben.
Ahhoz, hogy a GPU-k tudjak tartani a(z x86) CPU-kkal szembeni kedvezo parametereiket (flop/watt), szuksegszeruen (relative) egyszerunek kell maradniuk. Ha tul sok kacatot bepakolsz, akkor hasonloan bonyolultak lesznek egy ido utan, mint most az x86 CPU-k, es az a hatekonysag rovasara fog menni.
-
Abu85
HÁZIGAZDA
válasz
lezso6
#14183
üzenetére
A nanométer csak egy szám. Sokszor teljesen lényegtelen az adott gyártástechnológia jellemzésénél. Sokkal komplexebb ez az egész, hogy egy számmal leírható legyen a lényeg. Nagyon sokat számít manapság a gyártáshoz használt thin library, ami főleg szoftver, és nagymértékben befolyásolja a végeredményt. Sokkal nagyobb mértékben, mint a szám a nanométer előtt.
Példaként említve a Kabini->Mullins esetét. Nem történt előrelépés a nanométerben, de új thin libraryt használtak. Az eredmény, hogy a Mullins harmad akkora fogyasztáson hozza a Kabini teljesítményét. Mindenképp ölnek pénzt a fejlesztésbe, de manapság kezd irányadóvá válni, hogy azt a pénzt nem biztos, hogy a kisebb csíkra érdemes költeni, ha az automatikus dizájnkialakításért felelős szoftver cseréjével ennyit tudsz javulni.
Szerk.: A 20 nm alatt már leginkább feltételezzük, hogy mit lehetne tenni, hogy jobb legyen. Ma sokkal többet költenek a bérgyártók/gyártók arra, hogy megértsék a kvantumfizikát, mint régen. A legnagyobb ellenség a Heisenberg-féle határozatlansági reláció. Ez nagyjából a 2000-es évek eleje óta létező probléma és minden generációváltásnál egyre jobban felerősödik. Jelen pillanatban nem találjuk a jelenség megkerülésére a megoldást, ezért az történik, hogy megpróbálunk elhatárolódni tőle (úgymond tudjuk hol a fal és a fal előtt maradunk, hogy ne ütközzünk bele ... a beleütközés egyébként drámai fogyasztásnövekedést okoz, ezért kerüljük). Szerencsére ez lehetséges, viszont így jöttek a többmagos processzorok, jött az integrált grafikus vezérlő, és ma már világos, hogy ennek a koncepciónak is meg lesz a saját fala, tehát fel kell készülni arra, amikor a gyakran használt feladatokat teljesen célirányos processzorok látják el. Ezért is nem csak az IGP-kre terjed ki a HSA, hanem akármire, mert ha nem találunk megoldást a problémára, akkor vagy elkezdünk rendkívül specializált DSP-ket és akár FPGA-kat rakni a lapkákba, vagy elfogadjuk a jelenség létezését, és a teljesítményt szimplán a fogyasztás drasztikus növelése mellett emeljük. A probléma az, hogy nagyon mobil irányba tartunk, így azt a piac nem fogja benyelni, hogy a teljesítmény növeléséhez a fogyasztást mindenképp növelni kell. Ma az a norma, hogy nőjön a teljesítmény és csökkenjen a fogyasztás.
Vannak még nagyon érdekes tanulmányai az NVIDIA-nak, hogy a GPU-k sokkal szabadabban tervezhetők, mint ahogy azt eddig sejtettük. Ezzel a mostani GPU-k jellemző pJ/FLOP értékét a tizedére is le lehet vinni, tehát az is egy reális alternatíva, hogy a GPU-k falát odébb toljuk, hogy később ütközzünk bele. Ugyanez megtehető a CPU-kra is, de a bonyolultságuk miatt a pJ/FLOP maximum a felére csökkenthető, amihez viszont radikálisan új ISA is kell. Ez egy régebbi MIPS tanulmány. Sajnos ezt úgy értékelik, hogy nem éri meg a fejlesztést.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
HookR
addikt
"A legnagyobb ellenség a Heisenberg-féle határozatlansági reláció. Ez nagyjából a 2000-es évek eleje óta létező probléma és minden generációváltásnál egyre jobban felerősödik. Jelen pillanatban nem találjuk a jelenség megkerülésére a megoldást..."
Akadnak érdekes kutatási eredmények a témában: Tricking the Uncertainty Principle
▌www.thunderbolts.info | youtube.com/ThunderboltsProject ▌16personalities.com▐
-
P.H.
senior tag
Még ha el is fogadjuk, hogy a nanométer már nem megoldás minden problémára, azért azt semmiképp sem hagyható figyelmen kívül, hogy a nanométer-csökkentés gazdaságosabbá teszi a gyártást. De csakis a gyártást - azaz az 1 mm2 waferre eső költséget -, ami csak egy bizonyos része az egész "chip-készítési" folyamatnak, de az utóbbi években egyre markánsabban látható, hogy ez a "chip-készítési folyamat" egyre jobban szegmentálódik, úgy mint:
- ARM vagy MIPS mint ISA-tervező (a.k.a architektúra)
- Qualcomm, MediaTek, Apple, stb. mint "egyedi" elvárások készítője (a.k.a microarch)
- TSMC, GlobalFoundries mint gyártó cégek (a.k.a design implementation)Emlékeztetve erre: "An understanding of the terms architecture, microarchitecture, and design implementation is important when discussing processor design.
The architecture consists of the instruction set and those features of a processor that are visible to software programs running on the processor. The architecture determines what software the processor can run. [...]
The term microarchitecture refers to the design features used to reach the target cost, performance, and functionality goals of the processor. [...]
The design implementation refers to a particular combination of physical logic and circuit elements that comprise a processor that meets the microarchitecture specifications."Ebben a közegben a néhány nagy öregen (Samsung, IBM, Intel) kívül egyre kevésbé finanszírozható házon belül az összes lépés, legutóbb látványosan az AMD is elvesztette/kiszervezte a gyártást és a bele ölt költségeket, és az IBM is erre készül; tehát ez legalábbis nem a tehetségesség vagy a tehetségtelenség mutatója.
Ha viszont ilyen vertikális tekintetben nézzük az egyes fázisok költségeit (K+F, termelési eszközök, gyárak, ...), akkor úgy tűnik, először is a gyártás a legköltségesebb, nála lényegesen kevesebbe kerül a microarch-fejlesztés; új architektúra (ISA) kidolgozása pedig a legkevésbé költséges, lévén - nem lebecsülve a szükséges tudást, - inkább elméleti, mint gyakorlati dolog. A gyakorlat is ezt látszik igazolni, eddig legalábbis a leggyakoribb a "design implementation" váltás volt, kevésbé gyakori a microarch-újratervezés (bár az Intel - kissé érthetetlen, vagy piacilag nem teljesen magyarázható módon - a kettőt évente váltogatta), a legritkább az új ISA-k létrehozása. Ez igaz GPU-fronton is.
Mivel eddig a nanométer-csökkentés volt a legfőbb fegyver hatékonyság növelése érdekében, ha ennek lehetőségei elfogynak, ennek megfelelően egy-egy architektúrát "birtokló/felügyelő" cégnek még mindig kevésbé érdeke az ISA-ja felújítása, viszont igenis érdeke a legtöbbet kihozni microarchitecture-szinten belőle; ez pedig együtt jár - SZVSZ végre - a software-es oldalra helyezett nagyobb hangsúllyal is (gondolok itt arra, hogy az AMD se dobta volna be a pl. Mantle-t, ha számításai szerint úgy haladna a chip-hatékonység fejlesztése a következő 10 évben, mint az elmúlt 10 esztendőben).
A gyártó cégeknek viszont érdeke, hogy minél több eszköz legyen legyártva, hisz a csökkenő mm2-re eső gyártási költségek melletti növekvő egyéb költségek csak úgy behozhatók, ha minél több chip kerül legyártásra. Internet of Things, you know.
[ Szerkesztve ]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
Na pont erre gondoltam, hogy ha a gyártástechnológia fejlesztése egyre kevésbé éri meg, akkor a microarchitektúra megtervezésére kell jobban odafigyelni. Viszont mikor már ez utóbbinak fejlesztése is korlátokba ütközik a teljesítménynél (lásd haswell, ahol minimális volt a növekedés), új architektúrára van szükség. Ez utóbbinál viszont korlátozó az eltérő ISA, így az Intel az AVX kiterjesztéssel próbálkozik (ahogy eddig is ment az MMX, SSE), ami úgymond egy köztes út, megtartva a kompatibilitást, míg az AMD radikálisabb megoldásban keresi a jövőt, és GPU-val házasítja a "fix" CPU-t.
[ Szerkesztve ]
Make Asia Great Again!
-
P.H.
senior tag
válasz
lezso6
#14193
üzenetére
A microarch - hülyén megfogalmazva - egy nagyon oda-vissza dolog: a HSA pár tucat utasításával mindent meg lehet csinálni (még kevesebb utasítás is elég lenne, pl. a lebegőpontos számok kezelése leginkább bitbirizgálás, régen a 286-386-486 időkben a fordítóprogramok belefordították a programokba a sima integer utasításokkal való végrehajtást arra az esetre, ha nincs FPU), a többi (micro)architektúra 1000+ utasításai csak arra vannak, hogy egyes eseteket/helyzeteket gyorsabban lehessen megoldani (pl. SIMD esetén 2/4/8/16/32 számpárt ugyanannyi idő alatt mondjuk összeadni, mint egyetlen párt; vagy AES is volt eddig, csak most gyorsabb; az AVX is csak közel 2x gyorsabbá tenne bizonyos utasításfolyamokat, ha kihasználnák a programok).
Ezt viszont a leghatékonyabb kihasználni közvetlen kódban; fordított/köztes rétegeket felhasználó nyelvekben ez a hatékonyság csökken. Pl. Abu szerezi emlegeti a pJ/FLOP-ot mint mérőszámot alkalmazni, ami nyilvánvalóan nő, ha a futtatott kódot fordítani is kell előtte.
Ilyen szempontból az x86/x64-nek is csökkenni tűnik a hatékonysága, mivel ezt is úgymond fordítani kell chip-en belül, viszont azt is hozzá kell venni, hogy az x86/x64-nek így sokkal nagyobb a kódsűrűsége, mivel változó hosszúságú utasításokat használ; ezért pl. egy natív x64 programrésznek kb. harmadannyi az I-cache igénye, mint egy IA-64-é és kb. feleannyi, mint egy ARM-é; így kevésbé költséges pl. loop cache-t építeni bele. Ilyeneken is múlik az energiahatékonyság.[ Szerkesztve ]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
Abu85
HÁZIGAZDA
Nem erre gondoltam. A gyártástechnológia továbbra is lényeges még ha a generációváltás egyre kisebb előnyt jelent és ehhez képest egyre költségesebb. Ami az én szememet csípi, hogy a nanométer elé odaírunk egy számot, de az valójában nem jelent semmit. Csak azért nem kódnév alapján utalunk a gyártástechnológiára, mert marketingeszköz az egész és a vásárlók nem értenek meg a több oldalas leírást, amivel pontosan jellemezhető az adott gyártástechnológia.
Ha pontosan akarjuk ezt elemezni, akkor még az egyes lapkákhoz is szükséges lenne egy teljes leírás a fizikai dizájnról, és az alkalmazott dens library-ről. Ezek nélkül az a szám a nanométer előtt nem jelent semmit.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Ja, én is inkább az egész gyártástechnológiára gondoltam, mint a nanométerre. Erről lehetne egy részletesebb tudástárcikk, esetleg akár vélemény cikk a nagyobb terjedelem miatt, mert sokaknak (nekem is) elég homályos, s szerintem nem csak én vagyok rá kíváncsi, hogy most mi van. Jelenleg csak azt tudom, hogy egyes gyártók nanométereit nem lehet összehasonlítani, nemcsak azért, mert azok gyakorlatilag "nem is annyik amennyik", hanem mert az általad is említett "thin library" is rengeteget közrejátszik. Gondolom ez utóbbi a cpu-kban használt egységek építőköveinek halmaza.
[ Szerkesztve ]
Make Asia Great Again!
-
P.H.
senior tag
válasz
lezso6
#14196
üzenetére
Neked és #14195 Abu-nak: A gyártástechnológiai fejlődés lassulásával egyre inkább jönnek elő az olyan "okos" dolgok, mint pl. ez. Az ilyesmit nehéz leírni, és nyilván az Intel és az ARM is kínál(ni fog) hasonló "okosságokat". Igen, eljött a kora az ilyesminek is; most sajnálhatjuk, hogy nem korábban.
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
#14198
Vitamincsiga
tag
dezz
#14048
Vitamincsiga
tag
A legutóbb nem tudtam olyan tesztet találni, ami a Kaveri igazi erejét bemutatná, most pótlom: [link]
A HSA-val készítettek a cikk második felében találhatóak; nagyon meggyőzőek
HSA-val kihasználva az erejét 2,5-5x-ös a gyorsulás, az i5-tel szemben így 1,5-2,5x-te jobb teljesítményre képes!Jó lett volna egy 6 magos i7-et látni a tesztben
A fenti teszt tükrében, már értem miért készül az Intel 8 magos i7-tel a csúcsproci cím megtartására - lehet, hogy a HSA-val készült programoknál az Excavatornak így is lesz esélye lenyomni őket a trónról?No! Mégis csak van kakaó a Bull legújabb reinkarnációjában
Jó lenne egy varázsgömb ;-)
-
#14199
Fiery
veterán
Vitamincsiga
#14198
Fiery
veterán
válasz
Vitamincsiga
#14198
üzenetére
A PCMark 8 tudtommal nem tamogat HSA-t, legfeljebb OpenCL 1.x-et. A PCMark eredmenyek egyebkent is kicsit furcsak, erdemes osszevetni oket ezekkel --> [link]
A HSA potencialis teljesitmenye egyebkent tenyleg remek, csak epp az a gond, hogy a 3 letezo HSA implementaciobol 1-et az AMD irt, a masik kettot meg az AMD szponzoralta kozvetlenul. Szerintem varjuk meg a fuggetlen fejleszteseket. Ahhoz viszont kellene elobb egy stabil HSA implementacio. Abu mindjart megmondja, most epp mikorra igeri a HSA Foundation meg az AMD. Ahhoz adj hozza me'g 1-2 honapot, negyedevet vagy evet, izles szerint, es akkorra talan elkezdenek szallingozni a fuggetlen szoftverek is.
-
Vitamincsiga
tag
válasz
stratova
#14158
üzenetére
Hát egy SeaMicro szívesen beüzemelnék
Az AMD x86 + ARM bejelentésével kavart egy alaposat...
Ezzel nagyban leegyszerűsíti a fejlesztendő termékek palettáját, míg azok még jobban le fogják tudni fedni(?) a teljes piaci igényt.És a teljesítménnyel sem lesz gond; már a Kaverinek sincs. Teszt linkje itt: #14198
Persze mint tudjuk abból soha sem elég; a PS4 APU-ját ha tegnap kapuk volna meg PC-be, akkor is későnek találtuk volnaJó lenne egy varázsgömb ;-)
/
Plusz, ha az on-board memoriaban vannak az adatok, a szamitassal sokkal gyorsabban vegezhet egy dGPU, mint egy APU, es ez a trend me'g par evig fenn fog maradni.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
De a mai vilagban pont nem azt latom, hogy az ISA-hoz valo ragaszkodas lenne a legfobb kerdes, plane a mobil es ultramobil vonalon.
Új hozzászólás Aktív témák
A topikban az OFF és minden egyéb, nem a témához kapcsolódó hozzászólás gyártása TILOS!
Az ide nem illő hozzászólások topikja:[link]
MIELŐTT LINKELNÉL VAGY KÉRDEZNÉL, MINDIG OLVASS KICSIT VISSZA!!
A topik témája:
Az AMD éppen érkező, vagy jövőbeni új processzorainak kivesézése, lehetőleg minél inkább szakmai keretek között maradva.
- DIGI kábel TV
- TP-LINK routerek
- Audi, Cupra, Seat, Skoda, Volkswagen topik
- Gaming notebook topik
- Kedvenc zene a mai napra
- Kormányok / autós szimulátorok topikja
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Star Wars: The Old Republic - MMORPG
- Androidos fejegységek
- Hivatalosan is elkészült az NVIDIA App
- További aktív témák...
- Intel Core i7-7700K (8M Cache, up to 4.50 GHz) OEM Processor!
- AMD Ryzen 5 2600 6-Core 3.4GHz (up to 3.9 GHz)OEM Processzor!
- AMD Ryzen 5 1600 6-Core 3.2GHz (up to 3.6GHz) AM4 OEM Processzor
- AMD FX-8320 8-Core 3.5GHz AM3+ Processzor
- AMD Ryzen 7 5700X3D 3.0GHz (96MB Cache, up to 4.1GHz) OEM AM4 Processzor!
Állásajánlatok
Cég: HC Pointer Kft.
Város: Pécs
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest