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/
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í.
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?)
Ak niekto taký HW prevádzkuje, veľmi pochybujem, že s Linuxom. Sila Linuxu bola vždy hlavne v behu na lacnom komoditnom hardvéri, čím prevalcoval komerčné unixy na drahých proprietárnych strojoch. Nemalo zmysel mať drahý stroj na lacný systém, ktorý jeho prednosti nevyužije (existoval aj Windows Server pre Itanium, tuším 2003-ka, ale ten tiež skoro nikto nenasadzoval).
Linux pro Itanium byl portován přímo za asistence Intelu v rámci Project Trillian a například na strojích SGI Altix to byl jediný podporovaný systém. Na FI MUNI byl v roce 2007 nasazený SGI Altix 450 pro provoz databáze Oracle:
https://is.muni.cz/blog/is_info/nov_20070814_novy_hw_pl
Na Integrity strojích se asi provozovalo spíš VMS nebo HP-UX.
Tak ako hovoris, HW uplne v inej cenovej kategorii. Par nasich zakaznikov to tak malo.
Napr. na superdomoch sa vytvoril jeden npar prave pre Windows. Ostatne npary boli HP-UX. Ale bol to skor zriedkavy setup.
Design z 2005, mozno to niekto kupil este v 2008. Postupne to prestalo davat financne zmysel. A kedze HP malo svoje vlastne problemy tak to islo postupne do zabudnutia.
Este mam par zakaznikov na Itaniach, ale vsetko su to HP-UX.
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).
Presne tak. Ono se od VLIW designu odklonili nakonec i grafiky od obou tahounu.
Duvodem bude nejspis cena kremiku/transistoru a vubec moznost dat na cip toho tolik - takze neni treba vymyslet sw reseni, kdyz to jde poresit na hw urovni.
Myslim ze si mnoho lidi neuvedomuje, ze HW bobtna podobnym zpusobem jako sw - namisto asm/C mate najednou managed jazyky a skripty.. a v hw zas jedou reorder buffery a spekulativni vykonavani - vsak proc nespocitat obe vetve a pak jednu zahodit.. nez aby bylo nutne na ni cekat. Tohle spotrebuje hodne kremiku, ale prakticky je zisk dost znatelny.
Takze prakticka moznost udelat cpu, ktery ma vysledky nekolika paralelnich vetvi kodu vlastne zabilo ono tupe reseni, kdy program rika co ktera cast cipu ma delat.
Jiste ze to pocita ruzne vetve, od toho se tomu rika speculative execution.
https://en.wikipedia.org/wiki/Speculative_execution
(a kolik ze to chyb se v tom nasekalo.. :)
SIMD a threads je neco jineho nez VLIW.. a prece rikam ze ty gpu co meli VLIW uz davno vyrobci zanechali.
Počítat obě větve je pouze jedna z variant Speculative Execution a IMHO nepříliš častá (pokud vůbec), neboť je příliš drahá.
Spíš se používá branch prediction a pokud byl odhad špatný, tak se výsledek zahodí a začne se správnou větví. Což navíc zpomaluje ty vulnerabilities, bo nejdřív musí oblbnout branch prediction a teprve potom něco zjistit.
Zrovna nedavno jsem vyhazoval nejake servery s HP PA-RISC a Itaniem ...
tak jsem to rozvrtal a alespon jsem se na to CPU kouknul https://imgur.com/a/1tLKDxU