Új hozzászólás Aktív témák
-
Fiery
veterán
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. -
Fiery
veterán
"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"
-
Fiery
veterán
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
-
Fiery
veterán
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.
-
Fiery
veterán
APU-bol nem lehet tobbutas szervert epiteni, maga az APU mint CPU+GPU egyseg, plane SVM-mel (megosztott memoria) fuszerezve nem mukodik tobbutas leosztasban, sajnos. Ugyhogy vagy tobbutas CPU, vagy egyutas APU. Az elobbi piacrol az AMD kiszallni latszik, az utobbiban meg vagy menni fog a szeker a HSA-val, vagy nem, majd kiderul az elkovetkezo 1-2 evben.
-
Fiery
veterán
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.
-
Fiery
veterán
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. -
Fiery
veterán
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...
-
Fiery
veterán
"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 -
Fiery
veterán
"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
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
Fiery
veterán
"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...
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
- Kezdő Gamer PC / Számítógép! Csere-Beszámítás!R7 1700X /GTX 1060 6GB /16GB DDR4 / 250SSD + 1TB HDD
- Apple Mac mini M4 / M4 Pro garantáltan a legjobb ár, bontatlan, EU-s, garanciális
- HP EliteDesk 800 G3 TWR PC, i5-6500 CPU, 16 GB DDR4 RAM, Windows 11
- BONTATLAN Lenovo ThinkCentre M70s SFF Business Időtálló Asztali gép -50% i5-14500 16/512 770 Magyar
- ReZone Használt PC Bazár Megbízható gépek, korrekt árak.
- Akciós Windows 10 pro + Office 2019 professional plus csomag AZONNALI SZÁLLÍTÁS
- Okosóra felvásárlás!! Samsung Galaxy Watch 6, Samsung Galaxy Watch 7, Samsung Galaxy Watch Ultra
- Azonnali készpénzes AMD CPU AMD VGA számítógép felvásárlás személyesen / postával korrekt áron
- HIBÁTLAN iPhone 13 Pro Max 256GB Graphite -1 ÉV GARANCIA - Kártyafüggetlen, MS3756, 100% Akkumulátor
- Apple iPhone 14 128GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Laptopműhely Bt.
Város: Budapest