Nejrychlejší ARM64: AmpereOne proti AWS Graviton4

AmpereOne: spotreba 350W, Arm v8.6, 5nm

Graviton4 (Neoverse v2): ~260W, Arm v9, 4nm: viz (https://www.nextplatform.com/2023/11/28/aws-adopts-arm-v2-cores-for-expansive-graviton4-server-cpu/ - 2 socket per 130W = 260W )

pripadne jeste jiny zdroj: Neoverse v1 ma mit spotrebu na jadro 1.2W, u v2 je pry zvyseni +17%, tj 1,2*1,17*192 = ~ 270W (https://www.nextplatform.com/2023/09/13/other-than-nvidia-who-will-use-arms-neoverse-v2-core/)

Co asi jako cekali, kdyz to ma nizsi frekvence, dva sockety, nizsi TDP :D

Nie je tam napísané, čo čakali. Asi preto robili testy.

Pokud to dobře čtu (včetně prvního příspěvku), pak měl vítěz nižší frekvenci jader, dva sockety (tedy potenciálně pomalejší komunikaci) a mírně vyšší TDP.

TDP se vykon nemeri.

Zajímavý mi přišel i jeden z předchozích článků na Phoronixu s benchmarkem Gravitronu.
https://www.phoronix.com/review/graviton4-96-core
Možná tu i o tom byla předtím zprávička, nevím.
Každopádně je tam i srovnání s x86 procesory, tak si to aspoň člověk může dát do nějaké relace.
Altra je tam taky, ale Max, ne ten nejrychlejší One. Gravitron tam byl 96 jader, tzn. nejspíš jeden socket, respektive řádově půlka výkonu oproti tomuhle poslednímu testu.
Na jednu stranu to je logické, na druhou stranu škoda, že se k tomu Gravitronu nedá dostat jinak než přes AWS.
Protože když se dívám na těch pár specifických testů, tak je to snad poprvé, co mi přijde, že to začíná být opravdu výkonově konkurenceschopné i EPYCům. Zvlášť když se vezme v potaz i to TDP zmíněné v prvním postu, tak je to výtečné.

Předtím ARM na serveru s těmi Altrami vypadal jako zajímavá volba jen pro někoho, kdo maximálně zohledňuje spotřebu a měl to vychytané na specifický paralelizovaný workload, kde nebyl až tak třeba hrubý výkon. Jinak mi to moc smysl nedávalo, zvlášť pokud u toho člověk zohlednil cenu, minimum klasických HW dodavatelů s podporou (mimo typ. barebone serverů) atd.
Uvidíme, jak se to bude vyvíjet dál. Amazon s Gravitony ukazuje, že by to evidentně technicky šlo :) I když samozřejmě netušíme jak by pak mohly vypadat retailové ceny.

9. 9. 2024, 23:38 editováno autorem komentáře

Podle me ten osekanejsi Zen4C ma fakt adekvatni ARM64 nahradu.

Takze jsme znova zpet u me teorie - kdyz vezmes urcity node (proces) a das tomu urcity limit na TDP, tak vypocetni vykon bude stejny, nehledne na konkretni implementaci.

Ty Ampere Altra jsou dostupne na eBay jako desky/cpu.. ale nevim zda bych do toho sel - porad je u techto serverovych veci velka IDLE spotreba (napric vsemi produky, at uz arm/intel, nebo intel/amd), takze to proste cili na provoz v zatezi, kdezto ja bych rad na domaci instalaci neco, co ma i nejaky power management hodny 21. stoleti. Nepotrebuji turbo/boost, potrebuji jen aby se to uspalo a vyplo napajeni, kdyz to idluje..

Nechapu proc nedelaji ty cpu tak, ze to v idle lze naskalovat na 2C~4C a zbytek vypnout dokud tam nebude zatez.

Takze jsme znova zpet u me teorie - kdyz vezmes urcity node (proces) a das tomu urcity limit na TDP, tak vypocetni vykon bude stejny, nehledne na konkretni implementaci.

No nevím, jestli se to dá až úplně takhle zjednodušit.. prakticky tam bude i dost ostatních proměnných než jen proces a TDP, zvlášť pokud budu porovnávat mezi sebou úplně odlišné architektury. Ale budiž, i kdybych odhlédl od instrukcí, registrů a řekl, že se to stejně překóduje na nějaké micro ops, ta různá jádra cíli na stejný segment a jsou konkurenceschopná, CPU budou podobně vybavená z hlediska I/O a cache, tak to stejně bude platit jen pro základní operace (na ALU a FPU).
Pro určité workloady tam bude hrát velkou roli právě další, rozšířené instrukce, které daný výrobce může, ale také nemusí implementovat, podle toho jaké si nastaví priority.
Příklad je třeba ta Altra a předchozí modely Gravitronů u AWS, oba implementují jádra Neoverse N1 od ARMu. Altra oproti Gravitronu 3 nemá SVE, ale má zas podporu pro bf16 (half-floaty).
Pokud budu dělat nějaké storage servery, edge servery na obsluhu tuny klientů, nebude tohle hrát roli. Jakmile budu počítat a používat nějaký HPC toolkit s podporou SVE, nebo video enkodér, co to využije, bude Gravitron 3 zásadně lepší. Situace se ale může výrazně otočit v momentě, kdy budu chtít dělat AI inferenci a pak bude zas bf16 výhoda, která přetlačí i to, že Gravitron 3 má lepší výrobní proces (5 vs 7nm).

Ten test mě zaujal, protože je tam Gravitron 4 jako první CPU s licencovanými jádry Neoverse V2, které jsou primárně cílená na výpočty (oproti datacenter/edge v případě N1 a N2). V2 použila i NVIDIA u akcelerátorů a Google v jejich procesorech Axion, ale o tom jsem jen četl v jejich tiskové zprávě.
Ampere s One šlo jinou cestou, protože oproti předchozímu Altra nelicencovali celé jádro od ARMu, ale udělali si vlastní (s ARM ISA, podobně jako třeba Apple).

Jinak na home lab a malé instalace budou po nějakou dobu dávat větší smysl x86 procesory, pokud se nebavíme o nějakém speciálním použití (např. vývoj pro konkrétní platformu). Zatím to fakt byla spíš datacentra, kde jde o nejvyšší hustotu v definovaném workloadu a ten příkon počítáš spíš na stojany v 24/7 režimu. Jestli z toho Ampere (jako v podstatě jediný současný retail výrobce) postupně dostane i nějaké menší a zároveň konkurenceschopné varianty a za dva roky se tu budeme bavit, jestli si někdo koupí Ryzen, menší Epyc, nebo něco s ARMem, protože to bude srovnatelné, uvidíme. Já jsem trochu skeptický, myslím že ten fokus na SaaS a velké instalace v Cloudu je jasný.

Nechapu proc nedelaji ty cpu tak, ze to v idle lze naskalovat na 2C~4C a zbytek vypnout dokud tam nebude zatez.

Netuším.. Ale v idle stavu ty samotná jádra s frequency scalingem podle mě v porovnání s plným loadem moc žrát nebudou. Nicméně je tam spousta věcí okolo (různé IO řadiče, obsluha toho meshe), ty patice jsou obrovské. Podobně i komponenty na zákl. deskách, rychlé síťovky osazené SFPčky, které si i se všemi šetřícími fíčurami, ASPM (pokud už to rozchodíš :)) klidně vezmou 15-20W v idle.
Úplné vypínání jader a fakticky dynamická změna topologie CPU podle zátěže nevím, asi by si to vyžádalo spousty změn ve všech vrstvách od architektury CPU samotného, přes OS, až třeba po hypervizory.

