On uz to je bordel :) Zapomels na ruzne podarchitktury jak arm6 arm7 arm7hl arm8whatever, ruzne kompatiblni a nekompatibilni instruckni sady x86 atd....idealni by bylo mit secko, vysledkem je kompromis.
Debian me prekvapil ze do loongAaarchu sel. Mel sem to za mrtvy projekt. Sel do toho vubec jeste nejaky dalsi vetsi projekt?
To je ale tím, že každý CPU má integrované věci přímo v CPU - různé power management funkce, PCIE linky, dokonce i IO, atd... Takže je celkem logické, že každý nový CPU potřebuje podporu jádra. Na druhou stranu jaký je rozdíl mezi generacema od stejného výrobce z pohledu jádra? Nic moc žádný. A díky tomu, že jsou vlastně jen 2 mainstream výrobci x86 CPU tak bych řekl, že kompatibilita právě není problém.
X86 architektura z user-space hlediska je dekády kompatibilní, takže to bylo fakt vtipné. Porovnej s ARMem, RISC-V, a dalšíma, kde o nějaké kompatibilitě nemůže být řeč.
25. 12. 2025, 15:38 editováno autorem komentáře
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.
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".
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).