Intel dismette ufficialmente Itanium, il futuro dell'architettura IA-64 resta ignoto

[Redazione di Hardware Upg]

Link alla notizia: https://www.hwupgrade.it/news/cpu/in...oto_80511.html

Intel ha annunciato la morte della linea di processori Itanium: quelli attualmente presenti sul mercato, appartenenti alla serie Itanium 9700, saranno gli ultimi della stirpe. Futuro ignoro per l'architettura IA-64

Click sul link per visualizzare la notizia.

[Siux213]

D'altronde qualcuno ha mai visto qualche server con questa CPU?

[ninja750]

che flop

e anche solo a due anni dal lancio era un casino trovare alcuni programmi compatibili con la piattaforma

[biometallo]

Da quel che ricordo Intel avrebbe tagliato i ponti con itanium anni fa, fu hp ad insistere... da wikipedia (tradotta con google):

Durante la causa di sostegno di Hewlett-Packard Co. contro Oracle Corp. del 2012, i documenti giudiziari aperti da un giudice della contea di Santa Clara hanno rivelato che nel 2008 Hewlett-Packard aveva pagato Intel circa $ 440 milioni per continuare a produrre e aggiornare i microprocessori Itanium dal 2009 a 2014. Nel 2010, le due società hanno firmato un altro accordo da $ 250 milioni, che ha obbligato Intel a continuare a produrre CPU Itanium per le macchine HP fino al 2017. Secondo i termini degli accordi, HP deve pagare i chip che ottiene da Intel, mentre Intel lancia Tukwila , Poulson, Kittson e Kittson + chip nel tentativo di aumentare gradualmente le prestazioni della piattaforma. [52] [53]

[le_mie_parole]

"con ben 128 registri" qualcuno mi sa spiegare con parole semplici ^_^ in che modo questi influiscono sul funzionamento di una CPU e che benefici ne trae? anche perché la differenza con l'x86 è abissale, non è che per mancanza di voglia degli sviluppatori è morta una piattaforma estremamente più performante? (mi ricorda molto, seppur siano due cose totalmente differenti, la fine fatta dai lumia… )

[Slater91]

Originariamente inviato da le_mie_parole

"con ben 128 registri" qualcuno mi sa spiegare con parole semplici ^_^ in che modo questi influiscono sul funzionamento di una CPU e che benefici ne trae? anche perché la differenza con l'x86 è abissale, non è che per mancanza di voglia degli sviluppatori è morta una piattaforma estremamente più performante? (mi ricorda molto, seppur siano due cose totalmente differenti, la fine fatta dai lumia… )

Per farla semplice: i registri sono molto, molto, molto più veloci della RAM. Parliamo di almeno due ordini di grandezza di differenza! Avere quindi più registri a disposizione rende la manipolazione dei dati più efficiente. Lo svantaggio è che la progettazione dell'hardware è molto più complessa e la produzione più costosa (i registri sono tra gli elementi più costosi nella produzione della CPU). Un ulteriore svantaggio, sebbene non direttamente correlato, sta nella progettazione del processore e nel modo in cui gestiva l'esecuzione. Gli Itanium non erano dotati di branch prediction, ovvero della capacità di "prevedere" la prossima istruzione (esempio pratico: la CPU ipotizza che la condizione di un costrutto "if" sia vera e quindi esegue in anticipo il codice seguente), e si affidavano pesantemente ai compilatori affinché svolgessero questo compito in fase di compilazione. Non sempre, però, i compilatori erano in grado di stabilire correttamente l'ordine delle istruzioni: in caso non ci riuscissero (ed accade più frequentemente di quanto si pensi...), il processore doveva andare in memoria a recuperare i dati necessari pagando un prezzo notevole in termini di tempo. Quindi avere così tanti registri, insieme al modello basato su compilatori anziché su logiche di branch prediction nella CPU, portava a rallentamenti durante l'esecuzione rispetto ai processori x86. Ho molto generalizzato e semplificato, se ti interessa la materia posso consigliarti alcuni testi specifici.

[OUTATIME]

Originariamente inviato da Siux213

Non ne sentiremo la mancanza

Assolutamente no.
Se poi mi facessero fin da subito la possibilità di escludere in automatico su WSUS le patch per questa piattaforma sarebbe il TOP

[Phantom II]

Originariamente inviato da le_mie_parole

non è che per mancanza di voglia degli sviluppatori

Non è mancanza di voglia (non lo è mai in una economia di mercato).
E' una questione di costi in rapporto al beneficio (il profitto) ipotetico che si stimava sarebbe stato ottenuto dalla riscrittura del codice.

[le_mie_parole]