Tak CPU hotplug v jadru je, jen se to nepouziva timto zpusobem.

Nicmene pres sys/proc muzu udelat cpu jako offline, a nebude se na nej davat zatez (a myslim ze zmizi i z top, v lscpu je na to radek online/offline) - takze to maskovani jader je mozne i bez zmeny topologie, stacilo by k tomu navazat spravne acpi a napajeni v hw, aby to fakt bylo vypnuty (na druhou stranu, to vyrobce a fyzika nechce - protoze bys mel hotspoty - a je lepsi vsechny jadra vytezovat postupne dokola, at se vyvazi teplotni gradient na kremiku).

Ja prave vidim IDLE na 60-70w v pripade vetsiho cpu (xeon/epyc), a nejsem s tim v pohode. Jasne, kdyz se pridaj periferie, a budeme s idle na 150w, tak uz rozdil 150 : 100 nebude hrat takovou roli.. ale stejne.. mohlo by to byt udelany lepe :)

"Tak CPU hotplug v jadru je, jen se to nepouziva timto zpusobem."

No zkuste si to, když dáte jedno jádro offline, tak bude spotřeba větší. Zatím nejde do toho jednoho jádra prostě vypnout napájení a když je idle , tak má spotřebu menší, než při offline.

Jasně CPU hotplug jádro podporuje, otázkou je, jestli je to pro tohle vhodné. Chápu původní smysl toho mechanismu na mainframy, virtuály. Osobně jsem to nepoužíval nikdy s ničím jiným než s hypervizorem, kde pak jde za jízdy hýbat počtem CPU ve VM.
Ale i když to fungovalo, tak to vždy vyžadovalo určitou koordinaci na všech vrstvách. Přidáš CPU do virtuálu, objeví se jako offline, přes chcpu se musí povolit. A nakonec stejně většina aplikací, které si řeší něco s procesy, vlákny to dynamicky nedetekuje. V systému je volání get_nprocs() - aktuální počet resp. get_nprocs_conf() - počet včetně offline. Buď se musí aplikace restartovat, spustit znovu (případ top, lscpu a všeho, co to zjišťuje jen po startu) nebo musí podporovat nějaký vnitřní příkaz aby si za jízdy znovu detekovala aktuální stav (a třeba rekonfiguorovala interní scheduler).
I když chápu, že v hypotetickém šetřivém CPU by byl celkový počet jader stejný a měnil se jen dynamicky počet aktivních. Nicméně i kdyby se změnily aplikace, aby přijímaly třeba nějaké události, tak pořád mi to celé přijde docela heavy handed, na to aby se to dělo třeba několikrát za hodinu.

