CEO nVidia-e to povedal

NVIDIA Says It Spends 20% Time on Hardware & 80% Time on Software As First DGX H100 Systems Roll Out
May 1, 2023
https://wccftech.com/nvidia-spends-20-percent-time-hardware-80-percent-t...

Ono totiž moderná CPU s akcelerátormi, čipletmi/dlaždicami potrebujú podobný stav podpory v softvéri, ako to potrebujú GPU. Ešte nie úplne identický, ale blížime sa k tomu.

No mna sameho by ma zaujimalo kolko % zabera samotne AVX512
nikde sa mi to nepodarilo zistit.
Ale oproti GPU je to CPU fakt malickate aj ked ich tam date 16

Ono jedna zmena na riadku 3372 v zdrojáku power save state má väčší vplyv

--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -3372,6 +3372,7 @@ static const struct x86_cpu_id intel_epp_balance_perf[] = {
* AlderLake Mobile CPUs.
*/
X86_MATCH_INTEL_FAM6_MODEL(ALDERLAKE_L, 102),
+ X86_MATCH_INTEL_FAM6_MODEL(SAPPHIRERAPIDS_X, 32),
{}
};
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commi...

While using the "powersave" governor in its default configuration on
Sapphire Rapids systems leads to much lower power, the performance is
lower by more than 25% for several workloads relative to the
"performance" governor.

A 37% difference has been reported by www.Phoronix.com
https://www.phoronix.com/review/intel-spr-one-line

Ja to vidím tak, že Intel uvedie 512 variant podpory AVX inštrukcií a nazve to "AVX-512 support".

https://en.wikipedia.org/wiki/AVX-512#CPUs_with_AVX-512

ako vidno z tabulky, po 2019 je to uz "relativne ukludnene", ja tam konstantna NEpodpora nejakych styroch instrukcii, zbytok je akoze podporovany (parial bordel tam robi akurat alder)

ale v pociatkoch a niektoych inych CPU z 2016-2020 tam bol neskutocnyyyyyyyy bordel

Pokud se ptáš na nějakou klasicky využitelnou aplikaci, kterou používají i zcela běžní lidé a ne jen hrstka "raketových inženýrů", tak je to Emulátor RPCS3.

Je to zdarma, je to o prostá zábava a pokud chceš mít dostupnou knihovnu kultovních her, které nikde jinde na PC neuvidíš - je pro tebe AVX512.
Emulátor to využívá poměrně masivně - přínos je viditelný.

Těch kvalitních her co lze jedině takto provozovat na PC je hodně: RedDead1, Uncharted 1,2,3, Ratchet a Clank, Gran Turismo.

Dnes už to jde obejít s pomocí silných Raptorů, které mají i s AVX2 hrubou sílu a hodně fyz jader. Ale AVX512 má reálné použití

Ja tomu az tak nerozumiem, ale skor som mal pocit ze AVX-512 je rozsirenie starsich AVX2 registrov, ktorych bolo 16 po 256 bit. AVX512 ma 32 registrov/ "vektorov" po 512 bit, z ktorych kazdy moze byt chapany ako 8 double precision floatov po 8 bajtov, alebo 16 floatov po 4 bajty, alebo 8 64-bit integerov, alebo 16 32-bit integerov. A na nich je mozne robit jednou instrukciou naraz nejake operacie. Napr. 8 nasobeni, alebo nejake bitove operacie cez masky, rotacie, bit shuffling atd. https://www.intel.com/content/www/us/en/developer/articles/technical/int...
Priamo maticove nasobenie som nenasiel, ale mozno som zle hladal. https://docs.oracle.com/cd/E37838_01/html/E61064/gsesq.html

Preco ma vyznam pridavat zlozite instrukcie (mozno aj tie tenzorove) do CPU je ten, ze je "general purpose". Da sa na nom urobit cokolvek (na rozdiel od GPU) a akekolvek zrychlenie sa hodi. Na GPU je program, ktory sa nejak zlozito vetvi prakticky nemozne urobit, pretoze je to SIMD - skupina procesorov vykonava ten isty kod na roznych datach.

Latence, jednoduchost a dostupnost. Než se data dostanou do GPU, už jsou dávno zpracována v CPU a klidně ani nemusí opustit L1 cache. A programátor ani nemusí nic složitého řešit. Buď přidá pár instrukcí přes asm nebo intrinsics, nebo jen zapne autovektorizaci (ta sice stoji za houby, ale je v podstatě "zdarma"). Typicky je tedy třeba možné kombinovat skalární a vektorové úseky kódu v jednom algoritmu. Skalární část připraví data, vektorová je spočítá a další skalární část zpracuje výsledky. Samožejmě, pokud je celý algoritmus o relativně jednoduchém zpracování obrovského množství dat, pak je lepší to poslat do GPU a vyřešit všechny komplikace s tím spojené.

Este doplnim to, co napisal xR:

Vypoctove bloky GPU vo vseobecnosti nepodporuju vetvenie. Neviem uz, ako dnes, ale svojho casu, ak si niekde nejake vetvenie mal, tak sa robilo tak, ze vetva ktora sa nevybrala, sa proste skonvertovala na instrukcie No Operation. To znamenalo, ze vetva sa sice nespracovala, ale cas v procesore zabrala. Preto potom klesal hruby vypoctovy vykon. Bolo to technicke obmedzenie, pretoze instrukcie boli do vsetkych jadier na jednom CU strkane po tej istej zbernici, takze nutne vsetky museli spracovavet ten isty kod. Akurat pracovali nad inym fragmentom velkeho bloku dat. Takze kod, ktory potrebuje vetvit, ma na GPU mizerny vykon. Kod, kde mas vypocty nad sirokymi vektormi prekladany vetvenim, bude mat tiez pomerne mizerny vykon.

Takze vyhoda GPU pri spracovavani vektorov sa ukaze vtedy, ak mas fakt velky datovy subor, nad ktorym potrebujes vykonat jednu operaciu za druhou. Ak zapocitas latenciu danu tym, ze data z pracovnej oblasti CPU musis dostat do pracovnej oblasti GPU a potom spat, mozes dojst k zaveru, ze ten subor musi mat radovo desat- az statisice prvkov, aby sa to oplatilo. Pripadne sa to moze oplatit, ak konecna stanica (alebo povodny zdroj) tych dat je graficke rozhranie. Vtedy usetris jednu cestu dat z GPU na CPU, alebo spat.

Veci ako napr. praca s vektormi v CAD softoch, kde mas vektory dlzky 4 (3-rozmerne suradnice sa kvoli jednoduchsej matematike pocitaju cez 4-rozmerne vektory) a operacie mas prekladane vetvenim, stale bezia rychlejsie na CPU so SIMD.

Jj ale to nás jako uživatele zajímat až tak nemusí. Auta taky nevybíralme podle toho, dobře nebo špatně se tam vyměňuje palivový filtr

To bylo z pohledu vývojáře Linuxového jádra. Z pohledu programátora uživatelské aplikace je to naopak asi nejpřívětivější vektorové rozšíření (hodně registrů, masky, lepší instrukce, ...).