Phantom, l'economia di mercato è un falsa leggenda - al di là del caso specifico in discussione, si basa solo sul risparmio di soldi nell'immediato e l'assenza totale di lungimiranza e/o pianificazione e prevenzione di disastri. Ti basti guardare il mondo com'è conciato…
Tornando in topic grazie Slater per le info, più o meno ho capito ^_^ mi interessava una infarinatura e capire le potenzialità dell'architettura rispetto a quella più diffusa. Tanto ormai la "storia" gli ha messo una pietra sopra, e con molta probabilità Intel preferirà dirottare le risorse sulle CPU quantistiche, che ad occhio e croce saranno il futuro in quell'ambito.

[xxxyyy]

No branch prediction quindi no bachi recenti?
Prestazioni mostruosamente più elevate ma bisogna sbattersi per programmare?
Ma si'... buttiamo tutto nel cesso.

[Phantom II]

Originariamente inviato da le_mie_parole

Phantom, l'economia di mercato è un falsa leggenda - al di là del caso specifico in discussione, si basa solo sul risparmio di soldi nell'immediato e l'assenza totale di lungimiranza e/o pianificazione e prevenzione di disastri. Ti basti guardare il mondo com'è conciato…

Non è una leggenda, ma una realtà con cui fare i conti, e che si basa sulla creazione di profitto che non corrisponde automaticamente a un risparmio.
Che poi la si condivida o meno è un altro paio di maniche.

[quartz]

Originariamente inviato da Slater91

[...]
Ho molto generalizzato e semplificato, se ti interessa la materia posso consigliarti alcuni testi specifici.

Ciao Slater,

Io sarei interessato a qualche testo più specifico.
Potresti indicarmene qualcuno?

Grazie,
Quartz

[LMCH]

Originariamente inviato da xxxyyy

No branch prediction quindi no bachi recenti?
Prestazioni mostruosamente più elevate ma bisogna sbattersi per programmare?
Ma si'... buttiamo tutto nel cesso.

TEORICAMENTE più elevate, nel senso che a livello pratico poi non erano così elevate a parità di costo rispetto ai RISC ed agli x86.
Fondamentalmente gli Itanium eccellevano
nell'eseguire codice che si presta ad essere eseguito bene sulle GPU, con di fatto gli stessi problemi di sviluppo software, mentre per il resto stavano nella media quando gli andava bene.

[le_mie_parole]

Phantom, associare la parola economia all'attuale sistema di accumulo di denaro è un ossimoro ^_^ è semplicemente un sistema feudale che invece di aver al centro la terra da coltivare, ha appunto le varie valute, è un dato di fatto, quello che dico è che usano parole associandole a cose che non rappresentano la realtà dei fatti. L'etimologia di economia ha un'accezione positiva, per quello la usano, mentre quella feudale un pochetto meno…

[floc]

peccato, paradossalmente sono stati uccisi dalle gpgpu.

[Dreadnought]

Ormai un normalissimo server x86 quad socket da 80-90.000€ riesce a battere in performance anche la macchina itanium più grande che vende HPE, che ha la bellezza di 16 socket e a listino viene più di 1.000.000€.

Solo in corrente consumata in un anno vale il costo del server x86

[frncr]

Originariamente inviato da Slater91

Gli Itanium non erano dotati di branch prediction, ovvero della capacità di "prevedere" la prossima istruzione [...]

Non è solo questione di branch prediction, ma soprattutto di esecuzione "in order" o "out of order". I processori con capacità di esecuzione fuori ordine, come ad esempio gran parte delle architetture x86 a partire dal Pentium Pro, possono eseguire le istruzioni in ordine differente rispetto a come compaiono nel codice, anticipando l'esecuzione di istruzioni i cui operandi siano già pronti e ritardando quella di istruzioni ancora in attesa di operandi, anche se precedenti nel flusso del codice. Questo permette di sfruttare meglio le varie unità di esecuzione della CPU diminuendo gli stalli, anche in presenza di codice non ottimizzato (non correttamente schedulato dal compilatore o dal programmatore). La previsione statistica dei salti serve invece per attuare la cosiddetta "esecuzione speculativa", che consiste nell'eseguire un flusso di istruzioni prima di conoscere l'esito del salto condizionale che deciderà se devono essere eseguite o meno (salvo poi scaricarne i risultati se la previsione era sbagliata), sempre con l'intento di sfruttare al massimo le risorse di esecuzione disponibili e l'ampiezza di banda della memoria.
Spostare il compito di schedulare le istruzioni dal compilatore alla CPU è vantaggioso nelle architetture con tante CPU molto diverse fra loro sul mercato, come nel caso della giungla x86, dove risulta impossibile ottimizzare il codice a tempo di compilazione per ogni possibile CPU, salvo fare codici differenti con ottimizzazioni diverse e selezionarli a run-time dopo aver identificato la CPU. Lo svantaggio invece è che le CPU diventano più complesse e quindi più costose a parità di prestazioni massime, dovendo sobbarcarsi una parte dei compiti del compilatore o del programmatore.
In un mondo dove il software è fatto sempre più coi piedi, si definisce "programmatore" qualsiasi ragazzino che sa pasticciare con java e il business grosso sta nel rendere obsolescente l'hardware il prima possibile per venderne altro sempre più pachidermico, ci sta che la complessità si sposti sempre più sull'hw stesso (salvo poi trovarsi con problemi come la sicurezza zero, vedi Spectre e compagnia bella).

