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?
Není na Debianu založena ta čínská státní distribuce? Ono není moc možností, na čem takové distribuce založit. Fedora? Ubuntu? Arch? Gentoo?
Ale tak uznej ze vsechno vsude nebezi. Jednak nejsou invalid opcode handlery v sw emulaci (podobne jak se kdysi resil softem FPU?) a pak jeden kod (OS) nebude bezet na ruznych x86 cpu, protoze kazdy ma svoje vlastni MSR, ktere je treba nastavit ruzne pro ruzny modely cpu.
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.
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ů.
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).
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
Muzete 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...
A co se zacist do duvodu, ktere k tomu byly? A racej si vsimnout, ze to umrelo prave proto, ze se nenasel nikdo, kdo by byl ochotny to resit - protoze ono to neni tak jednoduche, jak si myslite. Mohl jste se prihlasit, kdyz tomu tak ruzumite ;-)
Přesně tak. Čínský Longsoon vychází z MIPS a západní odnož MIPS sama řekla, že nemá smysl vydávat novou major verzi, když je tu RISC-V, který se principy MIPS hodně inspiruje a zajímá řádově více lidí a firem.
Super, takze ked rusko alebo severna korea vyvinie novy procesor na zaklade MIPS tak mi budeme utekat aby sme ho podporovali...
Kdo "budeme"? Vy někam utíkáte? Pak je to váš problém. A pokud neutíkáte, co do toho mluvíte ostatním?
Toto je diskusia/polemika ja som myslel ze tu kazdy v ramci slusnosti moze hovorit co chce alebo uz tu mame cinu ?
Toto napis cinanom, myslim ze maju na to kapacity kapacity aj peniaze na individualny vyvoj, nie je treba utekat z otvorenou narucou...
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.
MIPS dodnes pouzivaju prakticky vsetky laboratorne meracie pristroje a tam nikdy cinana nepustia. Osobne mi to az tak nechyba lebo vecsinou len citam data z tychto pristrojov ale fascinuje ma ako ludia opustaju overene riesenia ktore maju urcitu firemnu kulturu.
Lidi žádné ověřené řešení neopouštějí. Na ty měřící přístroje nový OS stejně nebudeš instalovat a podpora CPU architektury je jen jedna z věcí. Např. můj zubař má rentgen s Windows 98.
Ja zrovna ted mam zakazku na update zarizeni zalozeneho na mips na jadro 6.12, takze to tak mrtve neni.
Tak třeba své patche pošleš komunitě a podpoříš podporu MIPSu. A vývoj zaplatí zadavatel zakázky.
25. 12. 2025, 13:55 editováno autorem komentáře
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.
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.
Proc 6.12 prave? kdyz uz jde o update.. tak vzit to nejposlednejsi, ne? Navic se sepota ze 6.20 bude LTS ? Nez to kluci dodelaj, vy udelate port a vsichni budou stastni :-)
Detail: ví se, že 6.18 bude LTS, ne 6.20 (které bude v Ubuntu 26.04 možná).
LTS uz nie je vlastne LTS pri tej smiesnej dlzke podpory je skoro jedno co tam das. Inak tu v labaku odhadujem ze tak 70% pristrojov ma MIPS :-)
RE: "Kolik z nich budete upgradovat na nový Linux?"
Tipnul bych si, že většina, těch zařízení nový Linux nepotřebuje a "spokojeně" mohou fungovat dál, dokud budou dostupné náhradní díly.
Problem je, ze s novym GCC nezkompilujujete stary jadro.
Takze potrebujete stary GCC ... a to zas nese dalsi zavislosti ... takze ne, vyhazovani kodu neni reseni - protoze namisto inkrementalnich zmen pro nove verze vseho - jste najednou totalne zasekan do minulosti.
Tipnul bych si, že většina, těch zařízení nový Linux nepotřebuje a "spokojeně" mohou fungovat dál, dokud budou dostupné náhradní díly.
Ne, nemuzou. Ta zarizeni jsou v siti a musi mit podporovany system. 6.12 ma pres CIP podporu do 2035.
Proc 6.12 prave? kdyz uz jde o update.. tak vzit to nejposlednejsi, ne?
Delam to, co si objedna zakaznik.
25. 12. 2025, 21:59 editováno autorem komentáře
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.