Vlákno názorů ke zprávičce Intel představil AVX10 jako lepší AVX512 i pro E-jádra od cc - AVX10 je AVX-512 s max. 256-bit registry. Lepší...

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.