Egy kicsit a feje tetejére állt a világ, de jó értelemben. Talán nekem mint mezei user-nek a h.265 lesz majd a megváltás mert a mostani youtube minőség az katasztrófa. Amúgy van egy nagyon jó kis video az apu13 honlapján. Érdemes megnézni. Baromi jól elmagyarázza, hogy mi ez az egész hardver hisztéria. Én bízok az AMD-ben, hogy pár éven belül tényleg meg lesz az áttörés, és végre elérik a 2006-ban kitűzött célt. Amen.

Addig gyorsítottuk a világot míg mi magunk maradtunk le...

"Itt akár 40-50 GB-ról is beszélhetünk, így hiába van GPU-s gyorsítás ezen a piacon, a mai gyorsítókártyákon nincs kellő mennyiségű fedélzeti memória. Ezért a cégek még ma is jellemzően százezres nagyságrendű node-okból felépülő szervereket használnak az adatok feldolgozására, így az egyes munkafolyamatok öt napig is futnak."

Kivancsi lennék ennek a pontos mechanizmusara. Mert 40-50 GB rendszermemoriat a Kaveri (Berlin) eleve nem kezel ("csupan" 32 GB-ot), tehat ott is fel kell osztani a munkat reszfeladatokra, mondjuk minimum 2-re. Ha pedig a munkat fel lehet osztani reszfeladatokra, akkor nem igazan latom a kulonbseget akozott, hogy 20 darabra daraboljuk, vagy 2-re. A GPU-val gyorsitott feldolgozas eleve a parhuzamosithato feladatokra van kitalalva. Nyilvan az ide-oda masolgatast egy SVM-képes APU-n meg lehet uszni, de erre eddig is voltak workaroundok. Ha egy tipikus modern dGPU PCIe 3.0-s interfeszet nezunk, az siman tud egy iranyban 10 GigaByte/mp tempoval adatot mozgatni. Hacsak nem a GPU-val vegzett szamitas baromi gyorsan megtortenik (ami nem tipikus), akkor az ide-oda masolgatas maximum fejlesztoi (programozoi) oldalrol maceras, de nem annyira lenyeges a futasido szempontjabol. At is lehet lapolni az adat masolasokat a szamitasi feladatokkal, ha valaki nagyon ra akar menni a teljesitmenyre.

Persze tudom en, hogy SVM-mel csomo mindent megsporolhat az ember, de nem vilagos szamomra, hogy miert tudna a Kaveri (Berlin) 5-10-szeres gyorsulast elerni pl. egy 1 TFLOPS-os dGPU-hoz kepest, ha amugy a feladat reszfeladatokra bonthato, es a hardver eleg gyorsan tudja mozgatni az adatokat a dGPU memoriaja es a rendszermemoria kozt oda-vissza. A programozo meg oldja meg, azert fizetik. Nehogy mar az olaj/gaz banyaszati iparban (ahol iszonyat penzek forognak elmeletben es gyakorlatban is) ne tudjak megfizetni a programozot...

[ Szerkesztve ]

A Kaveri 64 GB-ot kezel. A Berlin is tud ennyit talán többet is.

Természetesen vannak tipikus megoldások a dedikált GPU-kra is, mert az AMD és az NV is érdekelt itt a FirePro és Tesla kártyákkal, és ebből a szempontból számos kutatás folyik a gyorsítók hatékonyabb kihasználására, de a piac ezeket nem fogadta be a nehézségeik miatt, így még ma is a CPU-kra építenek, és inkább vennének új hardvert, minthogy a program oldalán oldják meg ezeket.
Azzal érvelnek, hogy olcsóbb tonnaszámra hardvert venni, és az aktuális programkód jelentős részét újrahasznosítani, minthogy közel a nulláról újrakezdve egy hatékonyabb kóddal beépítsék dedikált GPU-kat a feldolgozásba.

[ Szerkesztve ]

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

"Azzal érvelnek, hogy olcsóbb tonnaszámra hardvert venni, és az aktuális programkód jelentős részét újrahasznosítani, minthogy közel a nulláról újrakezdve egy hatékonyabb kóddal beépítsék dedikált GPU-kat a feldolgozásba."

Ha a jelenlegi programkod kizarolag CPU eroforrasokat hasznal, akkor dGPU-ra es SVM-es APU-ra atvinni a szamitasokat mindenkepp es egyarant a meglevo programkod modositasat igenyli. Teny, hogy SVM-nel kicsit egyszerubb (lesz majd) a melo (ha majd lesz OpenCL 2.0 ill. HSA a gyakorlatban is), de mindenkepp a program modositasat igenyli.