Nel caso di Itanium, Intel adottò il paradigma "epic" di HP: in pratica il compilatore incorpora nelle istruzioni le indicazioni sia sul parallelismo di esecuzione sia sulla previsione dei salti. Il vantaggio consiste nella semplificazione della CPU e relativa riduzione del rapporto costo/prestazioni, ed era perfettamente logico in uno scenario dove non ci sarebbero state mille diverse architetture di CPU ognuna con le sue esigenze di ottimizzazione differenti.

Il motivo del fallimento di Itanium è da ricercarsi nella mancanza del supporto software e nel ritardo dello sviluppo (il progetto parte concretamente nel 1994 e non si concretizza prima del 2001), con il condimento della cattiva idea di supportare anche il codice x86 (fino al 2006) con pessime prestazioni. Poi nel 2003 AMD ha proposto l'estensione a 64 bit di x86, cosa vantaggiosissima per i produttori sw per la piena compatibilità con tutto il codice esistente (senza penalità di prestazioni), e Intel ha dovuto inseguire per non essere tagliata fuori dal mondo PC. Dopodiché x86 64 ha trovato spazio anche in ambito enterprise, fino a farci i supercomputer, e per Itanium non è rimasto molto spazio, indipendentemente dal fatto che fosse più o meno valida come architettura. La stessa Intel ha offerto le versioni enterprise "Xeon" delle sue CPU già a partire dal Pentium II, per poi proseguire anche con i 64 bit.

L'associazione con GPU computing che qualcuno ha fatto è infondata: Itanium non è un'architettura massivamente parallela, nonostante l'ampia disponibilità di registri (128 integer e 128 floating point). Ha delle limitate capacità SIMD, non più di qualunque CPU x86 dall'introduzione delle istruzioni SSE2 (anno 2000).

[cdimauro]

Originariamente inviato da le_mie_parole

"con ben 128 registri" qualcuno mi sa spiegare con parole semplici ^_^ in che modo questi influiscono sul funzionamento di una CPU e che benefici ne trae? anche perché la differenza con l'x86 è abissale,

Aggiungo un dettaglio a ciò che già t'è stato scritto: i 128 registri non erano tutti direttamente indirizzabili dalle istruzioni. Lo erano soltanto 32. Itanium, però, implementava un meccanismo "a finestre" nelle chiamate a funzioni, dove i registri "scorrevano in avanti" (una parte dei registri della funzione chiamante divenivano i registri coi parametri passati alla funzione chiamata, e e quest'ultima si trovava coi "nuovi" registri a disposizione per le sue variabili locali o per passare eventualmente parametri a un'altra funzione) e "indietro" al ritorno.
E' un meccanismo utilizzato dai processori SPARC, ma l'implementazione qui era più efficiente (perché il processore aveva 128 registri direttamente a disposizione, per l'appunto, mentre SPARC doveva scaricare un po' di registri sullo stack).
Il costo è che il context-switch diventa molto più elevato, ovviamente.

non è che per mancanza di voglia degli sviluppatori è morta una piattaforma estremamente più performante? (mi ricorda molto, seppur siano due cose totalmente differenti, la fine fatta dai lumia… )

No, è morto per altre motivazioni. Ne parlo brevemente dopo.

Originariamente inviato da Slater91

Un ulteriore svantaggio, sebbene non direttamente correlato, sta nella progettazione del processore e nel modo in cui gestiva l'esecuzione. Gli Itanium non erano dotati di branch prediction, ovvero della capacità di "prevedere" la prossima istruzione (esempio pratico: la CPU ipotizza che la condizione di un costrutto "if" sia vera e quindi esegue in anticipo il codice seguente), e si affidavano pesantemente ai compilatori affinché svolgessero questo compito in fase di compilazione.

In realtà Itanium aveva un elegante meccanismo di predicazione delle istruzioni, col quale avrebbe dovuto sopperire per lo più a questi casi. Al costo di eseguire, però, troppe istruzioni non utili (perché non facente parti della predicazione che successivamente si sarebbe dimostrata essere quella corretta).

