Newsgroup: it.comp.hardware.cpu
Titolo: Microsoft abbandona " l'Itanic "...:D

http://www.hwupgrade.it/news/business/microsoft-abbandona-le-architetture-itanium_32157.html


l'Itanic è affondato =)

 
http://www.hwupgrade.it/news/business/microsoft-abbandona-le-architetture-itanium_32157.html
Ma come fino a qualche mesetto fa qui dentro non ce n'erano un paio che 
decantavano le doti di IA64...
ROTFL!
-- 
Saluti
Alec (32,72+,265,CT)
Powered by AMD Phenom II X3 710 @ X4 3.4GHz
Fueled by ATi - Sapphire HD3300-OC
OnLine by Alice TuttoIncluso 7M

 ROTFL!
Comunque c'è da dire che Microsoz ha avuto poca penetrazione per quanto 
riguarda i sistemi di fascia altissima...sistemi dove rientra anche 
l'Itanium.
Ad ogni modo misà che anche alla Intel prima o poi si decideranno di 
abbandonarlo...specialmente considerando che ormai le stesse cpu Xeon 
cominciano a diventare interessanti (la serie 5600 e 7500 sono ottime 
cpu).

 decantavano le doti di IA64...
la diffusione e il successo commerciale sono dovuti a fattori diversi 
dalla qualità del progetto
il progetto AMD64 è stato intelligente dal punto di vista commerciale, 
quello intel era migliore dal punto di vista strettamente tecnico (mi 
riferisco al set di istruzioni, registri e altri parametri 
dell'architettura del processore)
dal punto di vista dell'utente medio di PC non c'è alcuna differenza 
visto che la potenza dei processori è ormai di gran lunga eccedente le 
necessità di un utente base (videoscrittura, browser web, email)
-- 
bye
main(){printf("%u\n",!(!1|1));}

 un utente base (videoscrittura, browser web, email)
Beh certo, per i compti appena descritti basta anche una cpu di 7/8 
anni fa :D


ma quell'architettura (IA64) non era dedicato a quei compiti comunque. 
Ai tempi dell'uscita del primo Itanium io ero quasi 
preoccupato..pensando che si sarebbe di colpo cambiata architettura per 
passare in massa ai 64 bit...ma è sempre il mercato che governa :)) ed 
ha "vinto" l'amd64

 dell'architettura del processore)
No, per quanto possa sembrare strano
IA64/Itanium non era migliore dal punto di vista strettamente tecnico.
Era semmai un esempio di come sia deleterio la "progettazione
per comitato" (troppi cuochi che preparano il piatto ed ognuno
che vuole aggiungere il suo ingrediente speciale senza considerare
cosa succede mischiandolo con gli altri).
Itanium era nato seguendo la moda del momento quando ne fu iniziata
la pianificazione & sviluppo, ovvero le architetture VLIW.
Naturalmente bisognava garantire anche la retrocompatibilita x86
e quindi ... integrano nel chip un core Pentium II completo!
Oltre a questo bisognava ridurre il consumo di memoria (le istruzioni
delle precedenti architetture VLIW "sprecavano parecchio spazio")
quindi viene usato un formato più compatto, è per quel motivo
che invece di VLIW veniva definito inizialmente un EPIC
(Computer con Istruzioni a Parallelismo Esplicito).
Oltre a questo, le prestazioni dei VLIW/EPIC dipendono fortemente
da quanto il compilatore riesce ad ottimizzare il codice
quindi parte della "scommessa" era che mentre procedeva la progettazione
del chip, in parallelo venisse sviluppato un compilatore capace di
ottimizzare dove nessun compilatore era mai giunto prima
(inserire la sigla iniziale di Star Trek mentre leggete
  le righe sopra e comprenderete meglio il senso della "scommessa").
