Názory k článku
Intel představil AVX10 jako lepší AVX512 i pro E-jádra

Slušelo by dát odkaz na článek od pana Olšana, když už jste ve stejné skupině :-)
https://www.cnews.cz/clanky/intel-avx10-reseni-problemu-se-simd-na-malych-jadrech-ale-mozna-take-umiracek-avx-512/

Ten článkek ale napsal někdo, kdo tomu očividně moc nerozumí. Např. hned v začátku tvrdí, že SSE má jen 8 registrů, v 64-bit režimu má ale 16, stejně jako AVX.

Na konci článku zase filozofuje nad tím, jestli AMD bude AVX10 podporovat, což je další nepochopení, protože AMD už podporuje AVX-512, takže implicitně nebude mít problém s AVX10, protože nově tyto instrukce teď mají požadavek AVX-512 nebo AVX10 - takže software si jen přes CPUID zjístí, co bude potřebovat.

28. 7. 2023, 19:23 editováno autorem komentáře

Nebylo by lepsi komentovat to pod tim clankem?

A když tu je odkaz na Phoronix, tak jdeš komentovat na Phoronix?

Rozhodně by mi přišlo lepší kritizovat článek pod článkem, než u nějakého odkazu k němu. Zvlášť pokud bych se chtěl navážet do autora. Ale já u Phoronixu nemám účet, a kvůli komentáři si ho vytvářet nebudu. Navíc je tam změna jazyka.

Vy účet na Cnews nejspíš máte, protože je spárovaný s rootem. Komentovat a kritizovat autora na místě, kde na to autor může reagovat, je tedy otázka asi dvou kliků.

28. 7. 2023, 21:15 editováno autorem komentáře

AVX10 je AVX-512 s max. 256-bit registry. Lepší to není, spíš znouzectnost a absolutní fail dohnat AMD, které má teď AVX-512 v celé produktové řadě.

To je právě to slovíčkaření. Je jasné, že v principu je to omezenější implementace umožňující nahodit "AVX-512" i na E-jádrech. Jeden v tom klidně může vidět 1. fail a 2. snahu dohnat AMD (to první neberu, to druhé je pravda). Ale jiný v tom může vidět logickou cestu, jak implementovat jakkoli okleštěné AVX-512 tak, aby bylo možné takové úlohy pouštět i skrze hybridní architektury. Jestli to bude zlepšení oproti pre-AVX10 stavu, ukáží aplikace. Jestli to Intelu pomůže ukáže čas. Podle mě spíš ne, protože Zen5 už je na cestě a zatím nic nenasvědčuje tomu, že by se Intel vyhrabal ze svých výrobních problémů, ať už vlastními procesy, nebo vylepšeným nasazováním TSMC procesů (což na GPU Arc fakt nezvládl).

Lepší to bude, protože AVX-512 má řadu vychytávek, které AVX2 nemá a nikdy mít nebude. Takže logicky, pokud Intel neumí udělat efektivní double pumping, tak jak to má Zen4, tak to musí udělat jinak, a toto je cesta.

Je to už dlouho co lidi volali po "AVX-256" - A Intel to těm lidem právě dal. S čím ale Intel moc nepočítal bylo to, že AMD se implementace AVX-512 povedla nad očekávání a tyto intrukce jsou teď i v consumer segmentu, takže Intel ať bude chtít nebo ne, stejně časem bude muset AVX-512 přidat všude, protože je teď v nevýhodě.

citace: Intel ať bude chtít nebo ne, stejně časem bude muset AVX-512 přidat všude, protože je teď v nevýhodě.

Kdyby to nejak rozumne a levne slo, asi by to uz udelal (nejakou pomalou implementaci AVX-512 na E-jadrech).

Pomalá implementace je právě ten double pumping. I ty malé jádra mají AVX2, takže AVX-512 je v podstatě jen problém dekodéru. A CPU, který umí AVX10 v podstatě umí AVX-512 s 128-bit a 256-bit vektorama.