Ha pedig a szoftver mar hasznal GPU eroforrasokat, mondjuk CUDA-n vagy OpenCL-en keresztul, akkor a programozok mar athidaltak a dGPU problemait (relative szukos on-board memoria, memoria blokkok masolgatasa), tehat egyszerubb egy erosebb dGPU-ra cserelni a meglevo dGPU-t, mintsem a teljes szervert kukazni.

Es arra nem reagaltal, hogy mikepp all elo az 5-10-szeres gyorsulas a Berlinen. Azt nem tudom elkepzelni, mihez kepest gondolja az AMD. Hacsak nem valami atomos (Centerton) mikroszerver farm a kiindulasi alap darabonkent 2 GB rendszermemoriaval

[ Szerkesztve ]

Tipp: ugyanazon az APU-n mérték CPU vs. CPU+GPU módban.

[ Szerkesztve ]

Eladó régi hardverek: https://hardverapro.hu/apro/sok_regi_kutyu/friss.html

SVM-mel jóval egyszerűbb lesz az átvitel. Módosítani mindenképp kell, de a HSA-val maradhatnak a mostani nyelv mellett is. Jellemzően OpenMP.

Jelen pillanatban ott tartunk, hogy a dGPU az olajiparban nem jutott tovább a kipróbálom fázisnál. Ma ez a szegmens még mindig CPU-kat használ, noha valóban próbálkoztak a váltással, csak költségesnek tartják a dGPU-nak a kihasználását. Kisebb átállási költségeket szeretnének.

Azt nem mondták, de az IGP befogásával el tudom képzelni, hogy egy egységnyi fogyasztású CPU az RTM-ben tízszer is lassabban fut.

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

"Itt akár 40-50 GB-ról is beszélhetünk, így hiába van GPU-s gyorsítás ezen a piacon, a mai gyorsítókártyákon nincs kellő mennyiségű fedélzeti memória. Ezért a cégek még ma is jellemzően százezres nagyságrendű node-okból felépülő szervereket használnak az adatok feldolgozására, így az egyes munkafolyamatok öt napig is futnak."

Akkor itt valami nem stimmel. Most akkor van GPU-s gyorsitas azon a piacon vagy nincs? Ha van, akkor egy dGPU-s megoldashoz kepest kizartnak tartom az 5-10-szeres gyorsulast. Ha nincs GPU-s gyorsitas jelenleg, akkor miert irja a hir, hogy van? Ha van GPU-s gyorsitas, akkor miert a CPU-only teljesitmenyt veszik alapul? (mar ha azt veszik alapul) Ha nincs GPU-s gyorsitas, akkor miert nem egy izmosabb 4-way Opteron "Interlagos" az alap? Vagy ahhoz kepest is 5-10x gyorsulas erheto el egy _1-way_ Berlin APU-val? Nem tartom tul valoszinunek ezt a variaciot sem

A vicc ebben az, hogy a programozoi munka ("tanuld meg fiam az OpenCL 1.x-et dGPU-val, van ra 3 honapod") me'g mindig olcsobb lenne, mint vasat cserelni _es_ modositani a meglevo szoftvereket, legalabbis ha figyelembe vesszuk, hogy igy is (dGPU-ra atallas), ugy is (Berlin+SVM-re atallas) teljes vas cserevel jar. Viszont, mig a dGPU-s megoldasnal, ha egyszer osszeallt az uj szoftver, barmikor tovabb skalazhato a teljesitmeny a dGPU upgrade-jevel (vagy ujabb dGPU-k telepitesevel, ha a szerverben van hely es van áram hozza), a Berlint nehez lesz cserelni gyorsabbra, plane olyanra, amivel jelentos elorelepesre lehet szamitani teljesitmenyben. Fejben nehez lenne most kiszamolnom, hogy a Watt/FLOPS arány tekinteteben melyik lenne a jobb megoldas, de az olaj/gaz banyaszati ipar szerintem nem ezt nezi leginkabb, nem hiszem, hogy naluk ez lenne a legfontosabb szempont.

De ha az olaj/gaz banyaszati ipar Berlint akar, akkor lelkuk rajta. Mindenesetre en errol megkerdeznek azert egy donteshozot is mondjuk a BP informatikai reszlegerol, lehet hogy tok mast mondana, mint az AMD sajat marketing expertjei

