Vlákno názorů k článku Nvidia investuje 5 miliard dolarů do Intelu, propojí x86 CPU a RTX GPU od cc - Třeba začne Intel konečně vyrábět pořádné ARM64 procesory...

Tak zrovna servery na ARMu jsou příklad, co úplně neoslňuje, že?

A kteří že ti cloud provideři so dělají vlastní mikroarchitekturu a není to aplikace Cortexu nebo Neoverse?

Oslňuje to právě spotřebou za stejnou práci.

Abych se přiznal tak nevím kolik toho musí Google udělat, aby měli třeba svůj "Axion", ale to není ani pointa nebo pro mě nějak důležité.

A ty spotřebu znáš jak?

Mno já jen že jsi to vytáhnul a byla to blbost...

Takze takovy amazon zacal pred lety nabizet arm kvuli cemu? Protoze vykon/spotreba/cena pro poskytovatele jsou dulezite. Klidne si o tom precti, zajimave cteni. Spousta uzivatelu jiz dnes neni zavisla na x86 instrukcich tudiz si porizuji arm.

Levna nabidka ARMu pro koncove uzivatele byl dusledek, ne pricina.

Cloud provideri zjistili, ze nabizet ARM za stejnou cenu jako puvodni x86 nejde.. nema to ten vykon, nema to tu kompatibilitu.. museli jit s cenou dolu.

Kdy jste totiz slysel, ze by se nejaky obchodnik snizil cenu pro koncove uzivatele, jako reakci na sve snizene naklady? Ja nikdy nikde.

Opravy:
- Kompabilitu s čím přesně? Drtivá většina SW na serverech je dnes plně open source nebo postavená nad open source. Nebo vlastní kód, který jde překompilovat. 90% bude pravděpodobně JVM nebo podobné.
- Výkon: Migrovali jsme projekt běžící na cca 300 serverech, v té době z Intel na ARM Graviton 2. Výsledkem byl nižší počet serverů na stejný úkol. Apple měl při emulaci x86 na ARM vyšší výkon než nativní x86.
- Cena: Ve skutečnosti jsou výrobní a provozní náklady ještě dramaticky nižší než s Intel nebo AMD. Nižší cena motivuje více zákazníků k přesunu, snižuje náklady u cloud providera a ve výsledku mu zvýší zisk ve srovnání s původním x86 řešením. O konkurenci mezi cloud providery ani nemluvě.

U ARMového Macu mám osobně nejradši ne ISA, ale unifikovanou paměť. Na lokální QM výpočty / inferenci LLM je to strašně příjemný a je to primární důvod, proč se ho držím. Jinak AVX-512 je argumentem až zase v poslední době => do Zenu 4 chyběla rozumná implementace (u Intelu to vede k podtaktování, takže si člověk musí rozmyslet, jestli při kompilaci povolí AVX-512), fakt efektivní implementaci má až Zen 5.

Dál pak na velkým železe fakt nechci hnát SW přes překladovou vrstvu, neb nechám na zemi víc efektivity, než získám jinou ISA. A vzhledem k tomu, že tady se tahají legacy věci i z dob vyloženě dřevních, fakt hraje zpětná kompatibilita sakra roli. Vyšší efektivita, nižší spotřeba v idle a menší kód (+ subjektivně příjemnější assembler) jsou sice hezký věci, ale bohužel to nekompenzuje ty desítky let budovanej ekosystém okolo AMD64. A ne, není to snadný ani u appek, ke kterým mám zdrojáky. Tuhle se mi stalo, že jeden výpočetní nástroj jsem musel na Macu překládat a běžet pod Rosettou 2, neb měl některé subrutiny psané v assembleru (kvůli efektivitě, paradoxně) a nevyplatilo se mi to přepisovat pro ARM64, případně do jazyka vyšší úrovně.

Každopádně uvidím, jak se to teď pohne s novým clusterem Jupiter v Německu. Ten by měl bejt postavenej na ARM64, takže i SW podpora a ekosystém by se mohl zlepšit. Jako to bylo okolo ROCm se spuštěním clusteru LUMI.

I Zen4 měl dobrou implementaci, i když to byl double pumping - 2x256-bit, ale třeba i Zen4 měl jednu 512-bit shuffle jednotku, kterou dělal třeba VPERMB a další instrukce, které nedělí registr na menší části.

Zen4 totiž dokázal, že lze snížit spotřebu už jen tím, že se uleví dekodéru, a že nemá cenu hned dělat plnou implementaci tak, jak to udělal Intel (a co mu přineslo hrozné problémy a pak i opuštění AVX-512 v consumer segmentu kvůli těm nepoužitelným E jádrům).

Ale jinak souhlas. ARM64 je prostě zatraceně dobrá konkurence a podle mě už ten 15% overhead u decode, nutnost mít uop cache, atd... je to včechno zbytečná režie navíc, která pomalu ale jistě likviduje x86 architekturu.

19. 9. 2025, 20:37 editováno autorem komentáře

E jádra byla slabá dřív. V okamžiku, kdy má dnes jedno to E jádro vyšší výkon než jádro deset let starého notebookového i7 čili by na každém páru z nich mohl běžet jeden dnešní běžný kancelářský počítač ta nepoužitelnost dost mizí. Intel zrovna s tímhle dost pohnul. A to máte CPU, kde je těch jader takhle dvanáct. Coz jsou třeba pro mě tři počítače, na kterých jsem doteď normálně vyvíjel plus dvakrát výkonnější P jádra.

Problémem AVX-512 je hlavně jak ji uchladit. Ono je to dost poznat i s AVX2, že ji něco zrovna používá. Nemluvě tedy o tom, že zabírají velkou část křemíku přičemž většinu času se vůbec nepoužívají protože v běžném provozu moc není kde. AMD to svou vyšší energetickou efektivností v zátěži dává lépe ale hitparáda to taky není.

19. 9. 2025, 23:50 editováno autorem komentáře

Macovský ARM má zásadní výhodu v tom, že s sebou nemusí vláčet kouli na noze v podobě křemíku pro podporu starých instrukčních sad. Kdyby ty CPU měly mít nativní křemík až zpátky k 68030, taky by to nebyla žádná sláva.

AArch64 má i 64-bit SIMD (tak nějak na úrovni MMX), který užírá hodně instruction space, takže staré instrukce má i ten AArch64. Ale je fakt, že toho historického balastu má x86 architektura mnohem víc (celé FPU, MMX, 16-bit režim, segmentace, a dnes už i SSE instrukce (AVX je lepší)).

to 64bit SIMD je (jestli myslime oba NEON v 64bitove variante) spis tak na urovni SSE2. I HELIUM je vys nez MMX.