AMD ukázalo dobrou cestu a jediné co by měl Intel udělat je držet se té cesty u jejich power efficient jader. Nikdo nepotřebuje 2x512-bit FMA. Stačí 1x512-bit complex shuffle a AVX-512 implementace je hotová včetně velmi praktického AVX512_VBMI2.

"intrukce jsou teď i v consumer segmentu, takže Intel ať bude chtít nebo ne, stejně časem bude muset AVX-512 přidat všude, protože je teď v nevýhodě."

Řekl bych to trochu jinak.
Ano, instrukce jsou teď v běžných CPU.
Aplikací co je používají přibývá.
Protože benefity to má slušný.
(I když chvíli to vypadalo, že AVX512 je slepá ulička)
Za pár let to bude nutnost i pro "málá" jádra.
Těch aplikací bude hodně. A hlavně to budou MT aplikace. A právě mála jádra se uplatní při MT zátěži.

(křivej) rovnák na vohejbák E jader.

Proč by nemohlo jít, aby některé jádra podporovala víc instrukci než jiná? OS by při unknown opcode exception daný thread přehodil na jádro, které to umí, a poznamenal si, že na malá jádra toto už dávat nemá. A nemuselo by se řešit nějaké zakazování AVX512, sjednocování sad apod.

Presne tohle me napadlo taky, ale bohuzel Intel byl rychlejsi a prakticky neexistuje mixed-ISA cpu, protoze ty rozdily rychle zahladil update.

Paradoxne mozna duvod proc tohle nejde udelat je, ze by CPUID a flagy museli byt per-jadro, coz jaksi odporuje zazitym zvyklostem.

Mixed ISA by slo asi slozit na 2S platforme, kde se osadi nejaky obyc xeon bronze/silver a do druheho socketu gold/platinum - ale podle me to "znackovy" bios odmitne nabootovat a bude trvat na stejnem modelu CPU.

Hmmm myslenka hodna otce Fura. Tisice lidi si lamou hlavy jak to jadro napsat tak aby nedochazelo ke switchum. Je to sedsakra "draha" ( cache ) operace a ty tady tvrdis, no problemo switchnem se na jiny jadro.
To uz by byl mnohem lepsi pristup, zamknout thread na konkretnim core ktery tu instrukci podporuje ( affinita ).

Lze leccos, otázkou jsou nechtěné vedlejší dopady. Režie přehození na jiné jádro by možná byl ten menší problém. WTF související s trvalým požadavkem na P jádro může být horší. Představte si, že po zdánlivě nesouvisející změně najednou procesor nebude využívat všechna jádra, případně aplikace začne žrát více baterie. Důvodem bude jedno malé použití AVX-512 (které tam může hodit kompilátor automaticky => nemusíte o tom mít tušení). Reálně se tak AVX-512 použije jen na začátku, ale podstatný vliv bude mít celou dobu.

Podobné WTF by mohla přinést i knihovna třetí strany. Prakticky by to incentivizovalo nepoužívat AVX-512, dokud si o to autor aplikace neřekne explicitně.

Protože v hodněvláknových aplikacích mívá ta aplikace jen jedno OS vlákno na jádro a ta vlastní výpočetní vlákna si přepíná ve vlastní režii. Různých implementací green threadů, task poolů a podobně jsou mraky a nepotkal jsem jediný, který by bez úprav zvládl fungovat na něčem takovémhle.

Takže by to znamenalo, že mnohovláknové aplikace by si obvykle naspouštěly moc OS vláken, které by se nakonec praly o pár velkých jader a na malých by neběželo nic. Buďto by to byl totální průšvih, nebo by to bylo rozšíření, které by si zapnul málokdo.

Protože Intel zjistil, že to je naprosto nepraktické.

Dnes když aplikace/knihovna detekuje nějaké rozšíření, které má benefit pro některé základní operace, tak chce to rozšíření použít. Takže to dopadne tak, že už jen zavoláním memcpy se např. může použít AVX-512, protože tato implementace bude nejrychlejší. A tato funkce není jedinný případ. Runtime nebo link dispatch pro optimalizované funkce je dnes hodně oblíbený.

V praxi by to dopadlo tak, že 99.9% procesů by běželo na těch performance jádrech.