Quote:
Originariamente inviato da frncr
Il titolo è sbagliato: Itanium quando fu sviluppato non voleva essere un'alternativa a x86 ma alle architetture usate su workstation o server come PA-RISC, SPARC, MIPS, Alpha, POWER.
Se intendi che avevano un package molto complesso ok, ma dal punto di vista tecnologico non sono mai stati competitivi con nulla, anche perché arrivarono sul mercato con un mucchio di anni di ritardo (oltre 10 anni di sviluppo) e con un rapporto costi/prestazioni improponibile rispetto alle alternative in qualsiasi fascia di mercato. L'architettura Itanium originale (Merced) arrivò sul mercato con un ritardo imbarazzante solo nel 2001, ma si può dire che non è praticamente mai stata venduta perché a quel punto come prestazioni non stava al passo con la concorrenza e costava troppo; ne hanno prodotti ben pochi. Nel 2002 poi arrivò Itanium 2 che se non altro risolveva i più gravi problemi di prestazioni, dovuti alla gestione della memoria, ma ormai era tardi e la pietra tombale la piazzò nel 2003 AMD che uscì con delle CPU da server e workstation (Opteron) con un'architettura x86 estesa a 64 bit, cosa che rendeva immensamente più facile la transizione ai 64 bit mantenendo piena compatibilità con tutto l'ecosistema software a 32 bit esistente (Itanium offriva una modalità di emulazione x86 dalle prestazioni penose). Il seguito lo dovrebbero conoscere tutti: Intel dovette turarsi forte il naso e allinearsi all'architettura AMD64 (o x86-64 che dir si voglia).
Tecnicamente, Itanium era basato sul paradigma "EPIC" (explicitly parallel instruction computing) concepito in HP, una roba che sulla carta sarebbe anche il modo migliore di fare le cose, o perlomeno quello che dovrebbe permettere la massima efficienza nell'uso del silicio e nel consumo energetico: in pratica la parallelizzazione delle istruzioni per tenere occupate il più possibile le unità di esecuzione della CPU viene fatta una volta per tutte a tempo di compilazione e non a tempo di esecuzione dalla CPU stessa, che in questo modo risulta potenzialmente più semplice ed efficiente. Il concetto non è molto diverso da quello delle CPU x86 superscalari con esecuzione in-order (come Intel Pentium e Pentium II, AMD K6, ecc.), anche in quel caso il compilatore ha il compito di analizzare il codice e schedulare le istruzioni in modo da alimentare al meglio le pipeline di esecuzione; però nel caso di Itanium il parallelismo era superiore (per l'epoca) perciò la criticità e complessità del compilatore molto più importante. Le architetture x86 sono invece andate praticamente tutte verso l'esecuzione out-of-order spostando il problema all'interno della CPU, cosa che rende le stesse più complesse ma solleva gli sviluppatori dalla necessità di ottimizzare il codice per ogni possibile diversa CPU su cui potrebbe girare, e in più rende potenzialmente possibile il simultaneous multi-threading.
|
Ma assolutamente si.
Ricordi la storia nei dettagli molto bene, io molte cose non le ricordavo.
Il fallimento di Itanium stava sicuramente nella mancanza di supporto ma c'era in effetti da aggiungere ciò che hai detto tu: uno sviluppo lunghissimo e costosissimo che lo fecero arrivare sul mercato imperfetto, caro e con prestazioni non a livello di una concorrenza che in quel settore già ci navigava da una vita.
Lo ha ucciso il mercato, ma il progetto in sè era tantissima roba.. tenedo ovvimante ben presente che Intel con Itanium partì praticmante dal foglio bianco.