In quel periodo circolavano pubblicazioni secondo le quali
teoricamente si poteva parallelizzare qualsiasi codice seriale
a colpi di ristrutturazioni e loop unrolling senza limiti ecc. ecc.
a patto di avere abbastanza unita di esecuzione indipendenti,
abbastanza registri ecc. ecc.
(notare il *teoricamente*, ci sono dei vincoli pratici che
  limitano le prestazioni reali).
Tanti. Registri.
Tante. Unita. Di. Esecuzione.
Hardware. Di. Supporto. Per. Il. Loop. Unrolling.
Tutta roba "infilata" nell'Itanium presupponendo che con
un colpo di bacchetta magica della fatina buona (il compilatore)
si riuscissero ad ottenere prestazioni vicine a quelle teoriche massime
(usare nel modo più efficiente tutte le unita di esecuzione, usare
  nel modo più efficiente tutti i registri disponibili, ecc. ecc.).
Il risultato e' stato che sebbene fosse già chiaro come ottimizzare
singoli aspetti dell'hardware dell'Itanium (si trattava di problemi
NP-Hard, ma si potevano trovare soluzioni accettabili)
*ottimizzare tutto* si rivelò molto più problematico
(combinando insieme più problemi NP-Hard si ottiene un problema
  di complessità di gran lunga superiore alla loro semplice somma).
Poi iniziarono i problemi dovuti a cosa succede quando
una "bella idea sulla carta, ma complessa" va implementata.
Non e' un caso se gli Itanium hanno avuto problemi mostruosi
nel salire di clock mentre i POWER di IBM sono arrivati a 5GHz
e pure gli x86 hanno avuto un margine di vantaggio intorno
al Ghz rispetto agli Itanium.
L. Micheletto

 IA64/Itanium non era migliore dal punto di vista strettamente tecnico.
i problemi che hai menzionato, saranno venuti a galla dopo
avevo letto qualcosa sull'architettura itanium solo quando vennero
rilasciati i primi esemplari e francamente non ricordo i dettagli, ma
solo che rimasi impressionato dalle caratteristiche
sicuramente avrai ragione, ma il motivo principale per cui, all'epoca,
non si affermò l'itanium (e prima altre architetture tipo i risc ibm o 
poi cell sony-ibm) è che il set di istruzioni x86 era già troppo 
diffuso e la soluzione di amd era molto più efficiente nei riguardi 
della retrocompatibilità
del resto anche in ambito apple, penso che il passaggio
all'architettura x86 sia stato dettato soprattutto da ragioni di
diffusione e conseguenti costi inferiori
ovviamente al di fuori dell'ambito PC, (
p.es
. calcolo scientifico) le 
playstation sono abbastanza popolari per la realizzazione di cluster 
di calcolo a basso costo, al punto che sony ha rimosso (ci ha provato) 
recentemente la possibilità di installare altri s.o. (evidentemente le 
vende ancora sottocosto)


 e quindi ... integrano nel chip un core Pentium II completo!
Se non erro, almeno nella prima implementazione (Merced) le istruzioni 
x86 venivano emulate via software... solo in seguito, visti gli scarsi 
risultati ottenuti ci hanno "ficcato" dentro una cpu dedicata allo 
scopo in tutto e per tutto.


si...con prestazioni penose! Ricordo di aver visto anche qualche bench 
in giro a suo tempo! :D

 i problemi che hai menzionato, saranno venuti a galla dopo