Felreertes ne essek, siman el tudom kepzelni rengeteg felhasznalasnal, hogy a Kaveri jol johet, de ennel a banyaszati peldanal nehezen kepzelem el, hogy egy Berlin farm jobban mukodne a gyakorlatban, mint mondjuk egy Tesla-farm...

[ Szerkesztve ]

Nem elég az OpenCL-t megtanulni. Mesterévé kell válni. Ez sokkal több idő, mint három hónap.
Vascsere mindenképp lesz, de az kedvezőbb, ha az aktuális kódban a lehető legtöbb részt újrahasznosítod.
Ugyanerre megy egyébként az NVIDIA is, és az RTM-re a következő években saját APU-kat kínálnak majd. Ez náluk is egy áttörés lesz. Tehát ez a piac annyira nem változik meg, továbbra is lesz FirePro és Tesla, csak nem dedikált, hanem integrált szinten, ahogy az a piacnak kedvezőbb.

Nem véletlen, hogy a Maxwell killer fícsőre az SVM. Ők is ugyanazokat a problémákat látják, amiket az AMD, és ugyanazt a megoldást kínálják rá.

[ Szerkesztve ]

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

Rendben, bar tovabbra sem tudom felfogni agyilag, hogy a programozasi reszt miert tudja kivaltani egy joval gyengebb elmeleti teljesitmenyu vas. Egy Berlin akarmennyire is megfeszul, nem fog tudni 0,8 TFLOPS-nal nagyobb teljesitmenyt leadni az iGPU-javal, mig egy 4 db Tesla K20x fogadasara kepes GPU szerver 15,8 TFLOPS-ot teljesit. Persze ha a feladat baromi jol parhuzamosithato ujabb szerverek hozzaadasaval, akkor adott esetben 16 db Berlin szerver kivalthat 1 db GPU szervert, de nem hiszem, hogy az anyagilag, villanyszamlaban, elhelyezesben (logisztika) jobb megoldas lenne. De mindez csak az en nyomorom, en ilyen feladatra tutira GPU szervert vasarolnek, de lehet, hogy baromira nem ertek hozza Hagyjuk is, nem akarom tovabb nyujtani a retestesztat.

Akkor van ennek értelme, ha a Berlin jobb performance / watt mutatód ad, mint egy standard CPU + Tesla kártya. Amíg azt nem tudjuk, nem törnék pálcát egyik oldal mellett sem.

Ezt azert nagyjabol meg lehetne saccolni szerintem. Egy Berlin alapu szerver mondjuk fogyaszt cca. 150 Wattot mindenestul (teljes terheles alatt), ebbol kell 16 db, az 2400 Watt. Egy Tesla K20x alapu GPU szerver, 4 db K20X-szel meg legyen mondjuk durvan 1300 Watt 2 db Xeon CPU-val (egy Tesla K20x = 235 Watt, egy Xeon kb. 150 Watt). SZVSZ eleg egyertelmu a performance/Watt mutato, ha csak a nyers, elmeleti TFLOPS-ot nezzuk. Mas kerdes persze, hogy egyik vagy masik platformra mennyire jo szoftvert tud kesziteni a vallalat.

Koszi, nem tudtam, hogy ennyire megvaltozott a memoriakezeles.

Miért is nem működik?

Cache koherencia, hogy csak egy peldat mondjak. Egy tobbutas CPU rendszerben a CPU-knak egymas kozt kell koherenciat fenntartani a cache-eiknel. Egy egyutas, SVM-capable APU eseteben a CPU es a GPU resz kulon cache-ekkel rendelkezik, melyek kozt szintén fent kell tartani a koherenciat -- amit egyebkent egeszen ... khm ... erdekes modon old meg az AMD, de vegul is mukodik. Egy tobbutas APU-nal borzaszto sok eroforras elmenne arra, hogy az osszes CPU es az osszes GPU cache-ei kozt fenntartsak a teljes koherenciat. Abu biztos tudja, hogy milyen egyeb akadalyai vannak, nekem most kapasbol ez jutott eszembe.

[ Szerkesztve ]

És ha L3-t alkalmazol a APU közötti kapcsolatra?