Druhá principiální možnost je pak, aby se to transparentně dělo v CPU a jen to signalizovalo nějaké stavy do OS. Tam zas vyvstane další otázka, jak to udělat rozumně efektivně. CPU ví o procesech, vláknech a jejich vazbách mezi sebou daleko míň než systém. Což pak plynule dojde k problému jak spolehlivě detekovat idle stavy, ušetřit energii a zároveň úplně nezabít výkon těch aplikací, pokud bude potřeba.
I dnešní standardní mechanismy s C states můžou mít dlouhou relativně dobu těch přechodů mezi nimi (a jestli máš nějaký workload citlivý na latenci, tak je to velký problém a typicky se to úplně vypíná). Vyladění toho všeho dohromady pak i s použitím relativně sofistikovaných mechanismů není úplně snadné. Pokud by se ta jádra komplet vypínala, signáloval se stav do systému a aplikací, bylo by to ještě problematičtější.

Stran té vyšší idle spotřeby, netuším, můžu jen spekulovat. Buď je to s tou aktuální vyšší idle spotřebou tak, že to není u serverových CPU prioritou (což se mi úplně nezdá, že by to vůbec neřešili).
Nebo, pokud to vztáhnu třeba konkrétně na AMD, je to s jejich stávající technologií s čiplety a stále aktivními komponenty v pouzdře okolo obtížně technicky řešitelné. I u současných desktopových Ryzenů je to potíž. Např. jejich malá APU jsou monolitická a mají nízkou idle spotřebu. Desktopový Ryzen 9 s čiplety může mít klidně okolo 40W (a AMD za to dostává čočku :)). Pokud bych to extrapoloval na výrazně větší Epyc, tak mi 70W se stejnou koncepcí nepřijde nereálných.
U těch velkých serverových ARMu nemám žádné podrobnější informace, ale klidně tam může být stejná potíž.

"Nechapu proc nedelaji ty cpu tak, ze to v idle lze naskalovat na 2C~4C a zbytek vypnout dokud tam nebude zatez.

Netuším.."

Na to je odpověď jednoduchá. Protože idlující procesor nevydělává peníze. Pro datacentrum je nejvýhodnější server zatížit naplno, a nevytížené servery sjet do vypnutí a zapnout je až v momentě, kdy jsou potřeba.

Pro jasně definované workloady, kdy je nad tím nějaký systém na správu, to přesně může být tak jak říkáte. Třeba render farmy, můžou mít po skončení nějaké skupiny renderů nastavené vypínací skripty. A naopak před tím než nějaký manager dispatchuje konkrétní job, tak si může nahodit nody přes WoL nebo BMC (IPMI, Redfish).