Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Nevím jakou přesně plochu zabírají AVX-512, ale vím jakou zabírá iGPU. Pro Intel by nebyl problém udělat dvě základní třídy grafik - jednu výkonnou i pro občasné hraní a druhou co nejmenší (naprostý základ) jen pro 3D efekty OS a přehrávání všelijakých multimédií. To základní by samozřejmě měla většina jejich CPU, takže by za ta léta ušetřili řádově více plochy než co jim sežerou AVX-512.
PS: Čekal někdo jinou reakci představitele Intelu? Svět je v tomto předvídatelně nudný. Intel přiznává chybu až když to jinak nejde nebo už má za rohem připravenou „opravu". A zrovna Raja je méně důvěryhodný než Horst Fuchs.
Nechápu o co Linusovi jde. AVX-512 jsou instrukce pro velmi specifické účely. Nikdo je nenutí nastavit kompilátor k tomu, aby se usilovně snažil optimalizovat obecný kód k použití těchto instrukcí.
Jo kdyby to bylo o nastaveni kompilatoru. Aby doslo k opravdu optimalnimu vyuziti AVX-512 tak se optimalizuje hezky rucne po staru v assembleru. Muj oblibeny priklad je zdrojovy kod x264, kde jsou ty optimalizace hezky videt.
No právě. Ty instrukce mají smysl jen tam, kde je to pro ně napsané. A když už si s tím někdo dá práci, zůstane tam i ta starší alternativa a způsob, jak si automaticky vybrat.
Podobných problémů bude přibývat, jak se začínají prosazovat CPU s kombinací výkonných jader, která umí všechno, a úsporných jader, která něco nepodporují. To se bude týkat mnohem více fíčur. Tam to bude chtít i nějaký nový přístup ze strany OS, aby běžící proces dokázal přepnout na alternativní cestu v kódu, když se OS rozhodne přesunout běh na jádro jiného typu.
Myslím ,že už AMD s 3DNOW! před léty zjistilo , že kde není široká implementace je k ničemu i samotná instrukční sada byť ..."i náš procesor je vybaven pro budoucnost"
Pokud Intel sadu AVX 512 stále mění , pravděpodobnost ,že se bude softwarově využívat přijde až v době ustálení vývoje a podpory stálé řady instrukcí obsažených ve většině CPU ....
Ale pokud je AVX512 už teď poražena paralelním zpracováním dat na GPU , tak je jasné že implementovat by se mělo z jiné strany ,a ještě jestli vůbec ...Tady mi Koduriho výkřik pomalinku dává smysl ....byť jde o osamělou misi subdivize jedné mocné firmy.
Koduriho výkřik do tmy...
Ne všechno jde akcelerovat na GPU. Typicky pro fyzikalni vypocty ve strojirenstvi to napriklad nejde (nebo to dosud nikdo neimplementoval). Tyhle softwary navic maji per-core licencovani a kazde urychleni ma tak doslova cenu zlata.
Tak zrovna AVX512 je "teoreticky" uplne super a vyplnuje spoustu der co do pouzitelnosti. Umoznuje mj. jednodussi vektorizaci jak pro kompilator, tak pro programatora v assembleru. Hlavni problem je v implementaci v SKX (kde sizuje takty) a "neimplementaci" v mid- a low-endu a AMD. Existuje spousta moznosti, jak pomoci AVX512 zrychlit i uplne normalni kod, ale z vyse uvedenych duvodu je to momentalne problem (mj. to komplikuje vyuzitelnost v knihovnach). To, ze se to jmenuje AVX512 neznamena, ze je programator musi vyuzit 512b registry. K dispozici jsou 256b i 128b bez omezeni (na CPU, ne na Phi). Stejne tak muze CPU 512b instrukce interne rozkladat na mensi a porad tu bude prinos. Co se tyce te roztristenosti, tak to neni takovy problem, jak to vypada. Kdyz se ignoruji sady pro Phi a AI, tak je to vicemene zpetne kompatibilni a existuji jen dve sady (F-VL v SKX a F-VL + zbytek v ICL). A nakonec - mit vic jak jednu verzi fci u kterych zalezi na vykonu neni zadny problem. Pro x64 je to napr. zakladni SSE2 a pak napr. SSE4.1, AVX2 a AVX512VL. Runtime dispatcher zvoli tu spravnou podle detekovanych features. Ja to tak delam uz hodne dlouho a funguje to bezvadne. Pokud by to Intel zacal davat do vsech CPU a implementovat poradne (a pridala se AMD), tak je to vetsi prinos, nez vetsi pocet jader, kde je problem Amdahl's law.
Co myslite tim "normalnim kodem" ?
Neprijde mi ze by AVX512 byla jakakoliv revoluce nad ramec toho, co dovolovalo mmx/sse. Pokud se bavime o zpracovani dat, ktere jdou resit skrze SIMD, tak ano - rychlost to prinese pac se zpracuje vice dat najednou, ale tomu se tezko da rikat normalni kod.
Tak AVX512 pridava spoustu uzitecnych veci jako masky, scatter/gather (gather v horsi podobe byl uz v AVX2), vetsi orthogonalitu instrukci (napr. plnou podporu pro signed/unsigned, porovnavani, 64b integer, ...), vektorove bitove operace, ternarni logicky operator, plne 2-registrove shuffly atd. S trochou invence ted jde temer kazda rozumna vypocetni smycka efektivne vektorizovat a nekdy dokonce zrychlit i bez vektorizace. Samozrejme, hodne veci jde udelat i s drivejsimi sadami, ale je to tezsi. Revoluce to samozrejme neni, ale je to krok spravnym smerem.
Dik, to je zajimavy.. jsi me navnadil! je nekde nejaka dobra literatura k tomu? Nemyslim instrukcni reference, spis treba prakticke ukazky
To je dobra otazka. Ja jako samouk bohuzel o nicem moc nevim. Mozna to je taky duvod, proc tohle moc lidi neumi :). Zakladem jsou prave ty referencni manualy, praxe a odhodlani. Zacit jednoduchyma vecma a zdokonalovat se. Samozrejme jdou ruzne priklady vygooglit. Dobre je cist i diskusni fora (napr. realworldtech.com, community.intel.com, InstLatX64) a blogy lidi, co to umi. Napr. Travis Downs, Daniel Lemire, John McCalpin atd. Hezke ilustrovane priklady jsou taky ve firemnich prezentacich, hlavne u Intelu.
OK, vem si ale jednu věc - AVX-512 rozšiřuje 16 registrů z 256bitů na 512 a přidává dalších 16 512-bitových. Kdykoli procesor mění kontext (přepíná z jedné úlohy na druhou), musí všechny tyto registry navíc uložit a nahrát kontext druhého procesu, to dává dalších 12kB dat potřebných uložit / nahrát jenom při změně kontextu.
Že to nepoužíváš neznamená, že tě to nebrzdí. :-)
Nebrzdi, protoze s nejvetsi pravdepodobnosti ani nemas procesor, ktery by tuto instrukcni sadu mel. Bezne cpu i7 ani i9 10. generace nemaji AVX-512, pouze AVX2.
AVX-512 je otazkou rodiny Xeon a od nich odvozenych procesoru (napr. Core i9-109??X) Cili jde o profesionalni sferu a tam dle mehou soudu takova instrukcni sada spise pomaha, nez skodi.
Do mobilni sfery takova vec pak vubec nepatri, teda alespon v dnesni podobe.
Jiz od dob FP instrukci existuje flag, ktery identifikuje skutecne pouziti nadstandardnich registru, takze pri zmene kontextu se nemusi ukladat a obnovovat vsechno. Navic tyhle zmeny kontextu skonci bud v L1 nebo zustanou viset v ROB, takze v pripade malo aplikaci nejde o tak strasnou vec.
Btw mas tam chybu: 16*256 + 16*512 = 12kbit, ne kB. tudiz jde o +1.5KiB jenom, a vsechny nadstandardy dohromady tvori 2.5KiB kontextu a uklada se jenom to rozsireni, ktere je nutne, skrze XSAVE/XRSTOR.
https://events.static.linuxfound.org/sites/events/files/slides/LinuxCon_...
Typicky na systemu nebezi vice nez jedno vlakno per cpu, ktere je vypocetne narocne, tudiz kontexty se nestridaj. Takze pokud uvazujeme o 16C x 100 aktivaci vypocetniho vlakna, mame 1.6K x 2.5KiB * 2 (load/store) = 8 MiB/s hit. Ve srovnani s 76.8GB/s na pametech (4ch-2400MT/s) to je cca 0.1 promile - kdyby neexistovala zadna cache.
Jo, máš pravdu. Můj komentář byl v podstatě takový joke / rýpnutí do extrémních tuničů, které by mohlo na.rat, že tam mají sadu, kterou jednak nevyužijí a ještě je může brzdit, ale bity s byty jsem si popletl, to jo. Je jasné, že ukládání / obnovování AVX-512 registrů je v podstatě nic i pokud bereme jenom samotné přepnutí kontextu - tam si teď zejména Intel nasekal potřebu jiných procedur při ochraně proti všem těm Meltdownům a Spektrám, ty cache je potřeba "propláchnout" řádově většími objemy dat, než obsah AVX registrů.
. (smazat)
No a to je možná ten problém. Kdyby místo "instrukcí pro velmi specifické účely" mělo x86 něco jako SVE nebo RV32V/RV64V, tak by se žilo lépe tvůrcům kompilátorů, tvůrcům aplikací, a nakonec i uživatelům, kteří pro svůj software potřebují levně koupit vhodný počítač.
Jenže to by bylo právě bylo moc jednoduché. Myslím si, že v tomhle hodně roli marketing jak ze strany výrobce čipů, tak software. Oni moc nestojí o to, aby to bylo jednoduché. Pak se dají snáz vymýšlet různé kličky a ve výsledku ze zákazníka dostat více peněz i za věci, které by ani nepotřeboval. Licencování MS SQL budiž příkladem....
Kazde slovo, ktere Koduri pronese, krici: Ja chci byt CEO Intelu! :-)
jo, to by si chlapec napred musel nechat zvetsit zuby a roztahnout usmev..
Chudák Koduri . Buď ví něco co většině uniká , nebo mluví řečí svého chlebodárce . V každém případě začínám mít velké obavy , jak to nakonec dopadne s první "údajně" konkurence schopnou externí grafikou od Intelu .
" chlebodárce"
nemám pocit, že mu Intel chlieb len tak daruje a Koduri si ho neodrobí ...
Vie to, ze ked pride 5 - 3nm proces TSMC, alebo 7nm a nizsie procesy Intelu, tak spotreba AVX 512 v mobiloch nebude problem. A uz to budu mat pripravene na AI, ktora cochvila na mobily masivne dorazi. Potom bude mozne na mobile rozpoznavat rec, t.j. lokalne nadiktovat smsku a text len poslat, a ine veci.
V desktope/servroch je to potrebne kvoli tomu, ze na GPU bezia veci v lockstepe vo velkych skupinach - nie je to take flexibilne ako na univerzalnych procesoroch.
Az sa AVX 512 presadi a bude ho podporovat CPU u 90% zakaznikov, tak potom, o 10 rokov ho 1% vyvojarov mozno i implementuje do svojho SW.
Presadi sa. Prave sme vo faze adopcie.
A neodpustim si aj malu konspiracku. :) AI v mobiloch vyrazne vylepsi moznosti spehovania ludi. Mobil bude bonzovat, len ked bude treba. Zisti o com sa ludia bavia - prevod do textu. A potom dalsia vrstva, ci kecy nie su politicky zavadne, pripadne komercne vyuzitelne. ;-)
Sa pozri ako dlho to trvalo kym sa zacalo vyuzivat SSE pre koncovych zakaznikov. :)
Tak AVX512 je v podstate "jen" rozsireni SSE, navic jednodussi na pouziti. Kdyby ho, stejne jako SSE, podporovaly vsechny nove cipy (bez dalsich vlivu), tak pridani SW podpory neni problem.
Tak hlavny problem je, ze CPU s podporou AVX 512 ma 1% zakaznikov. A potrva i 10 rokov az ho bude mat 90% beznych userov.
Nevidel bych to tak strasne. AVX512 maji vsechny Intelacke 10nm ne-Atom cipy. Tedy predevsim notebookove IceLake a brzo TigerLake. Nevim, kolik maji (resp. budou) mit % trhu, ale rekl bych, ze to bude vic, nez 1%.
Do ultramobilních a levných notebooků ale půjdou hlavně ty big.LITTLE Intely, kde AVX není vůbec, nejen AVX512 (https://diit.cz/clanek/lakefield-zrejme-nepodporuje-ani-avx-avx-512). Do workstation notebooků zas AMDčka, které maj vícejádrový výkon (a udrží ho dlouhodobě). A co se týče AI v notebookách, to už mezitím obsadí Apple se svými ARMy.
Zde bych to videl jinak - ta sirka warpu na gpu je jiz zhodna (nebo podobna) tomu AVX-512, a zatimco gpu dokaze delat vetveni (byt neefektivne) k zpracovani casti toho vektoru, tak u CPU se porad jedna jen o jeden vektor, ktery se pak dodatecne maskuje.. tj. CPU dotahuje vypocetnim vykonem ono GPU (az se vyresi ten thermal throttling ktery avx aktivuje). Mala ale dulezita vyhoda CPU je pak to, ze na tom bezi klasicky kod a OS, GPU ma precejenom omezenou velikost kodu a architektury se tam meni dost divoce (nemluvne o tom ze se casto maskuji za abstrakce).
Ano, obecný CPU kód dává mnohem více možností než kód pro GPU. V tomhle se mi líbí ARM SVE. Nejvýkonnější počítač světa má jeho fyzickou šířku 512 bitů, tedy stejně jako AVX512 u Intelu. Protože tam je to dotáhnuté pořádně (thermal throttling), tak to překonává i superpočítače založené na výkonu GPU. Je možné, že než se AVX512 rozšíří v x86 (viz můj komentář kousek výše), tak kdo bude chtít výkon, tu brzo bude mít výkonné ARMy - v Apple, a kdo ví, třeba i v PC/Windows (uvidíme, jak úspěch Applu nakopne ostatní výrobce).
Sirka warpu u GPU je 32 pre Turing i RDNA2. To je 1024 bitov. Na GPU bezi paralelne az 125 takych hw warpov pri 4000 procesoroch. Navyse GPU ma oddobu hyperthreadu, kde na jednom warpe moze bezat v pohode i 10 threadov paralelne co zakryva latencie. Spolu teda 40-tisic threadov, ktore riadi HW scheduler, ziaden Windows10, ktory ma problem so 128 threadmi. GPU ma i 10x vysssi bandwidth ako CPU. GPU je na tom stale o 1 rad lepsie v porovnani s CPU, co sa tyka vykonu i spotreby/vykon.
Ze kod na CPU nema limity, tak to je vyhoda pri 4-8 jadre. Ale pri vysokom pocte, tj. 64 jadre uz musis pisat veci efektivne, vyzaduje to experta, inak to efektivne skalovat nebude. Vyvoj algoritmu pre SIMD je tiez daleko narocnejsi nez napisat compute shader. Na GPU mas obmedzenia na to aby zarucili vykonovu efektivitu pre tisice threadov. Je to blbovzdorne a ma to 10x mensie naroky na developera. I v tomto podla mna vyhrava GPU.
Napsat kod na GPU vypada jednoduse, ale efektivita je nekde kolem 10%. A pak se to musi rucne tunit a tunit, abys z toho vymackl alespon 25% propagovaneho vykonu - protoze to neni univerzalni procesor.
Zkouseli jsme delat kodeky nebo zpracovani videa - a gpu HW bylo potreba poradne naddimenzovat - protoze kazde vetveni v shaderu znamena ze se tam neaktivni vetev flaka. Plus vecny problem toho, jak rozdelit ulohu - nechat cykly na scheduleru, nebo je vepsat do compute shaderu. GPU se chova v tomto tezce nepredvidatelne.
U CPU se me pro tyto aplikace omnoho lepe odhaduje narocnost (a u FPGA je to dokonce ze sve podstaty 100% spravne). Kdyz zustanu u tvych cisel, tak gpu (125W) i cpu (64C/128T) ma stejnou miru vykonavani NEZAVISLYCH kodu (u GPU nastava prinos az kdyz vsechny vlakna budou delat totez, aby sli pustit jako sirokej warp - a to pak CPU hezky dozene tim, ze pouzijete SIMD). A kdyz ma CPU 4x vetsi frekvence (no budiz u avx ne docela), tak je moderni CPU zcela ekvivalentni tomu, co pustite na GPU (rozdil to je ale cenovy, pokud se porovnava consumer GPU.. pri srovnani HPC CPU a HPC GPU to je zas nastejno per jednodku vykonu.. trocha takovej kartel).
Takze zrnutie:
64 jadro bez AVX je rovnako rychle ako mainstream grafika pri extremne vetvenom kode.
Az pouzijes AVX na 64 jadre, tak tu mainstream grafiku ani nedorovnas, lebo ti dojde bandwidth, ktory ma grafika daleko vyssi.
Zalezi na aplikaci - BW neni vsechno. Kdyz uvazujeme o souhrnem vykonu 10TFlop@DP = 2x80TB/s do alu, 1x80TB/s z alu = 240TB/s. Takze nejake GPU s 800GB/s a CPU s 80GB/s BW... dovoluje vykomunikovat bud 0.33% nebo 0.033% - nerekl bych, ze pri pomeru 300:1 a 3000:1 je samotna propustnost pameti tim nejvetsim problemem.
To je divne, ja tvrdim presny opak.
...trochu na jiné téma, ale o to zajímavější - "Intel Moving to Chiplets"
https://www.anandtech.com/show/16021/intel-moving-to-chiplets-client-20-...
Pro někoho by mohlo být zajímavé i toto - "Modern CPU Microarchitecture":
https://pcpartpicker.com/user/526christian/saved/dm4CLk
Intel kupi alteru za miliardy a miesto toho aby dodavali nake karty ktore prevezmu vsetky hlavne vypocty tak to seru do cpucka. Hehe.
A kam bys tu kartu dal? Většina počítačů jsou notebooky.
Klidne i do notebooku. Ono FPGA dokaze akcelerovat mnoho veci optimalneji nez cpu/gpu, ale vyzadovalo by to "pozehnani". Bohuzel pristup vsechn firem je takovy, ze technologie vyslovene brzdi a nepousti si na svuj pisecek nikoho.
Ve většině notebooků není místo pro další čipy. Dále PC notebooky jsou jen skládačky komoditního hardware a OS. Většina výrobců ani nemá marže, aby vyvíjely něco sami (stačí se podívat na problémy s ovladači - když notebook koupíte, tak ještě nějak jde, ale pak se stáhnou novější ovladače, a nad těmi už výrobce nemá žádnou kontrolu).
Uvidíme, jak PC svět nakopne přechod Applu k ARM (v jejich SoC je např. neuronový procesor a výkonný enkodér videa). Výhoda Applu je, že zajišťuje i to "požehnání": kvalitní API a přesvědčení výrobců velkého komerčního software, aby jejich technologie využívali (a motivovali tak výrobce ostatního software). Dále je výhoda Applu, že svoje technologie dává do všech modelů včetně lowendu - výrobci software se nemůžou vymlouvat, že část uživatelů daný obvod nemá.
Jinak FPGA byla např. v jedné kartě Matrox. V linuxovém OpenGL driveru jej využili k transformaci T&L, čímž se vytáhli na výkon Riva TNT 2.
U které Matrox karty to mělo být? Nějak mě nenapadá karta Matroxu, která by neměla v běžném stavu výkon TNT2, ale nesla nějaký FPGA, který by jí pomohl výkon zvýšit na úroveň TNT2. Mohl jsem to zapomenout.
G200/G400 a výš integrovaly přímo v jádře RISC procesor (WARP), který byl vybavený dostatečně na to, aby na něm mohlo běžet TnL a nějaký jednodušší vertex shader, ale chyběla softwarová podpora. G400 ale byla i bez toho minimálně stejně výkonná jako TNT2 (pokud v některé hře ne, tak jen díky tomu, že G400 poctivě prováděla trilineární filtraci i při multitexturingu, kdežto ostatní karty to odrbávaly).
"Uvidíme, jak PC svět nakopne přechod Applu k ARM (v jejich SoC je např. neuronový procesor a výkonný enkodér videa)."
Myslis ten NLU, ktoremu v praxi nasobne nakopal prdel ten konkurencny, pouzity v Mate 20 Pro? :)
https://nanoreview.net/en/soc-compare/hisilicon-kirin-980-vs-apple-a11-b...
"Dále je výhoda Applu, že svoje technologie dává do všech modelů včetně lowendu - výrobci software se nemůžou vymlouvat, že část uživatelů daný obvod nemá."
Ono opravdu neni treba orezavat samotny HW (aj ked sa to deje), ked uplne staci zariadenie zabrzdit updatom FW/OS.. :D ;)
1) To je minulost, Huawei už nemůže vyrábět svoje SoC v TSMC a jinde by to byly "horší nanometry", takže by SoC byl nekonkurenceschopný (nižší výkon/vyšší spotřeba/menší výdrž na baterii). Stock SoC nemají takový výkon (např. v NLU) a/nebo jsou o dost dražší (Huawei je nebude moci nabízet v cenově konkurenceschopných telefonech).
2) Lepší možnost rozhodnout se, zda si nainstaluju update (menší výkon, protože nový OS je náročnější na HW, ale zas kompatibilita s novými apps), než nemít tu vilbu vůbec. Navíc iPhony maj nadprůměrný výkon, takže i se zpomalením časem jsou furt na úrovni nových androidů (větší problém - hlavně v minulosti - byla velikost RAM). To tvoje odkazované srovnání bohužel míchá dohromady single a multi výkon CPU, takže není na první pohled vidět, o kolik je iPhone rychlejší pro aplikace v popředí.
Ja jsem zakaznik a mam stejny nazor jako Linus T. ... proc ??? na vypocty mam GPU, ktere je nasobne lepsi a vsemi podporovane.
No a mam AMD samozrejme, takze ten silney Ind asi mysli zakazniky, kteri mu zbyli ;-))) ... grafiku mam nvidia a OS linux.
Mam intel v notebooku a rad bych si koupil AMD nebo uz rovnou nejaky skutecne vykonny ARM, vzhledem k tomu, ze Huawei nesmi pouzivat nove intely a zustava tak na starych, k tomu asi dojde ... prozatim i u netry modelu za 1k euro navysil RAM z 8 na 16GB, hdd nechal 500GB, mozna ze dal moznost 1TB ... a zustal na starych i7 ... vykonove je to jedno, ve spotrebe bohuzel ne ... takze doufam ze tam daji casem ARM a budu jeste vice happy nez doposud ;-))
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.