Vlákno názorů k článku
LoongArch bude oficiálně podporovanou architekturou pro připravovaný Debian 14 od MeeGo - no future - OMG, další architektura. ARM, IBM POWER, x86 a...

Qualcomm má taky mezi generacemi dobrou kompatibilitu a za levnou Čínu nemůže. Koneckonců ta Čína má i svůj nekompatibilní x86.

> X86 architektura z user-space hlediska je dekády kompatibilní, takže to bylo fakt vtipné. Porovnej s ARMem

Naopak, Aarch64 je v userspace kompatibilnější než x86-64. Intel si vymýšlí nekompatibilní rozšíření, např až v příští generaci AMD přidá instrukce, které si Intel vymyslel pro AVX10, který je ve skutečnosti horší než AVX-512, který AMD a implementuje dávno a Intel ho nezvládá. Zatímco binární balíky z repa Ubuntu jedou bez úprav i na Apple Silicon.

25. 12. 2025, 16:05 editováno autorem komentáře

AArch64 má už desítky verzí a ta první ArmV8.0 nemá ani nativní atomické operace! A z hlediska výrobců to je navíc tak, že výrobce tvrdí ArmV8.6, ale něco tam chybí, takže je to reálně ArmV8.2 a prase aby se v tom vyznalo. A co SVE/SVE2, které míá víc feature flagů než má AVX-512?

Takže porovnávat porovnatelné. Dnes když zkompiluju kód pro x86 a nepoužiju žádné -mxxx flagy, tam mám binárku pro 20 let starou architekturu co má SSE2 jako baseline. To co přišlo pak je evoluce a má ji každá architektura. Tvrdit něco o AVX je úplně mimo, mainstream AArch64 CPU taky nemá SVE.

Jinak to s tím AVX10 je naprosto mimo - AVX10.1 je standardizace AVX-512 do jednoho feature flagu. AVX10.2 jsou nové instrukce, ale obojí zachovává 512-bit vektory, takže to není "horší" než AVX-512, je to jen další evoluce u x86. Třeba nový Zen6 CPU netvrdí, že má AVX10.1, ale v podstatě by mohl, protože podporuje všechny AVX-512 rozšíření, které AVX10.1 vyžaduje.

Kde má AVX10 v Intelu 512bit vektory? Jen pár procesorů pro servery. Ty ostatní to neumí ani emulovat jako AMD 512bit dvěma 256bit operacemi např v notebookovém APU a v předchozí generaci, nebo AVX2 dvěma 128bit operacemi v prvních svých CPU s těmi instrukcemi, nebo Zilog Z80 emulující 8bit na 4bit ALU. To je přesně ono, Intel se potápí a chce s sebou stáhnout i AMD a x86 (ne poprvé). Kdežto firma ARM drží nad architekturou pevnou ruku.

A je teď ten intel s vámi v místnosti? Mluví na vás? Neslyšíte hlasy? Nebo co je to za paranoidní pateorii? Ostatně Intel AVX-512 normálně zvládá. Nezvládá ho uchladit. Ona to ani na AMD CPU není zrovna hitparáda ale přece jen jsou energeticky efektivnější tak to ještě jakž takž dávají. To je celé.

Intel nezvládá AVX-512 v žádném consumer procesoru. Ani emulací nad 256bit jednotkami. Nezvládá ani Hyper Threading, ani scheduler pro tu svou kombinaci velkých, malých a ultramalých jader. Ne tak dávno nedokázal procesory ani pořádně vyrobit, v naší firmě uhnilo všech 50 Raptor Lakeů.

AVX10.1 je standardizace AVX-512 - AVX10.1 jen garantuje většinu rozšíření.

Co to je "nezvládá"? AVX-512 je volitelné rozšíření, buď ho CPU má a nebo ne, tak jak ne každý AArch64 CPU má SVE/SME.

AMD třeba AVX-512 má, takže moje volba je jasná.

AMD měl AVX-512 dávno předtím, než Intel přišel s programátory nepodporovaným AVX10.

> AVX10.1 jen garantuje většinu rozšíření.

Ale tak nějak negarantuje 512 bitů.

Kolikrát to mám napsat? AVX10.1 nepřináší žádné nové instrukce, je to jen marketingový termín.

Hyper-threading je něco, co je v některých ohledech kontroverzní skoro od začátku. Ten odstranili úmyslně a schylovalo se k tomu dlouho. Stejně tak scheduling funguje normálně. Opět: AMD má scheduling lepší ale to je tak vše. S AVX-512 je to přesně stejný případ. Napíši vám důvody, které jsou ostatně známé skoro každému ale vy pořád melete svou (a nejen tady). Plácáte naprosté nesmysly.

