Vlákno názorů k článku
Na procesorech Intel Alder Lake lze provozovat AVX-512 od JVr - Hmm má to vlastní plánovač ne? To ten mikrokód...

Hmm má to vlastní plánovač ne?

To ten mikrokód plánovače neumí úlohy vyžadující AVX-512 přesunout na Golden Cove, aby nebylo nutné Gracemont vypínat? Toto se tváří spíše jako určité SW omezení. Otázka zda úmyslné, nebo byli v Intelu líní to řešit.

Spis asi zadny OS planovac neumi heterogenni systemy - kdy mate ruznou sadu flagu z CPUID. Mozna nebliz k tomu bude ten slovensky CPU co umi provozovat ruzne arch na hw urovni, protoze treba u M1 bezi x86 v soft virtualizaci / JITc.

Ono není tak snadné poznat, která větev vyžaduje AVX-512. Chce to součinnost překladače.

Pokud byste to chtěl řešit v plné obecnosti, tak se to nezdravě podobá takovým těm standardním příkladům nealgoritmizo­vatelných úloh.

Plná obecnost zde není potřeba. Máme několik málo množin podporovaných instrukcí na konkrétním procesoru podle toho kolik architektur/ rozšíření podporuje. Máme kód, ve kterém určité basic bloky https://en.wikipedia.org/wiki/Basic_block obsahují určitou množinu instrukcí. To lze porovnat a umím si představit, že by to mohl akcelerovat hardware a scheduleru poskytnout nějaké info/ vyhodit něco jako výjimku/ přerušení nebo co já vím. Je to vlastně dost jednoduchý lookup a natáhnout si dostatek instrukcí dopředu už procesor stejně dělá kvůli spekulacím. Taky by možná bylo možné kompilátorem do kódu přidat nějaké hinty, co kde spouštět, což by využil scheduler.

Čistě technicky vlastně není nepředstavitelné, že by nemohl mít jeden procesor i jádra více architektur. Tak by se holt muselo pár věcí v kompilátoru a jádru operačního systému poštelovat/ dodat podpora. Do jisté míry už něco takového děláme se síťovkami, GPU atd. když jim říkáme "tady máš kus paměti" dělej si s tím co potřebuješ a řekni mi až ty změny budou relevantní. Operační systém by se tak zase přiblížit realitě hardwaru a prostě by si musel výrobce zkontrolovat, že jeho soubor zařízení/ mix architektur je podporovaný.

Dokud se nedokáže, že to nejde, tak bychom se měli přiklánět k tomu, že to nějak inženýrsky dostatečně dobře řešit jde. Ještě lepší otázka je, jestli to je výhodné řešit a nebo třeba mít nějaký seznam programů, které prostě i na menších jádrech poběží, což můžou být prakticky všechny systémové procesy a jinak vše spouštět na velkých jádrech - tedy typicky neznámé aplikace. Nakonec, operační systém tu je hlavně proto, aby to měly aplikace jednodušší. Počítač si kupujeme aby nám řešil problémy a ne abychom tam měli Windows nebo Linux, to nám jen umožňuje řešit nějaké množiny problémů lépe/ pohodlněji/ vůbec.

Nemá to plánovač. Umí to jen doporučovat scheduleru v OS, které vlákno by bylo vhodné přemigrovat z P na E nebo naopak. Sám procesor mezi jádry samozřejmě žádné vlákna přehazovat nemůže.

Binárky ani dynamicky linkované knihovny si v hlavičce nenesou informaci, zda obsahují AVX512 instrukce a statická analýza by byla značně komplikovaná (v obecném případě stejně jako halting problem, tedy algoritmicky neřešitelná). V praxi by to znamenalo, že by se AVX512 instrukce poznala až v dekodéru E jádra, to by zahlásilo fault operačnímu systému a ten by musel uvolnit P jádro a nastavit ho do stavu E jádra a pokračovat ve výpočtu tam. Hrozný opruz a velký zásah do choulostivého kusu softu, kterým scheduler je.

Může se nám to líbit nebo ne, ale dříve nebo později to asi budou dělat všichni. Myslím si, že se dočkáme možná i více úrovni než dvou. Při daném limitu tranzistorů bude heterogenní procesor dávat v běžných úlohách větší výkon. Špatně paralelizovatlné části aplikace mají raději méně výkonných jader a dobře paralelizovatelné zase více jader. Reálné aplikace jsou kombinací obou. O spotřebu BTW příliš nejde. Limitem je počet tranzistorů a jak v daném limitu co nejlépe ohnout Amdahlův zákon.

Staticka analyza velice lehce odhali pouziti AVX512 - zkousel jste nekdy pustit objdump s volbou vypisu disasm? To staci grepnout. Bavime se samozrejme o sluznych binarkach - ktere maji const NX kodovou sekci, a nejsou komprimovane.

A samozrejme by to OS mohl odhalit pouzitim invalid-opcode vyjimky cpu. Zasah to neni veliky - existuje treba podobne implementovane nektere nahrazky instrukci.

A jeste existuji instrukce, ktere AVX nazhavuji predem - protoze ta jednotka neni trvale napajena a taktovana, takze by ten hw scheduler mohl poskytovat informace z tohoho pohledu (v podstate to neni invalid-op, ale ocekavani invalid op - takze by to slo preplanovat bez nutnosti restartovani instrukce).

Nevim, co je neslusneho na apce, ktera se sklada za chodu aby se v kriticke sekci vyhla podminkam typu pokud mam avx tak tudy jinak tudy, komprimovanych, obfuskovanych, tahajicich kod ze site atd. A co treba quemu, ktere zadne avx512 nema ale apka spustena e virtualu uvnitr uz jo? Co java, ktera avx512 obsahuje ale JIT ji emitne jen v extremne vzacne, v beznych aplikacich nikdy, bude kvuli tomu vzdy locknuta n P jadre? Zakazeme avx512 v jadre OS a ovladacich aby se nemohlo stat, ze to zavola apka na E jadre? Atd.

Invalid opcode fault by se chytat dal. Psal jsem to. Ale zeslozitilo by to scheduler. Kdyz si predstavim, ze by se to mohlo stat v ring 0 nebo dokonce -1 tak me z tych moznych deadlocku beha mraz po zadech.

Spravna cesta je pres ten fault, staticka analyza je v praxi znacne nefunkcni vec. Jsou aplikace, ktere treba generuji kod dynamicky, umel bych si predstavit, ze prave tam to AVXko bude.

To, ze nas ceka doba kdy scheduler toto bude muset nejak uvazovat je z meho pohledu celkem jasna vec.