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.
kdoví kdy to vůbec vyjde a jaká bude podpora v OS a aplikacích, tohle je dost zásadní přelom od přechod na vícejádrová CPU.
On Intel i dnes díky opomíjené RL je v mainstream cpu 4-8 jader dost konkurenceschopný. A vypadá to že současná mizérie může trvat ještě déle když i AMD vysílá dost rozporné signály. Nejblbější je u AMD že sice mají výtečnou ZEN 3 architekturu která hlavně díky vytvoření osmijádrového modulu je extremné konkurenceschopná, jenže to zabíjí nízký počet modelů i vysoké ceny. Intel má větší variabilitu v RL a takové základní osmijádro i7 11700 už dýchá 5800X hodně za krk, obzvlášť ve hrách a navíc je i o 2000,- levnější. A o přepálených 5600X úplně škoda mluvit ty nejsou skoro vůbec a když ano tak i za 10Kk, což je absurdní zvlášť v porovnání se zmíněným 11700 modelem.
Myslím že za to může zostřená konkurence, o kapacity TSMC se pere moc zákazníků a o GF také, zvlášť automotive je čím dál důraznější v požadavcích, je to teď hodně predátorské prostředí...
Podpora bude v pohodě, už se na tom nějakou dobu maká. A jestli to fakt má hw scheduler, nebude to závislé na diletantsví mrkvosoftu.
Bohužel to bude závislé na Microsoftu. Po rozkliknutí zdrojů článků o tom kouzelném hadrwarovém scheduleru se objevuje spíš pojem "hardwarem asistovaný scheduler". Rozhodně to bude hybridní řešení ležící mezi CPU a OS, jinak to aspoň zatím ani nejde. Snad jde o tak důležitou věc, že si odpustí aspoň ty nejhloupější chyby.
Uvidíme co ten HW asistovaný scheduler bude umět. Big.Little tady je od 2011 kdy to poprvé uměly Cortex A7 / A15 jakožto 32-bit ARMv7 a nějaké problémy s čistě SW schedullerem nejsou.
Jedna věc v čem by HW mohl pomoct je, že velké jádra Golden Cove by mohly mít aktivní AVX512 a tedy SW který AVX512 používá by OS nemohl přehodit na malá jádra, kde by zhavaroval protože ty umí jen AVX2. U Armu musí být právě stejná verze ISA, jinak big.Little nejdou použít viz nejde použít Cortex A53 s ARMv8.0A s novými Cortex A76/77/78/X1 které jsou ARMv8.2. Proto se musí párovat s A55 který taky umí ARMv8.2. ISA musí být homogenní kvůli jednoduchému context switchingu. Kdyby tohle Intel vyřešil, tak by to bylo opravdu heterogení CPU a OS by tak uměl pracovat teoreticky s jakýmkoliv x86 slepencem (starý Atom s SSE a nový ICL s AVX512 aneb konečně by se vyřešily problémy u Lakefieldu).
Ďábelská věc by byla kdyby ty velká jádra Golden Cove uměla ty nové 65 536-bit AMX pro násobení matic . Serverová verze Golden Cove AMX umí a to jádro má cca 4 mm2 na 10nm což není moc (Zen2 má 3,6 mm2 na 7nm, přitom neumí ani AVX512 ani AMX). Aby se pak lidi nedivili že bude díky AMX mít 10x větší výkon v násobení matic (a to se používá poměrně často, viz CFD a FEM výpočty pro inženýry). Už vidím tu jejich reklamu s vysmátým inženýrem používajícím Intel s AMX a s brečícím týpkem co jede na AMD. A že zrovna firem co se živí konstrukcí a výpočty FEM není zrovna málo.
BTW: Zen 4 sice bude mít podobné IPC jako Golden Cove, ale výhoda Intelu je ve zcela nové architektuře ať už to bude 6xALU nebo cokoliv jiného. Keller řekl, že to má být "výrazně větší" architektura, takže nepředpokládám, že by Intel udělal takový malý krok jako 4xALU+1xBranch u Zen3. Tudíž Raptor Lake a Meteor Lake budou mít dobrý základ pro snadnější zvyšování IPC. Na to nezapomínat, stejně jako že Intel pravděpodobně přesune část CPU k TSMC a bude mít stejný výrobní proces jako AMD.
BTW2: IPC Zen4 a ADL bude mít podobné i letošní Arm N2 / A79. U sesterského Cortexu X2 předpokládám, že bude mít IPC větší než Zen 4, protože loňský X1 měl už 4xFPU a již víme, že N2 má jen 2xFPU (byť nové SVE2 místo starého NEONU). Tudíž Cortex X2 i díky 4xFPU a naboostovanýmu ROB by mohl mít o 10% větší IPC než N2 a Zen4, tedy poměrně slušných 30% nad Zen 3. To není špatné na to že X2 bude už letos :)
"The concept behind big.LITTLE is to include multiple cores with the same instruction set"
To ze je tu b.L s nami od 2011 nejde tady aplikovat.
Ty jadra maji stejne moznosti, pouze jejich vykonostni parametry jsou jine. Tohle je v pohode resitelne, protoze uz tedka jde treba identifikovat na widlich "zlata jadra" a nastavit afinitu na ne.
Problem AlderLake ale je v tom, ze ty jadra nejsou jen ruzne vykonna, ale maji i jiny instrukcni set (podle dosavadnich informaci). Tedy planovac musi dobre predpovidat, jestli v kodu ktery spousti na tom slabsim jadre se neobjevi instrukce, ktera by vyzadovala presunout to na vykonejsi jadro, coz by treba mohlo znamenat to vykonejsi jadro probudit z nizkeho power stavu, coz muze byt dost brutalni latence.
"výhoda Intelu je ve zcela nové architektuře"
Zvyseni poctu ALU neni zcela nova architektura. To je jen rozsireni, specificky cilene na IPC. Tim ze mas vetsi pool instrukci, vice portu, vice ALU neni zadny super novy koncept.
Vzdy si ta firma musi udelat analyzu, jestli kod ktery na ni bude spoustet vubec dovoluje takovou miru paralelizace a jestli te firme stoji za to zvysovat tranzistorovy rozpocet nato.
Pro Apple je to vyrazne jednodussi, maji uzavreny ekosystem. Jeden cip, jeden OS, vsechny programy prochazeji skrze jejich shop, jakakoli aplikace prochazi schvalovacim procesem, vim ze delaji analyzu kodu aplikaci a delaji na tom statistiky. Takze Apple mel lepsi informace, presnejsi, a mohl bouchnout do stolu a rict, vice ALU nam pomuze, stoji za to investovat.
Nicmene neni to znamka nejake uzasnosti Applu, ze by byly technologicky dale nez AMD a Intel a ostatni. AMD a Intel podporuje ohromne mnozstvi operacnich systemu, windows neni jediny, ruzne unixove a linuxove distribuce tam jsou take. AMD a Intelu nemusi vychazet jako dobra investice rozsirovani poctu ALU.
JJ, souhlas. Jde o ISA. X86 má taky hromadu jiných rozšíření, z nich bych vypíchnul TSX pro mnohem lepší práci s pamětí u více vláknových přistupů k datům. Původně to byla serverová vychytávka pro Haswell a novější, ale dnes to může významně pomáhat i tomu Gracemontu.
Hlavně málokdo ví, že x86 má Strong memory model, což omezuje spekulace se zápisy do paměti, tedy to snižuje IPC. To právě by měly řešit TSX instrukce. U Armu to řeší TME instrukce, ikdyž Arm i bez TME má mnohem lepší práci s pamětí. Když CPU ví, že tento zápis do paměti může odsunout na později, protože HW instrukce by mu řekla kdyby nějaké jiné vlákno se dožadovalo těchto dat, tak může v rámci OoO enginu maximalizovat přerovnávání instrukcí na Reorder Bufferu, a tedy lépe vytížit ALU a FPU, tedy dosahovat většího IPC.
U Armu se verze ISA číslují celkem přehledně ARMv8.0, 8.1 až 8.6 a teď tady máme nový base-line jako ARMv9.0.
U x86 je to takové zmatené, poslední base-line je x86-64, který zavedl povinně SSE2 jako minimum. Od té doby je vše dobrovolné a výrobci SW tak nějak živelně podporují ten HW kterého je natrhu nejvíc. AVX512 tu fragmentaci dovedlo k dokonalosti, protože to podporuje málokterý CPU a pokud ano, tak žádný neumí všech 15 sub-setů. To je fragmentace jako prase. Navíc teď nové AMX, které AVX512 nenahrazují, takže fragmentace bude vesele pokračovat.
V tom vidím obrovskou výhodu toho ARMv9. Zavádí hromadu nových vychytávek/instrukcí, které podporoval víceméně jen Apple nebo Fujitsu, jako nový standard pro všechny. A odpadají veškeré nejasnosti pro SW vývojáře. Výrobce praček by mohl prskat, že by mu stačil CPU s podporou starého 128-bit NEON FPU, ale díky Arm v9 bude muset i pračka umět 2048-bit vektory SVE2. To že SVE2 budou moci zpracovávat i na HW 128-bit FPU v pračce nebo v řadiči USB flash klíčenky, je podle další důkaz že si Arm uvědomuje důležitost jednotné ISA.
Jo a máš pravdu s tím Applem, ten jede úplně sólo jízdu. Ten si dokonce implementoval vlastní tajné instrukce na násobení matic AMX. Využívá k tomu 32x128-bit registry stávající FPU, takže je to ISA kompatibilní. Veřejný kompiler tyto AMX instrukce vůbec neumí, ale borci v assembleru zjistili že Apple A13 opravdu umí nedokumentované instrukce navíc. Ofiko to Arm vede jako GEMM v rámci ARMv8.6, ale Apple o tom mlčí jako partyzán. Co vede Apple že tlačí násobení matic do jádra CPU když mají obrovský NPU koprocesor těžko říct.
"z nich bych vypíchnul TSX pro mnohem lepší práci s pamětí u více vláknových přistupů k datům"
TSX je mrtvé, klidně ho ignorujte. Zabily ho bugy.
"Hlavně málokdo ví, že x86 má Strong memory model, což omezuje spekulace se zápisy do paměti, tedy to snižuje IPC. To právě by měly řešit TSX instrukce"
Fakt netuším, jak jste si dal tyhle dvě věci dohromady. Pokud uspořádání zápisů do paměti určitým způsobem snižuje výkon, tak instrukční rozšíření, které si zápisy a čtení zapamatovává a automaticky detekuje konflikty a dokáže operace odvolávat vám tu ztrátu výkonu z přerovnání operací zpátky nevrátí, spíš právě naopak -- úplně stejně jako použití víceuživatelské relační databáze nebude rychlejší než přímý přístup do souboru (a jeho smyslem je koreknost, nikoli rychlost).
"Když CPU ví, že tento zápis do paměti může odsunout na později, protože HW instrukce by mu řekla kdyby nějaké jiné vlákno se dožadovalo těchto dat"
Že vám hardware řekne o konfliktu není důvod něco odložit, právě naopak. Čím déle to odložíte, tím spíše ke konfliktu dojde. Takže nemůžete mít v průměru prodloužené zápisy a optimistic concurrency současně. Že si můžete občas dovolit zápis odložit je jedna věc, ale dělat to v paměťových transakcích soustavně není dobrý nápad. Dokumentace všech systémů s optimistic concurrency na vás apeluje, abyste prováděl transakce co nejkratší, ne abyste si před commitem zašel na kafe.
on i ten HW scheduler není samospásný a nějak se musí naprogramovat .-)
AlderLake je první generace této Big.Little x86-64 arch. Nějakou dobu potrvá, než to odladí, jak po stránce SW, tak HW. Ostatně jako u každé první generace něčeho hodně nového. RaptorLake, příp. 7nm MeteorLake bude určitě lepší koupě/produkt. Nicméně dokud budou implementovat to jejich PL2, tak nemám zájem.
Tak Intel už má Lakefield. A věřím, že díky němu už došlo k nějakému posunu a vylepšením, ze kterých může Alder Lake těžit.
MS Win10 už Big.Little dávno pár let používá i bez Lakefieldu, protože jejich notebook Surface X už dva roky běží na 4+4 ARM Snadpdragon 8cx od Qualcomu. Zkušenosti s big.little mají dost, problémy s ADL v tomto směru neočekávám.
Lidi se zbytečně plaší nad těmi "malými" jádry. Jenže IPC jako Skylake (tedy cca Zen2) na 3,4 GHz se nedá vůbec s rovnávat s tou tragédií in-order Atomu v Asus Eee.
Atom N270 @ 1,6 GHz má v GeekBench5 ST skore 71 pts (ne nechybí mi tam nula :)
IPC = 71 / 1,6 = 44 pts/GHz
https://browser.geekbench.com/v5/cpu/6507446
Skylake 6400 @3,3 GHz má 856 pts
IPC = 856 / 3,3 = 259 pts/GHz
https://browser.geekbench.com/v5/cpu/7747885
Pitomé Raspberry Pi 4 s Cortex A72 @ 1,5 GHz má 194 pts
IPC = 194 / 1,5 = 129 pts/GHz (tedy 3x větší IPC než Atom, ale 2x nižší než Skylake)
https://browser.geekbench.com/v5/cpu/7529532
ADL je spíš Big.MIDDLE a výkon těch MIDDLE jader bude více než slušný. Já myslím že to bude slušně bojovat s 12c Ryzenem 5900X a tak by Intel mohl donutit AMD snížit ceny. Což by bylo jen a jen dobře pro nás.
Jenže ani tyhle nové Atomy se Skylaku rozhodně neblíží.
Aby jsi pak tady nepsal stejne jako po uvedeni RL, ze to stoji za prd :)
Ale vazne, pokud to bude treba fungovat jako clustery, jeden pro velka a jeden pro mala jadra, tak asi bude problem prehodit ulohu z jednoho clusteru do druheho. Dalsi vec bude, jak se budou chovat ty nizsi konfigurace s malym poctem 2 a 4 velkych jader, ale plnym poctem malych, atd.
HW scheduler to fakt nemá, prober se.
Keby ste aspoň netrepali blbosti. 5600X skladom a cena 312,90 €, čiže asi 8100 czk. Šírite bludy.
https://datacomp.sk/amd-ryzen-5-5600x-wraith-stealth_d409127.html
Dneska měli na czc skladem všechny čtyři: od 5600X až po 5950X. To snad jsem letos ještě neviděl :-).
"a takové základní osmijádro i7 11700 už dýchá 5800X hodně za krk"
Tak pokud nejvyšší Intelí konfiguraci současnosti je možné popsat jako "základní", tak je Intel v pytli.
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.