Vlákno názorů k článku
Podpora procesorů Intel Itanium IA-64 bude odstraněna v jádře 6.7 od Erin - Škoda Itania, kdyby ho tak rychle nezahrabali...

Škoda Itania, kdyby ho tak rychle nezahrabali...

Zatím po revertu všechno funguje i přes tisíce commitů které přistály v rámci merge window:

https://github.com/lenticularis39/linux-ia64/tree/master-revert-ia64-removal

A Linus Torvalds je ochotný podporu vrátit, pokud se ukáže, že je udržitelná out-of-tree: https://lore.kernel.org/linux-ia64/CAHk-=whFLZ67ffzt1juryCYcYz6eL_XjQF8WucDzwUR5H65+rA@mail.gmail.com/

Nějaké argumenty? Podle mě to byla architektura určená k zániku. Nemohlo to přežít.

Např. že v seL4 (nebo nějaký příbuzný to byl) trvalo jedno IPC volání méně cyklů než celočíselné dělení.

Ale jde i o to že nejen emulace IA-32 byla nic moc, ale jelikož nepodporovali out of order execution a nechali to na překladačích které nebyly tak dobré.

Kdyby se tomu věnovalo více, bylo by to určitě fajn, ale AMD64 bylo industriálně v té době výhodnější řešení tak to bohužel k zániku odsouzené je.

Itanium totiž nemá celočíselné dělení ani modulení, má pouze reálné dělení a k celočíselnému napsal Intel pomocné funkce, které využívají právě reálné dělení. V kombinaci s tím, že v rámci GCC se přeloží tyto operace na volání funkce, a tudíž je není možné paralelizovat, to vede ke ztrátě až poloviny výkonu oproti kódu v assembleru (Itanium 2 má dvě FPU, kód generovaný GCC využije i v cyklu jen jedno).

> v seL4 (nebo nějaký příbuzný to byl) trvalo jedno IPC volání méně cyklů než celočíselné dělení

To moc neříká. Může to být i tím, že celočíselné dělení trvalo moc dlouho.

> nepodporovali out of order execution a nechali to na překladačích které nebyly tak dobré.

V tom vidím problém. Nechat to na překladači má svoje výhody (není potřeba to řešit opakovaně), ale když budete chtít v další generaci upravit něco, co změní nejvýhodnější pořadí instrukcí, najednou musíte všechno rekompilovat. Řešit lze leccos, ale dovedu si představit, že by to mohla být celkem komplikace.

Já to vidím jinak.

ISA je dnes v podstatě frontend - CPU dekóduje instrukce do uops a ty zpracuje. Toto je nejjednodušší způsob jak docílit toho, že nové generace CPU můžou mít lepší výkon a uvnitř může dojít k velkým změnám, které se ale nedotknou kódování instrukcí. Takže nové CPU jsou binárně kompatibilní s předchozí generací - celý ekosystém zůstává.

Itanium v tomto případě víc odhaluje (expose) design CPU a toto je do budoucna to největší omezení. Vzpomeňme si na 32-bit ARM, kdy PC registr už obsahoval PC + 8 kvůli tomu, že původní pipeline měla 3 stages. Dnes už je pipeline mnohem komplikovanější, ale PC je stále PC + 8 kvůli zpětné kompatibilitě.

Samozřejmě tam bylo mnohem víc důvodů, ale čistě z ISA hlediska by to byl podle mě taky problém tu architekturu vůbec dál rozvíjet. Příliš mnoho práce pro compiler, JIT, atd... Já jsem rád, že tato architektura je mrtvá a už nebude nikoho dál strašit.

Ještě bych k tomu dodal, že exposovat design procesoru si může dovolit třeba GPU, ale tam nejvíc práce udělá driver, takže to není až takový problém (teda kromě toho, že pokud není driver open-source tak každá nová generace GPU je problém).

4. 11. 2023, 12:25 editováno autorem komentáře

Z komerčního hlediska nemohlo, z praktického hlediska je problém ve špatné kvalitě open source překladačů (výstupní kód je pomalý) a matematických funkcí od Intelu (od samého začátku s rozbitým error handlingem floating point funkcí jako je sin, cos atd.), který přestal do architektury brzy investovat a od té doby se o ni staralo pouze HP.

Kód přeložený kompilátorem od HP je výrazně lepší, JIT JDK 8 dodávané HP také není špatný. Přes to je ale Linux použitelný a nebyly žádné výrazné problémy ani potřeba údržby kódu specifického pro tuto architekturu.

V kernelu jsou také i jiné architektury, jejichž výroba procesorů skončila mnohem dříve, jmenovitě Alpha a HPPA, které obě nahradilo právě Itanium, a nediskutuje se zrovna o jejich odstranění.

Tak třeba zmíněná Alpha je ale jednoduchá RISC architektura, na údržbu asi mnohem lepší než Itanium :)

Osobne neviem, kto to ešte prevádzkuje. Možno nejaká obskúrna inštitúcia, kam chodí raz za čas šedivý pán z múzea počítačov s tričkom D I G I T A L vymienať vytečené kondenzátory. Je to napojené na obsluhu letiska, alebo na kontinuálny transfunkcionér v chemickej továrni. Predtým tam bežal VMS, alebo custom UNIX. (ULTRIX?)

Alpha AXP predbehla time_t o 15 rokov.

Potom prišla Carly Fiorina a ostatné je už hist[óé]ria.

Mohlo to přežít, ale přišlo něco, co se ujalo víc. Tak už to někdy bývá.

Já reagoval čistě na návrh Itanium architektury. Kdyby to bylo něco opravdu převratného a efektivního, tak věřím tomu, že by v té architektuře někdo viděl inspiraci, to se ale nestalo a X86_64, AArch64 a RISC-V jdou úplně jinou cestou.

Návrh převratný není. Obyčejný DSP procesor. Tehdy byla idea, že dekodér instrukcí bere moc plochy a že by nemusel být "hardwarový" a přesunulo by se to do software (např. jak jsme měli/máme softwarové zvukovky, síťovky a třeba ZX Spectrum mělo i softwarový RAMDAC). Časem se ale ukázalo, že přerovnáním v out-of-order execution mnohem lépe využijeme výpočetní jednotky (časem jich hodně přibylo) a schováme interní architekturu CPU od aplikace (není třeba ji překompilovat pro efektivnější běh).