- Perelnek a vallásos kripto-piramisjáték miatt
- Milyen routert?
- Kodi és kiegészítői magyar nyelvű online tartalmakhoz (Linux, Windows)
- Open Broadcaster Software OBS
- Proxmox VE
- Jelszókezelők
- Kanada feltalálta a Netflix-adót
- Linux kezdőknek
- ASUS routerek
- Vodafone otthoni szolgáltatások (TV, internet, telefon)
Új hozzászólás Aktív témák
-
Fiery
veterán
Azt az egyet **rvara elfelejted, hogy az AVX-512 nem csak a szelesebb vektorokrol szol. Mint ahogy az AMD64 sem csak dupla szelessegu cimzest es dupla szelessegu regisztereket hozta, hanem egy csomo mas elonye is volt. Pl. a tobb altalanos celu regiszter kapasbol baromi hasznos, es ezt _is_ hozza az AVX-512. Ha egy fordito annyira bena, hogy csak 128 vagy 256 bit szeles vektorokra tudja szetdobni a kodot, az AVX-512 mas elonyeibol (pl. scatter-gather, csak hogy egyet emlitsek) akkor is fog tudni profitalni a program, tud gyorsulni 256 bites vektorokkal is, ha az AVX1/AVX2-hoz hasonlitod.
"Emiatt sem kapcsolja be az Intel a consumer vonalon."
Mit nem kapcsol be az Intel? Az AVX-512-t jelenleg egyetlen piacon levo processzor tamogatja, a Xeon Phi legujabb generacioja (KNL). Az minden, csak nem consumer, raadasul semmilyen "megvagott" verzioja nincs ennek a processzornak, ami barmilyen szinten consumer vonalon bevetheto lenne (vs. mondjuk a Broadwell-EP szeria, amibol van "olcsositott", kvazi mainstream verzio Broadwell-E kodneven).
[ Szerkesztve ]
-
Fiery
veterán
"Az a baj, hogy olyan dolgokról beszélünk, amelyek a GPU-kban már rég benne vannak"
Es? Hogyan hasznalod ki? CUDA? Az csak nVIDIA GPU-kban van. OpenCL? Lenyegeben vege. HSA? Ha-ha...
"És miért nem kapcsolják be?"
Piaci szegmentacio. Egy technikai ceg nem csak technikai kerdesekrol szol. Egy termeket el is kell tudni adni, a profitot maximalizalni, ki kell tudni termelni a boduletes gyar epitesek koltsegeit, a bereket, R&D-t, stb. Nem mondom, hogy nem lenne jo dolog mindenhol bekapcsolni az AVX-et, de -- szerintem -- semmit nem segitene a mostani helyzeten.
-
Fiery
veterán
"abban mindenképpen segítene az aktiválása, hogy a fejlesztő legalább mérlegelje, hogy AVX-et válasszon, vagy GPGPU-t, ne pedig csípőből menjen a GPGPU-ra."
A piacon elerheto CPU-k jelentos resze tamogat AVX-et. Ha nem tevedek, az Atom, Celeron es Pentium szeria nem tamogatja az AVX-et, de azon kivul minden. Tehat minden Core i3, i5, i7, Xeon; AMD vonalon pedig lenyegeben minden processzor. Ha ez nem eleg felhasznaloi bazis, akkor nem tudom, mi az. Ennyi erovel ha GPGPU-ban gondolkozol, ott meg az egyetlen ertelmes megoldas a CUDA -- de azzal a piacon levo GPU-k hany szazalekat tudod megcelozni? 20? 30? Talan... Hiszen hiaba a dGPU piacon az nVIDIA nagy folenye, az eladott GPU-k nagytobbsege Intel, az meg nem tamogat CUDA-t. Az OpenCL es HSA-val meg elo ne gyere, mert mar 10 eve varjuk az attorest, es mindig jovore kovetkezik be
Sz'al majd 2018-ban terjunk vissza ra...Egyebkent a merlegeles fejlesztoi oldalrol sokszor nem arrol szol, hogy melyikkel mekkora felhasznaloi bazist tudsz celozni, hanem sokkal inkabb arrol, hogy mekkora teljesitmeny elonyt tudsz elerni adott mennyisegu befektetett munkaval/energiaval. Ha a -- mar meglevo SSE kodhoz kepest peldaul -- AVX1/AVX2-vel mondjuk +50% gyorsulast tudsz elerni, de a GPU-val (egy izmosabb dGPU-val) meg +200%-ot vagy +500%-ot, akkor az AVX-et nem csoda, ha a GPGPU vonal izgalmasabbnak tunik fejlesztoi szemszogbol. Persze aztan sokan eljutnak oda, hogy a jo kis x86/x64 binaris az igazi
-
#229
Fiery
veterán
Petykemano
#227
Fiery
veterán
válasz
Petykemano
#227
üzenetére
Alapveto kulonbseg van a x86/x64 vonal es a GPGPU vonal kozott. x86-on ha egyszer, veres veritekkel optimalizalod a kododat -- adott esetben assembly betetekkel -- SSE/AVX1/AVX2/AVX-512-re, onnantol minden, ezeket az utasitaskeszlet kiegesziteseket tamogato processzoron hibatlanul fog futni a kodod, modositas es bibelodes nelkul. A jelenlegi es jovobeni ilyen processzorokkal sem lesz, nem lehet gond. A kodod, az elkeszitett szoftvered ezzel "future proof".
GPGPU vonalon viszont 2 lehetoseged van. Vagy CUDA, es az NVCC-vel binarist forditasz adott compute capability-t celozva. Ez tok jo, csak ugye ha jon egy uj GPU generacio (pl. Pascal), akkor ahhoz forditanod kell (marmint celszeru megtenni) uj binarist, tehat nem tudsz altalanos ervenyu binaris kodot kesziteni, ami minden jovobeni nVIDIA GPU-n is egyforman remekul fog futni. Vagy CUDA+OpenCL vonalon tudsz kernel source-ot szallitani a szoftvereddel, de akkor meg on-the-fly kell forditani, kiteve magad annak a problemanak, ami mar 10 eve nincs megoldva, azaz hogy a CUDA/OpenCL fordito lehet, hogy lefagy, crash-el vagy csak ugy altalaban sz*r binarist fordit az adott vason, amin epp futtatjak a szoftvered. Tehat az x86/SSE/AVX binarissal ellentetben, az on-the-fly forditott GPGPU kod futasa es az eredmeny helyessege abszolut nincs garantalva. Hasonlo, mint az orosz rulett, csak nem hal bele senki
[ Szerkesztve ]
-
Fiery
veterán
Nem a nyelv a lenyeg, hanem az elv, amivel az egesz mukodik. De hagyjuk is, hiszen jol lathato, hogy sem az AVX, sem a GPGPU nem tud elterjedni, hiaba erolteti oket tobb ceg is.
A GPU team budzsejenek megvagasa pedig SZVSZ eleg egyertelmu, hogy miert tortenik. Kulso ceget fog felvasarolni az Intel (Imagination?), vagy valakitol (RTG?) licencelni fogja a GPU technologiat, a mostani GenX pedig megy a kukaba, ahova valo. Ennel vadabb teoriakrol is beszelhetunk, pl. Qualcomm-Intel fuzio, de felesleges, hiszen ahogy irod is, elso korben a mostani, vastagon leszerepelt Intel CEO-t kellene eltakaritani.
[ Szerkesztve ]
-
Fiery
veterán
"Az Intel nem tud licencelni, mert az AMD nem licencel. Ez nem vita tárgya"
Persze, hogy nem vita targya. Hanem megbeszeles targya, papirozas es sok penz. Minden elado, csak a megfelelo árat kell megtalalni.
"Tulajdonképpen az Intel minden egyes új interfész támogatásával késne az AMD-hez képest egy évet."
Miert, most nem ugyanigy van? Sot...
Sz'al majd 2018-ban terjunk vissza ra...
Új hozzászólás Aktív témák
ph Minden modell tuningolható lesz, illetve a nyolcmagos verziók mellett lesznek kevesebb maggal rendelkezők is.
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen