Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Proč mám takový pocit, že to stejně fungovat nebude (nebo bude ale blbě) a pak to zase zruší? :D
za b je spravne a do te doby vymysli neco jineho.
Víc markeťáků než inženýrů...
je to smutne citanie, velmi smutne - cela tato AVX512 intel-telenovela trvajuca uz celu dekadu
instrukcna sada roztriestena jak vajco plestene o stenu, HW podpora je dalsia kriminalka, no hruza
nieco ako tryznenie schrodingerovej kocky, o ktorej nikto nevie ci zije alebo je zdochnuta
intel, vas technologicky lider, od 2017 permanentne v prdeli
ovela smutnejsie ako nejake 3d now! a 3d now!+ u AMD K6-I-II-III pred vyse 1/4 storocim
tam proste hned po par rokoch bolo aspon jasne ze to skapalo, ziadne tyranie a mohlo sa ist dalej na architekturu K7 a neskor K8
Takze to spravia tak, aby sa vlk nazral a koza zostala cela. Defakto sa do AVX2 doplni to, co ma AVX512 navyse a 512bitovy vektor sa urobi volitelny.
To je ale asi stale na rit, pretoze to asi bude vyzadovat dve rozne codepaths, jeden pre 256bitove vektory a druhy pre 512bitove vektory.
Slo by to sice spravit aj tak, ze sirka spracovavaneho vektoru by bola kontextovo zavisla, ale nepredpokladam, ze to tak Intel spravi.
Takže AMD udělalo dobře, že zůstalo u 256bit jednotek. Intel to bude mít v budoucím desktopu podobně. Vídím analogii u těch "revolučních" 2048bit SVE, kde se v reálu používá taktéž jen 128bit/256bít. V rámci efektivity je lepší mít více 256bit jednotek, než tam drtit kombinaci 1x512bit + 2×256bit.
AVX-512 ALU nemá kombinaci 1x512 + 2x256, jen umí společné jednotky takto buď/anebo použit.
Má to přesně takto. 256-bit ALU/FMA jsou na portech 0 a 1 a při výskytu 512-bit instrukcí v pipeline jsou sloučené do jedné 512-bit na portu 0. Na portu 5 je pak jedna komplexni 512-bit ALU (+ FMA u Xeonů), která jako jediná umí cross-lane operace jako ruzné shuffly atp.
Pokud správně chápu, tak budouci Intel big. LITTLE CPU budou podporovat AVX operace s 256-bit vektory, ať už si to marketing nazýva AVX-512 nebo kolik chce.
P-jádra je budou zpracovávat rychle, protože 512-bit ALU (promiňte zjednoduśení) zvládne dvé 256-bit operace naráz, E-jádra s užší ALU je zpracují také, ale pomaleji.
ARM přišel v SVE s volitelnou délku vektoru 128-2048 bitů, což zvládá každá ARM SVE implementace tak rychle/pomalu, jak může.
Intel odpovídá pevnou délkou 256 bitů každé jádro také zpracuje jak může. (možnost 512 zůstane jen pro vlka),
Edit: Jon Snih stihl napsat totéž rychleji :-)
Přijde mi otřesné, že Intel svou neschopností při navrhování čipů otravuje život "lidem od softwaru".
Nejdřív instrukce fragmentoval tak, že se prakticky nedaly rozumně použít a nyní když AMD ukázalo že z AVX512 jde normálně podporovat všechno, tak si vymyslí další speciální skupinu.
Jen doufám, že 10 bude podskupina 512 bez nějakých zákeřných kliček. Takže to AMD dá s prstem v nose.
Já bych řekl, že Intel schopnost návrhu čipů nijak zásadně neztratil, ale není schopný je podle plánu vyrábět a tak musí vymýšlet náhradní plán i náhradní plán pro náhradní plán.
Pokud si Intel sám vymyslí instrukce, které následně není schopný realizovat v použitelné formě, po řadu let!, prakticky do současnosti!, je to pro mě neschopnost. Následně namísto definování AVX256 kde by bylo jasné o co jde, vyplodí něco mimo zavedené schéma s definicí že to něco umět může ale taky nemusí. Marketingově dobrý, dáš nálepku ale už nemusíš říkat jestli umíš všechno nebo jen povinné části. Technicky debilní, protože to znamená další fragmentaci.
Opravdu nechápu proč nikdo nemluví o tom, že je to vlastně marketingová oblož s nozecností.
Nemíchal bych to do jednoho pytle, nevíme kolik lidí původní návrhy reviduje a mění, než jsou finální. Původní záměr mohl být dobrý. Nejstarší AVX-512 bylo určeno a optimalizováno pro Larabee, víme jak to ním dopadlo. Si někomu bylo líto tu sadu pohřbít a tak ji upravili pro Xeon. Jenže HW implementace byla moc náročná a takty dost padaly. A dál už je to víc známé. Proč nakonec vzniklo tolik variant netuším, ale s big.LITTLE by měl přijít druhý pohřeb a tak raději přišli s AVX 10. Proč to neudělali jako u AMD? Fakt nevím, mohli ty instrukce u velkých jader zpracovat na 512 bit jednotce a u malých na 256 bit, ale asi nechtěli AMD kopírovat. Dost na tom, že Intel musel převzít 64 bit rozšíření v době kdy plánovali x86 nahradit plošně další variantou Itania. Kdo ví, zda by teď programátoři na Intel nenadávali ještě víc.
Nerozumím tomu ... ten problém je přeci kvůli (ne)podpoře moderní instrukční sady malými jádry, ne?
"Prvním procesorem, který bude instrukce AVX10 podporovat, bude serverový procesor Granite Rapids."
<= Granite Rapids bude mít malá jádra? Pokud vím, tak všechna "moderní" velká jádra Intelu hardwarově umí AVX512. AVX10.x chápu jako jeho derivát / downgrade. Takže bych předpokládal, že AVX10.x poběží na všem co má jen velká jádra. Co mi uniká ... ?
Intel nejdřív potřebuje novou instrukční sadu nějak prosadit a to jde tradičně snáze v profesionální sféře (velká jádra). Proto nejdřív dojde na AVX10.1 určené čistě pro velká jádra a teprve poté bude následovat AVX10.2, která už počítá i s kombinací malých a velkých jader.
To chápu, ale to jsou "technikálie", které nemají s HW podporou tolik společného. Co tedy brání tomu, aby Sapphire Rapids uměly AVX10.1 / AVX10.2 ? Předpokládám, že to je jen tím, že je tak marketing nepropagoval, ale reálně tam žádná překážka není.
Je to jen můj názor, který vychází ze zatím dost omezených informací, ale celá situace na mě působí tak, že Intel chce vydáním AVX10 ukončit další vývoj AVX512, aby vývojáře softwaru přiměl k přechodu na AVX10, které je pro jeho procesory výhodnější (na rozdíl od AVX512 poběží i na kombinovaných architekturách). Rozvíjet tedy bude jen AVX10 a právě v tom je jádro věci - AVX10 bude mít oproti AVX512 hardwarové požadavky navíc, aby nebylo zpětně kompatibilní. Kdyby totiž bylo, mohla by ho na Zen 4 podporovat i AMD a tím by Intel přišel o konkurenční výhodu. Že AVX10 nebudou podporovat ani dosavadní Xeony, může být Intelu vcelku jedno - v podstatě to z hlediska Intelu může být i výhoda, marketing tím může motivovat zákazníky k upgradu.
Celkově vidím v AVX10 spíš marketingový než technologický nástroj. Ono to nepřináší nic zcela nového a fundamentálně odlišného od AVX512, spíš to má eliminovat konkurenční výhodu AMD v podobě kompatibilnější a efektivnější implementace AVX512.
Zen4 neumí FP16, takže podporu AVX10 mít nikdy nemůže. Otázka co Zen5...
Nevím jak Float 16, ale BFloat 16 umí.
".. marketing tím může motivovat zákazníky k upgradu .."
Koukám, že markeťáci Intelu byli na stáži v nVidia.
".. Celkově vidím v AVX10 spíš marketingový než technologický nástroj .."
.. a další možnost, jak dělat podrazy.
ZEN4 AVX 10 může těžko umět, když teprve teď s tím Intel přišel. Ale ZEN5 by je mohl umět.
Teoreticky přes update mikrokódu pro správné CPUID, ale chybí mu AVX512-FP16, takže je to jedno. AVX10.1 není nic jiného, než AVX512 na úrovni Sapphire Rapids.
"AVX10 bude mít oproti AVX512 hardwarové požadavky" <= Na základě čeho k tomu lze dojít? Nepopírám to, jen jsem nezaznamenal důvody, které by to naznačovaly, nebo potvrdily. Budu rád za vysvětlení. V takovém případě by ten můj předpoklad "všechna "moderní" velká jádra Intelu hardwarově umí AVX512. AVX10.x chápu jako jeho derivát / downgrade." ... byl mylný, jen nevím proč ... :-)
Spíš je to způsob jak zajistit AVX512 na jádrech s různou šířkou HW prostředků. Samozřejmě to bude znamenat rozdílnou rychlost zpracování.
Sapphire Rapids AVX10.1 skoro jistě umí, akorát to nebude hlásit - něco jako FMA4 na prvních Zenech. U AVX10.2 už jsou nějaké drobné rozdíly na HW úrovni, takže tam má smůlu.
Protože AVX10.1 je v podstatě jen "marketingový" bod nula a splňuje ho nejspíš i současný Sapphire Rapids (akorát bez příslušných CPUID flagů). Malá jádra verzi 10.1 implementovat mohou, ale nebudou, protože to nestihnou a rovnou implementují 10.2.
Uz teraz je v instrukciach pekny gulas. Intel by lepsie urobil keby dal do jadra programovatelne FPGA a SIMD nechal na programatorov.
A kdo asi ty instrukční sady vymýšlí? Že by na vývoji CPU nikdy žádný programátor nespolupracoval. A nebo že by ti inženýři o programování nevěděli nic?
".. A kdo asi ty instrukční sady vymýšlí? .."
Vzhledem k tomu, jak ta instrukční sada vypadá a jak často se uvádí opravy oprav předešlých oprav .. tak nejspíš Pejsek a Kočička.
Tak si založte firmu a zkuste procesor od nuly navrhnout sami. Uvidíme, jak vám to půjde.
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.