Se sei legato sui binari e vedi che arriva un treno a tutta velocità
è ovvio che *dopo* ti affetta, ma lo vedi arrivare da molto prima.
Mi ricordo di aver letto nel 1995/1996 sull'edizione americana di Byte
i primi articoli su quello che Intel chiamava ancora solo EPIC.
Inizialmente si parlava di un VLIW con la "compressione" del formato
delle istruzioni (i primi VLIW avevano istruzioni "fisse" costituite
da opcode per ognuna delle unità di esecuzione, gli EPIC avevano
dei bit selettori che riducevano lo spreco di memoria)e con
l'esecuzione predicativa come ciliegina sulla torta.
Aveva molti registri ma erano comparabili come quantità ai ROB
(Reorder Buffer) degli x86 tipo Pentium II e Pentium III
quindi non dovevano esserci conseguenze pesanti in termini di latenze
e simili.
Era un VLIW ... senza i difetti dei VLIW quindi in teoria anche se aveva
un sacco di unita di esecuzione ed in media solo una parte di esse
sarebbe stata utilizzata, queste sarebbero state "semplici"
(leggi: facili da far salire di clock) e la logica di
sincronizzazione doveva essere pure essa "semplice" (leggi: ulteriori
semplicazioni rispetto agli x86 ed ai RISC che avrebbero permesso
di far girare l'EPIC a clock superiori).
In pratica un "mostro" che implementato con le tecnologie
a disposizione di Intel avrebbe polverizzato la concorrenza
a colpi di pura potenza di calcolo.
Fu allora che quasi tutti i produttori di sistemi di fascia alta
eccetto IBM e Sun letteralmente si arresero e dichiararono che
sarebbero passati ad EPIC/Itanium abbandonando lo sviluppo delle
loro cpu (IBM dichiarò che avrebbe realizzato sistemi basati
su Itanium, ma continuò anche lo sviluppo dei POWER).
Poi cominciarono a circolare le notizie "strane", tipo l'integrazione
di un intero core Pentium II "per retrocompatibilita" (in realta "solo"
il decoder che poi si appoggiava sulle unita di esecuzione Itanium, ma che 
per switchare tra una modalità e l'altra faceva quasi un reboot
della cpu), l'aggiunta di hardware per "semplificare" certi tipi d
ottimizzazione del codice ecc. ecc.
Il VLIW "senza i difetti più notevoli dei VLIW" stava diventando
un "coso" decisamente più complicato e questo è sempre un brutto segno
perchè significava o che il progetto di base aveva incontrato
qualche problema serio oppure che si era aperta la gara a chi aggiunge
la feature più fantasiosa.
Tieni conto che doveva ancora uscire.
Poi rispetto alla data di uscita prevista cominciano i ritardi ....
Poi esce il Merced ed è decisamente deludente ma ... Intel promette
che la generazione successiva risolverà tutti i problemi ecc. ecc.
E poi si è visto come i problemi sono stati risolti:
il "vecchio RISC" POWER da anni ha sfondato di potenza il muro dei 5Ghz
mentre l'Itanium gli sta qualche Ghz dietro.
Mi sa che Intel avrebbe "staccato la spina" ad Itanium da parecchio
tempo se non fosse vincolata dai contratti firmati a suo tempo con HP.
L. Micheletto

 in tutto e per tutto.
Se ricordo bene il Merced aveva il decoder x86 implementato in hardware
che si appoggiava sul resto dell'Itanium (unita di esecuzione e registri)
per eseguire il codice x86.
Le prestazioni erano circa quelle di un Pentium II ma il passaggio
dal "modo x86" al "modo Itanium" era pesantissimo, era eseguito quasi
come un reset della cpu (doveva flushare quasi tutto).
*Poi* nel 2005 venne rilasciato un emulatore x86
in software con compilazione JIT in "modalità Itanium"
che era più performante del "core x86" (perchè risparmiava
un sacco di switch "pesanti" e la compilazione JIT permetteva di sfruttare
meglio le unita di esecuzione ed i registri disponibili).
Per questo nel 2006 con il Montecito (la terza serie di Itanium)
fu rimosso il supporto hardware per la modalita x86 ormai inutile.
L. Micheletto

 è ovvio che *dopo* ti affetta, ma lo vedi arrivare da molto prima.
certamente e i progettisti intel sono masochisti visto che hanno 
progettato il pentium 4 e l'itanium e lo stesso vale per i progettisti 
AMD e la bacata prima versione del phenom
mai sentito parlare del 'senno di poi'?


Lorenzo Micheletto ha detto questo martedì :

Uhm si... forse hai ragione. Il supporto hardware fu in effetti tolto 
nelle revisioni successive.


Non è questione di senno di poi quando il disastro avviene in fase di
progettazione e ci sono segni evidenti di cosa comporterà.
Azz! Dipendevano dall'efficienza del compilatore e si sono messi
a complicare l'hardware, hanno implementato la retrocompatibilità
in hardware ottenendo prestazioni paragonabili a quelle in emulazione
software (ed infatti poi l'emulazione software ha pure superato
in prestazioni l'emulatore hardware), ecc. ecc.
Per questo ho parlato di "troppi cuochi", non si tratta di senno di poi
quando l'errore di progettazione alla base è vecchio e documentatissimo
in svariati settori (inclusa la gastronomia).
Riguardo agli esempi che hai fatto, considera come sono risultati
realmente e come ed in quanto tempo i loro problemi sono stati corretti.
Il Pentium 4 con tutti i suoi difetti almeno poteva salire di brutto
di clock per compensarli ... e batteva l'Itanium in vari benchmark.
I problemi che ha avuto AMD erano legati fondamentalmente al fatto che
non potevano investire le risorse di Intel e non riusciva a tenere il
passo a livello di tecnologie produttive, ma i loro problemi
architetturali li hanno risolti alla versione successiva.
Nel caso dell'Itanium si parla di una cpu che dopo investimenti enormi
per la prima versione, dopo tre generazioni uscite e circa 10 anni dopo
l'effettiva commercializzazioni e' ancora li con i suoi problemi perché
è stata "incasinata" all'origine e già la versione successiva
si e' ritrovata sul groppone problemi di retrocompatibilita con il Merced.
Gli x86 hanno tonnellate di problemi di retrocompatibilita ma con
gli Itanium quelli di Intel sono riusciti ad accumularne di ben peggiori
in una architettura tutta nuova, non so se mi spiego.
Ricorda, il Merced veniva battuto dalle cpu Alpha il cui sviluppo
era *bloccato da anni* e nella loro ultima versione erano la versione
precedente ma prodotta con la tecnologia fotolitografica successiva.
L. Micheletto



Se non sbaglio il primo Merced aveva una sorta di emulatore,
implementato non so come che offriva prestazioni in linea... con un
P100 (pentium I)
Con McKinley (seconda generazione) si era parlato all'epoca di un core
Deshutes (PII) "annegato" nell'hw Itanic.
In seguito, nel 2005 era arrivato l'approccio JIT, che leggeva l'.exe
x86, lo convertiva al volo in EPIC e ri-memorizzava l'eseguibile
convertito.
-- 
ZHELGADIS THE LIGHTBRINGER (ICQ 33134824)
Now online! 
http://www.eclissati.it
 -> Zhelgadis
"Aspettare non è mai stato un problema, per me.
Posso trascorrere piacevolmente ore e ore con l'aiuto di un buon caffè"

 convertito.
In pratica sono tornati ad un approccio "software" come accadde alla 
lontana con Merced...:)

 convertito.
No, è vero che le prime notizie che circolavano parlavano di un
core x86, ma in realtà avevano "solo" un decoder x86
che poi si appoggiava sulle unità di esecuzione IA64.
Se avessero integrato davvero un core "vero" sarebbe stato possibile
realizzare una sorta di dual core con prestazioni decisamente migliori.
Il Merced supportava il set d'istruzioni del Pentium Pro, solo che
l'esecuzione era inorder (non out-of-order) e combinando la cosa
con la nota debolezza del Merced nell'elaborare dati interi
si ottenevano prestazioni decisamente deludenti in "emulazione" x86.
Con il McKinley fu esteso il set d'istruzioni x86 supportate
e migliorarono le prestazioni (anche perchè le prestazioni
con gli interi del McKinley erano decisamente superiori a quelle
del Merced) ... solo che l'esecuzione rimaneva sostanzialmente inorder.
L. Micheletto