Moderní procesory (Apple, Qualcomm) dekódují 8 instrukcí za cykl. O tom se legacy x86 může jen zdát. Hyper Threading je workaround pro Multi Threaded zátěž, kdy se zbývající jednotky jádra CPU využijí instrukcemi z druhého vlákna. AVX-512 je zas workaround pro SIMD zátěž (vektory, matice), kdy instrukce obsahuje "hodně práce" (využije hodně výpočetních jednotek jádra CPU) a dekóduje se na AMD a Intelu za jeden cykl (na čínském x86 za dva cykly, takže tam je to spíše kvůli kompatibilitě s AMD a Intelem). Díky tomu AMD tak válí, protože obchází limity x86 ISA. Jenže Intel nemá nic - a na ten scheduler se zeptejte lidí, co dostali služební notebook s 2 velkými a 8 malými jádry. Chová se jako dvojjádro, a tak je korporát přestal objednávat. Tenhle podvod Intelu projde jen jednou.

27. 12. 2025, 16:47 editováno autorem komentáře

X86 má AVX-512, který má 512-bit vektory. Při dekódování 4 instrukcí za 1 cykl můžeš zpracovat 2048 bitů za ten 1 cyklus. Na Apple Silicon můžeš zpracovat 1024 bitů za 1 cyklus, pokud napíšeš kód, který těch 8 instrukcí paralelně umí využít (takže žádné závislosti).

Ale není instrukce jako instrukce - záleží na portu. Takže to na Apple vychází třeba na 4x násobení a 4x adder, atd... Musíš se fakt snažit. Obecný kód těch 8 instrukcí za cyklus nedá.

Nejvíc se to přirozeně projeví na skalárním kódu. Např při kompilaci zdrojových kódů dá Apple a Qualcomm v tenkém tichém notebooku skoro stejný výkon jako AMD v desktopu s trojnásobnou spotřebou.

Tvůj výpočet na hypotetický počet bitů vektorů za cykl je vtipný, žádný takový x86 procesor není. A naopak, i ARM procesory mohou implementovat širší vektory, ARM ISA na to nabízí SVE a SVE2. Reálně má AMD jednu AVX-512 jednotku v jednom jádře a Apple 4x 128bit NEON jednotky. Tedy stejný výkon "bitů za cykl".

Zen5 má 4x AVX-512 jednotky.

Nemá cenu tu míchat SVE. SVE může být klidně 128-bit, a na většině dostupného HW taky je, pokud tam je.

Na skalárním kódu se projevuje hlavně lepší ISA AArch64 kde jdou některé věci dělat "líp" už v baseline - X86 má sice BMI2, ale obecný kód to nepoužívá, protože to už vyžaduje x86-64-v3.

Využít 8 IPC u skalárního kódu bych chtěl vidět - sice to teoreticky jde, ale není to běžné. Stačí v linuxu pustit perf a podívat se na IPC.

BTW: Kompilovat pro různé architektury (což ty kompilační benchmarky dělají) je naprostý nesmysl pro porovnání výkonu. Není to stejné, negeneruje to stejný výsledek - navíc stačí aby tam byl SIMD a další věci a ty časy budou jiné už kvůli tomu, že to parsuje jiné hlavičkové soubory (třeba ty pro AVX-512 jsou monstrózní). Jediný použitelný benchmark je takový, který vygeneruje úplně stejný výsledek.

Je to reálný usecase. Programátor zkompiluje zdrojový kód, dostane binárku, a když jí spustí, tak ta vrací stejný výsledek. Sice strojový kód binárky je jiný pro každou ISA, ale programátora zajímá, jak dlouho to kompiluje. Doplním taky, že strojový kód se generuje až v poslední fázi překladu, ty dřívější fáze jsou na výstupní instrukční sadě (ISA) nezávislé.

Mimoto testovat se to dá i pro stejný výstupní strojový kód, pomocí cross-kompilace. I ta se běžně používá, např. na Macu máš Universal2 binárky Intel+ARM. Tedy kompilace release verze aplikace je Intel+ARM, ať už to provedeš na Intelu nebo ARMu. Takové testy jsou změřené.

Další velmi častý usecase jsou skripty na webových stránkách. Nevím o tom, že by jejich zkompilovanou verzi nějaký prohlížeč cachoval na disk. Takže je kompiluje pokaždé znova a je to podstatná část rychlosti "načítání" stránky (pokud nemáš pomalý internet).

Není to stejné -> výsledky jsou zavádějící a nedají se interpretovat.

Ale prosimtě, je jedno, že se udělá jiná práce, dokud u ARMu vyjdou lepší čísla!

Osm? Rozuměl jsi?! Osm!!!

Jak píšu, můžete porovnat cross-kompilaci nebo "načítání" moderních webových stránek.

28. 12. 2025, 17:43 editováno autorem komentáře