de pont ez a lényeg: nem a nyers TFLOPS számít, mert hiába adott, ha sok algoritmus nem tudja hatékonyan kihasználni, főképp a gyér memória sávszél miatt. és a nem erősen dataparallel feladatokról nem is beszélve. neighborhood searchet eleve pl. csak 1-2 elvetemült kutató implementált AFAIK, nevetséges gyorsulást elérve. Kaverivel ez jelentősen javul, és nem csak _lehetséges_, hanem _érdemes_ lesz szakértő programozóra beruházni, vagy valakit kitaníttatni.

mondjuk jó lenne már tudni valamit a developer programról, mert a HSA oldalán még SEMMI nincs, szóval nem tudom kivel kéne jóban lenni, hogy minél hamarabb elkezdhessünk foglalkozni a témával. Jó lenne minél hamarabb, mert az év elején meg kellene terveznem az új architektúrát a proginknak, de azt már jó lenne ehhez a hardverhez igazítani.

A vér nem válik VAZZE!™

Az L3-ak kozotti koherenciat is biztositani kell, raadasul az L3-ba szemetelo iGPU az Intelnek is fejfajast okozott, nem feltetlenul jo dolog az. Ha meg az egyik APU iGPU-ja teleszemeteli a sajat L3-at, plusz a cache koherencia miatt a szemetelest at kell vinni a tobbi APU L3-aba is, az vegkepp tragikus kovetkezmenyekkel jar a teljesitmenyre

"Egy egyutas, SVM-capable APU eseteben a CPU es a GPU resz kulon cache-ekkel rendelkezik, melyek kozt szintén fent kell tartani a koherenciat -- amit egyebkent egeszen ... khm ... erdekes modon old meg az AMD, de vegul is mukodik"

Ezt ki tudnád fejteni vagy tudsz linket adni a működésről? Köszi

"főképp a gyér memória sávszél miatt"

Az max. akkor szamit, ha tul keves feladatot csinalsz egy adott memoria tartalomra leosztva, azaz a GPU tul hamar vegez a feladataval, nem dolgozik eleget az adatokon. Ha ugyanis rendesen dolgozik a GPU, nem csak vegigszalad az adatokon, akkor a mem.savszelesseg szukossege nem lenyeges, hiszen sokkal tobb ido telik el az adatokon valo szamitasokkal, mint az adatok mozgatasaval. Amugy meg a dGPU-k sajat memoriajahoz valo hozzaferes -- elvileg -- sokkal gyorsabb, mint az iGPU eseteben a rendszermemoriahoz valo hozzaferes, SVM ide vagy oda. Teny, hogy ha keves adatot kell sokat ide-oda masolgatni, akkor az SVM jol johet, de mar eddig is baromi sok feladatot megoldottak dGPU-val, ide-oda masolgatassal is. Aki pedig mar volt annyira ugyes, hogy athidalja a dGPU korlatait, annak hiaba adsz SVM-et, a keves TFLOPS miatt maradni fog inkabb a dGPU-nal.

"_érdemes_ lesz szakértő programozóra beruházni, vagy valakit kitaníttatni"

Hat nemtom... En ha egy olaj/gaz banyaszati ceg lennek, es milliardok (USD-ben) forognanak kockan, nekem eddig is erdemes lett volna valakit kinevelni OpenCL-re vagy CUDA-ra, es venni egy csinos GPU szervert. Es mivel sok GPU szerver termekleirasaban pont ezek az iparagak szerepelnek (pl. a Supermicro weblapjarol egy idezet: "GPU Server, Mission-critical app., enterprise server, oil & gas, financial, 3D rendering, chemistry, HPC"), egesz biztos, hogy ez meg is tortent sok cegnel. Lehet, hogy az AMD talalt egy banyasz ceget, aki ezzel nem volt hajlando foglalkozni, es inkabb CPU-val oldotta meg a szamitasokat -- csak akkor meg fura, hogy nem a banyasz ceg CIO-ja vagy CTO-ja allt ki a szinpadra eloadni, hogy "Mi csak a HSA-ra vartunk, addig nem foglalkoztunk holmi 16 TFLOPS-ra kepes szutyok GPU szerverekkel, nem, mi az 1 TFLOPS-ra sem kepes Berlinre vartunk, nekunk semmi mas nem felel meg"

[ Szerkesztve ]

Ezt nem fogja az AMD sem reszletesen eloadni, annyira azert nem buszkek a megoldasukra A lenyeg, hogy a Kaveri eseteben az iGPU L2 cache-e letiltasra kerul, ha valaki az SVM-et hasznalja. Ez az egyik oka annak, hogy a Kaveri sem full-HSA megoldas (akarmit is mond az AMD a marketing maszlagban), hanem majd csak a Carrizo lesz a full-HSA.

