Názory k článku
Xeony Granite Rapids v AI výpočtech až třikrát rychlejší při použití instrukcí AMX

tak ten amx bude asi fungovat jako npu v jinych procesorech, ze urychluji maticove operace.
syn se ted na vysce uci matice, tak mu rikam, ze matice jsou dneska nejdulezitejsi nastroj.

Pokud se spotřeba se wattech (EDIT: tedy spíš příkon) skoro nezvýšila a čas běhu šel asi na třetinu, znamená to zhruba třikrát efektivnější výpočet.

EDIT: Vlastně by asi bylo přesnější psát o příkonu než o spotřebě. Příkon zůstal skoro stejný, spotřeba spadla asi na třetinu. Předpokládám, že to bylo tak – kdyby spotřeba zůstala skoro stejná a výpočet se stihl na třetinový čas, asi by se to projevilo na teplotách. Což se podle zprávičky nestalo.

24. 9. 2025, 22:29 editováno autorem komentáře

Nejsem si tak docela jist, zda to reálně k něčemu bude. Než na to zareagují vývojáři SW, tak bude půl dekády pryč a krom toho kdo chce, tak už tuhle třídu výpočtů dávno řeší přes GPU s daleko větším výkonovým ziskem. Teď je v kurzu sdílená paměť mezi CPU/GPU

Veškerou podporu pro AMX do existujícího softu dodal Intel - nikdo to normálně nepoužívá, protože kromě serverových CPU to nikdo nemá, takže to nemá ani jak testovat. AMD touto cestou zřejmě nepůjde a bude radši zlepšovat AVX-512.

Ono to AMX ani není taková sláva. Má sice velké registry, ale ty operace co to podporuje nic moc. V podstatě hlavně maticové operace s velkou restrikcí co se týče datových typů. Vektorové operace to neumí - takže žádné zrychlení pro vektorové DB, atd...

Ví někdo, co OS dělá s těmi 16KiB registrů při context switchi? Je to nějak ošetřené pro tu drtivou většinu programů, co to nepoužívají?
Vlastně je to relevantní otázka i pro AVX. I u AVX-512 jsou to 2 kila.

AMX kód na konci používá TILERELEASE, což vymaže AMX konfiguraci. Pokud se AMX nepoužívá, tak context-switch nic neřeší, pokud se používá, tak se ten obsah těch registrů musí uložit, aby pak zase mohl být obnoven.

Jo, ještě jedna perlička - AMX může používat jen 1 thread jednoho jádra (ne ten druhý v případě MT), takže scheduler s tím taky musí počítat.

No scheduler snad počítá s tím, že aplikace zavolá SetThreadAffi­nityMask() ve Windows, nebo processor_affi­nity() na Solarisu. Na Linuxu nevím, ale předpokládám že i tam už existuje obdobné API.

To by nevádalo smysl. Použití AMX může být někde v nějaké knihovně, která přece nebude nic říkat scheduleru a ovlivňovat tím aplikaci - scheduler si to musí pořešit sám na základě toho který process/thread používá AMX.

AMX je jen CPU extension, nic víc.

25. 9. 2025, 22:41 editováno autorem komentáře

Aha. Na prvním místě je možné AMX používat na obou HT threadech jednoho jádra. Nedojde k problému, jenom jde dolů výkon. Vizte kapitolu 20.17.2 v linku.
https://kib.kiev.ua/x86docs/Intel/Intel-OptimGuide/355308-003.pdf

Na druhém místě mi nebylo jasné, jak se scheduler dozví, že thread použil AMX. Při vytvoření threadu se v registru XCR0 zakáže podpora AMX (a obdobně to funguje u AVX). Když thread poprvé použije AMX instrukci, dojde na trap (NMI) #NM (Device Not Available, 0x07, původně používaný když není k dispozici matematický koprocesor), kernel následně v nt!KiNpxNotAva­ilableFault zapíše do struktury KTHREAD flag HasUsedAVX512, AMX povolí, a navrátí řízení na příslušnou instrukci. Tím se zároveň zapne podpora AMX u instrukcí použitých při přepínání kontextu, ze skupiny XSAVE/XRSTOR. Konkrétně XSAVES má formu optimalizace, kde ukládá kompaktní formu. No a zbytek je černá magie scheduleru: thread s flagem HasUsedAVX512 se nechává co nejdéle běžet na konkrétním fyzickém jádru, na druhý HT thread se nevěší AMX ani latency-sensitive workload, atd. Vše psáno v kontextu Windows; na Linuxu to bude nejspíš dost podobné.

Takže ano, převážně jste měl pravdu. Díky za nasměrování na zajímavý topic.

Ten minulý čas v "přicházely na trh" znamená přesně co? Že byly vydány nějaké modely a budou další, nebo že už to bylo zase ukončeno?