Non sempre, però, i compilatori erano in grado di stabilire correttamente l'ordine delle istruzioni: in caso non ci riuscissero (ed accade più frequentemente di quanto si pensi...), il processore doveva andare in memoria a recuperare i dati necessari pagando un prezzo notevole in termini di tempo.

Il nocciolo della questione sta tutto qui. Infatti a parte l'inefficienza della predicazione (che va benissimo per casi di poche istruzioni. Infatti è quel che ARM e altri processori hanno implementato, mettendo le istruzioni condizionate. Anche se come meccanismo è di gran lunga meno flessibile rispetto a quello di Itanium), c'è il problema che:
1) tale meccanismo non si può applicare a tutto il codice;
2) l'accesso alla memoria non è sempre prevedibile, e si pagano costi elevatissimi in caso di miss dei dati;
3) i compilatori NON possono mai e poi mai sostituire la logica out-of-order, che è in grado di sapere in ogni ciclo di clock esattamente quali risorse sono a a disposizione, e tentare una schedulazione migliore per le istruzioni, in modo da massimizzare il più possibile l'uso delle risorse.

Originariamente inviato da xxxyyy

No branch prediction quindi no bachi recenti?

I bachi recenti non richiedono necessariamente la presenza della branch prediction.

Originariamente inviato da LMCH

TEORICAMENTE più elevate, nel senso che a livello pratico poi non erano così elevate a parità di costo rispetto ai RISC ed agli x86.
Fondamentalmente gli Itanium eccellevano
nell'eseguire codice che si presta ad essere eseguito bene sulle GPU, con di fatto gli stessi problemi di sviluppo software, mentre per il resto stavano nella media quando gli andava bene.

No, Itanium è abbastanza diverso dalle GPU. Specialmente rispetto a quelle dell'epoca, che non erano certo processori come quelli moderni.

Originariamente inviato da floc

peccato, paradossalmente sono stati uccisi dalle gpgpu.

Vedi sopra.

Originariamente inviato da Veradun

Ennesimo flop. Chissa' cosa sarebbe successo senza pratiche illegali.

A parte che non c'entrano niente le pratiche illegali, quando Itanium è stato progettato da Intel e HP (ricordiamocelo) non era certo chiaro cosa sarebbe successo dopo.
Erano stati fatti degli studi che portavano a quelle conclusioni, e quindi si è tentata quella via, anche tenendo conto del fatto che i compilatori stavano migliorando molto.

Col senno di poi, insomma, è facile giudicare.

D'altra parte se prendi i RISC e le motivazioni per cui sono stati introdotti, puoi vedere tu stesso che sono stati costretti a rimangiarsi quasi tutti i pilastri su cui erano stati fondati, e praticamente divenire dei CISC (oltre al fatto che l'esecuzione OoO è venuta fuori proprio dai RISC, per superare i loro intrinseci limiti).

Per il resto almeno Intel e HP hanno provato a tirare fuori qualcosa di originale, invece di una penosa pezza su x86 messa lì in fretta e furia pur di contrastare Intel con Itanium.

Originariamente inviato da frncr

Spostare il compito di schedulare le istruzioni dal compilatore alla CPU è vantaggioso nelle architetture con tante CPU molto diverse fra loro sul mercato, come nel caso della giungla x86, dove risulta impossibile ottimizzare il codice a tempo di compilazione per ogni possibile CPU, salvo fare codici differenti con ottimizzazioni diverse e selezionarli a run-time dopo aver identificato la CPU. Lo svantaggio invece è che le CPU diventano più complesse e quindi più costose a parità di prestazioni massime, dovendo sobbarcarsi una parte dei compiti del compilatore o del programmatore.
In un mondo dove il software è fatto sempre più coi piedi, si definisce "programmatore" qualsiasi ragazzino che sa pasticciare con java e il business grosso sta nel rendere obsolescente l'hardware il prima possibile per venderne altro sempre più pachidermico, ci sta che la complessità si sposti sempre più sull'hw stesso (salvo poi trovarsi con problemi come la sicurezza zero, vedi Spectre e compagnia bella).

La "giungla" non è un problema tipico di x86. L'esecuzione OoO è nata nei RISC, come dicevo prima.

Inoltre non è anche pigrizia di programmatori e ragazzini improvvisati. Tutt'altro, ma è un discorso complesso.

[ninja750]

Originariamente inviato da Siux213

D'altronde qualcuno ha mai visto qualche server con questa CPU?

purtroppo si, un dbserver su cui era difficile farci girare le cose che non fossero MS

[schwalbe]

Molti commenti partono da una premessa dell'articolo sbagliata:

L'architettura IA-64, arrivata sul mercato con i processori Itanium, avrebbe dovuto sostituire l'architettura x86 secondo i piani di Intel.

L'IA-64 non è mai stata presentata come sostituto per il mondo x86.