Arra gondoltam hogy az iGPU nem szemetelhet a L3ba illetve csak egy meghatározott részbe írhat.

Ha a unified L3 csak egy reszet hasznalhatja az iGPU, akkor az nem unified L3. Ennyi erovel sajat L3-ja is lehetne akkor

Ez így van a PS4-ben és az X1-ben is. De a cache a munkafolyamattól függ, tehát az IGP L2 gyorsítótára aktív marad, ha van hozzá rendelve egy rendszermemóriából lecsípett videomemória. Akkor passzív, ha az Onion+ buszon keresztül történik a munka. Így sincs a szó szoros értelmében letiltva, csak a nem érinti az adatmozgás. Nagyon jó okuk volt arra, hogy azt így csinálták, ugyanis az IGP tolerálja a késleltetést, tehát nincs nagy szüksége az L2 cache-re, de a CPU-nak viszont jobban fekszik, ha az adatot a saját L2 gyorsítótárjába írja bele az IGP.

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

"De ha az olaj/gaz banyaszati ipar Berlint akar, akkor lelkuk rajta. Mindenesetre en errol megkerdeznek azert egy donteshozot is mondjuk a BP informatikai reszlegerol, lehet hogy tok mast mondana, mint az AMD sajat marketing expertjei"

Tessék itt elolvashatod mit gondol erről a BP, nem olyan régi hír:
BP Opens New HPC Facility at Houston Headquarters [link]

idézet:
"Last December, HPCwire learned that BP planned to derive its FLOPs from a CPU-only strategy. The new system would employ about 67,000 CPUs, but no GPUs or Phis. At the time, Keith Gray, BP’s HPC center manager, told HPCwire that the British firm wasn’t ready to make the leap to heterogeneous computing. “We continue to test accelerators,” he shared in an email, “but have not built a strong business case for our complete application base.”"

Szóval az előző 1 PFlops-os BP HPC rendszer is CPU only volt és az újonnan épülő 2 PFlops-os is az lesz. A mai napig is csak tesztelgetik ebben az iparágban a gyorsítók felhasználhatóságát, de éles üzemben még nincs bennük bizalom. Ez az AMD féle 10x gyorsulás a szokásos PR maszlag. Emlékezz anno az Nvidia is a GPU gyorsítás bevezetés kezdetén akár 10-100x teljesítmény növekedésről zagyvált a CPU-khoz mérten a saját PR promocióiban, de azokon is max mosolyogni lehetett, de komolyan venni aligha. Ez is ugyanilyen, valamivel fel kell hívni a termékre a figyelmet, még ha blőd nagy kamu is.

Egy kis adalek --> [link]

"Ultra High-end Workstation (Requiring GPU compute and 3D graphics performance): Oil and gas, computer aided engineering"

igen, épp ezt mondtam, hogy akkor számít sok ilyen algoritmus van.

amíg nem ismerjük az olajvállalatok számításaihoz szükséges algoritmust, és a fejlesztésekhez szükséges erőforrásokat, addig csak sötétben tapogatózunk. nem hinném, hogy egy emberes projekt lenne. kérdés ráadásul hogy van-e elég képzett szakember, aki tényleg mestere a gpgpunak (ELTE progmaton még speci sincs). aztán ott van, hogy mennyi idő kikisérletezni, hogy mi a megfelelően jó implementáció. ezeknek a cégeknek nem azért megy jól, mert szórják a pénzt. ahogy írták mások is: elég nagyobb szervert venni hagyományos procikkal és kész, a jól megszokott környezetben dolgoznak. Nem ruháznak be egy komplett új infrastruktúrára, ha egyébként kétséges a siker (nem tudod ennyit gyorsul) és kiszámíthatatlan a projekt. ráadásul van még sok más tényező is egy ilyen cégnél, ami bele tud szólni az időzítésbe.
nálunk kicsiben ugyanez meg: túl nagy vesződség egyáltalán megpróbálni a proginkat portolni GPU-ra, és abszolút nem garantált a siker. még felmérni a helyzetet is túl drága. pénz meg mi sem pazarlunk, ahogy az olajvállalatok és semmilyen vállalat sem.

persze abban egyetértek, hogy amit ígérnek, abból gyököt kell vonni. én ettől függetlenül úgy várom, mint a messiást

[ Szerkesztve ]

A vér nem válik VAZZE!™