Názory k článku
LoongArch bude oficiálně podporovanou architekturou pro připravovaný Debian 14
-
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).
-
Ondra Satai NekolaZlatý podporovatelAle prosimtě, je jedno, že se udělá jiná práce, dokud u ARMu vyjdou lepší čísla!
Osm? Rozuměl jsi?! Osm!!!
-
DannyStříbrný podporovatelMuzete se ji chopit, pokud vam tak chybi :-) Jak uz to tak byva, podpora jednotlivych architektur proste a jednoduse stoji a pada s tim, jestli se o to nekdo ma duvod starat...
-
DannyStříbrný podporovatel
A proc bych to psal ja cinanum? To vy zde brecite, ze Debian opustil MIPS. Vyse mate vysvetlene proc. Vy sam se do udrzovani kodu zjevne take nehrnete - a zda se ze ani do toho vysvetlovani cinanum :-) Pokud vam MIPS opravdu chybi, tak s tim neco delejte - a nenadavejte tem, kterym podpora MIPS nechybi.
-
Tak třeba své patche pošleš komunitě a podpoříš podporu MIPSu.
Tendle projekt aktualizuji kazdych par let uz od dob kernelu 2.6.32 a k upstreamovani tam toho dnes moc neni, protoze samotny CPU funguje dobre s vanilla kernelem a upstreamovat ovladace pro custom HW, ktery si nemuze nikdo koupit, nedava smysl. Svuj komentar jsem zde pridal proto, ze spousta lidi ma naprosto zcestnou predstavu o tom, jak dlouho se udrzuji v aktivnim protozu vestavene systemy. Tento produkt je komerecne v provozu od 2012 a EOL je planovanej na 2034, v soucasnosti jsou porad v provozu desitky tisic instanci. Jsou pripojeny do site, takze se to samozrejme musi aktualizovat. -
DannyStříbrný podporovatel
Embedded systemy ale obvykle nepotrebuji plnotucny Debian, ale jen velmi omezeny subset software. Ta diskuze zde byla i o tom, ze Debian utnul podporu cele distribuce. Jenze ono holt podpora Debianu na MIPS znamena neresit jen par vybranych veci - a pak teba dava smysl sahnout treba po OpenWRT - kde i toho software je min a tudis ve vysledku i udrzba podpory jednodussi.
Aneb ano, u sveho projektu si muzete tech pro vas par potrebnych veci udrzovat a patchovat dle potreby. Ale holt se obcas musite smirit s tim, ze to neudela nikdo za vas... ostatne, pokud vas to opravdu zivi, i cena by s tim asi mela pocitat.
-
Detail: ví se, že 6.18 bude LTS, ne 6.20 (které bude v Ubuntu 26.04 možná).
-
A kdo dnes vyrábí MIPS? Ta architektura umřela jako mnoho dalších.
RISC-V vychází z MIPS, ale je to nová architektura. No a loongarch vychází z MIPS taky, ale je to nová architektura.
Upřímně LA64 mi přijde mnohem lepší než RISC-V (hlavně pokud se bavíme o praktičnosti) bez ohledu na původ té architektury.
-
Problém LongArch je v tom, že to ti Číňani patlají tak, že není kompatibilní ani sám se sebou (vzorky pro firmy pro portaci komerčních aplikací nebyly kompatibilní s finálními procesory - closed source aplikace na nich pak neběžely) a na bezpečnost úplně kašlou (např. zápis do půlky registru nastaví bity v druhé půlce podle toho, zda se vejdeš do cache line, a v ISA je to nedefinované).
EDIT: Jinak ano, MIPS je mrtvý. Čínská odnož pokračuje v LongArch a západní v RISC-V (uznali, že nemá smysl dělat novou major verzi MIPS, když by o ni stálo méně lidí než o RISC-V, a ten z ideí MIPS dost vychází).
26. 12. 2025, 00:22 editováno autorem komentáře
-
Já bych neřekl, že vychází. Obě architektury jsou nové a nekompatibilní. Paradoxně toho MIPSu je možná víc v LA64.
Já bych ani netvrdil něco o východu a západu. RISC-V mi přijde nepraktická architektura, jako kdyby ti co na tom dělají měli radši teorii než praxi a nechtěli aby to bylo to "lepší" než AArch64. Kdežto LA64 mi přijde praktická - prostě chcou relativně jednoduše čerpat z existujícího ekosystému - jednoduše portovat AVX2 kód pro LA64, atd...
Já na RISC-V nevidím vlastně nic hezkého - až fanaticky vytvořená architektura, která nemá CPU flagy, a pak celé RISCV-V nutně potřebuje vsetvli - je to paskvil.
