Intel ritorna al brand Itanium

[Redazione di Hardware Upg]

Link alla notizia: http://www.hwupgrade.it/news/server/...ium_24439.html

Da Marzo scomparirà il numero 2 a identificare le cpu Intel della serie Itanium, specificamente sviluppate per sistemi server ad elevate prestazioni

Click sul link per visualizzare la notizia.

[commodoro]

WOW!!!!

però riunendo tutti questi processori sotto il nome unico di Itanium, non si farà un pò di confusione tra quelli di una generazione e l'altra?

[MadMax of Nine]

Su carta sembra mostruoso... vediamo

[Kuarl]

è mostruoso, ma gli ambiti di impiego sono assai ristretti...

peccato perché è veramente un ottimo processore.

[sfarago]

mostruoso mica tanto... intanto c'è da considerare che Itanium è un processore a 64bit le cui istruzioni non sono di per sé molto efficienti e questo impatta negativamente sulle dimensioni del codice. Quindi il codice oggetto prodotto dai compilatori è molto grosso e di conseguenza anche l'efficienza della cache ne risente. Per questa ragione Itanium è sempre stato dotato di cache generose. A grandi linee, in termini di efficienza operativa, si può considerare che 30MB di cache Itanium= 15MB di cache su processore X64 o PPC.
A questo si aggiunge che i binari Itanium sono "grossi" il doppio rispetto a quelli prodotti per x64. E questo fattore, oltre ad impattare sulla cache, impatta anche sulle altre risorse di sistema. Nel senso che avere un 1GB di ram su una macchina Itanium produce gli stessi effetti di avere 512MB su un x86 o PPC. Idem x dischi. Infine, gli Itanium non hanno nessun suppo
Vero è che Itanium è dedicato a sistemi high-end dove i costi non sono un grosso problema. Oltre a tutto questo, Itanium non è dotato, per scelta, di circuiti per l'ottimizzazione del codice in fase di esecuzione. Ne consegue, che ad ogni generazione di processori, se si vuole ottenere il massimo in performance, bisognerebbe procedere alla ricompilazione del software.

[shodan]

Originariamente inviato da sfarago

mostruoso mica tanto... intanto c'è da considerare che Itanium è un processore a 64bit le cui istruzioni non sono di per sé molto efficienti e questo impatta negativamente sulle dimensioni del codice. Quindi il codice oggetto prodotto dai compilatori è molto grosso e di conseguenza anche l'efficienza della cache ne risente. Per questa ragione Itanium è sempre stato dotato di cache generose. A grandi linee, in termini di efficienza operativa, si può considerare che 30MB di cache Itanium= 15MB di cache su processore X64 o PPC.
A questo si aggiunge che i binari Itanium sono "grossi" il doppio rispetto a quelli prodotti per x64. E questo fattore, oltre ad impattare sulla cache, impatta anche sulle altre risorse di sistema. Nel senso che avere un 1GB di ram su una macchina Itanium produce gli stessi effetti di avere 512MB su un x86 o PPC. Idem x dischi. Infine, gli Itanium non hanno nessun suppo
Vero è che Itanium è dedicato a sistemi high-end dove i costi non sono un grosso problema. Oltre a tutto questo, Itanium non è dotato, per scelta, di circuiti per l'ottimizzazione del codice in fase di esecuzione. Ne consegue, che ad ogni generazione di processori, se si vuole ottenere il massimo in performance, bisognerebbe procedere alla ricompilazione del software.

Attenzione, perchè dire che il set di istruzioni VLIW non sia efficiente non è propriamente corretto: in condizioni ideali (con tutti gli slot istruzioni occupati), l'architettura VLIW permette di raggiungere un elevato grado di parallelizzazione _senza_ richiede l'aggiunta di costosa (in termini di transistor) e complessa logica per esecuzione out-of-order.
Questo implica che la responsabilità relativa alla schedulazione delle istruzioni passi nelle mani del compilatore, che non sempre (per diversi motivi) riesce a risolvere le dipendenze nel migliore dei modi.
In altre parole, come giustamente fai notare, l'architettura Itanium dipende molto dalle performance del compilatore: quando queste sono basse, anche la velocità di esecuzione del codice verrà fortemente limitata; d'altro canto, se il compilatore fa bene il suo lavoro, Itanium riesce a spuntare prestazioni davvero elevate.

Ciao.

[darkx]

Quoto shodan. Il confronto fatto da sfarago non ha senso visto che si parla di architetture completamente differenti.

[sfarago]

E' vero che sono architetture differenti e shodan ha ragione a chiarire meglio il mio pensiero. Ma alla fine quello che conta sono le prestazioni finali rapportate ai costi...

[Dreadnought]

Da noi si dice: dove un server x86 arriva, itanium parte.

I server itanium che ho montato sono utilizzati soprattutto per DB pesanti in cui ci sono tantissime transazioni al secondo e un normale Xeon non ce la fa a stargli dietro.
Ovvio che i prezzi di un server dual itanium, partendo da 8000-10000 euro solo l'HW non sono alla portata di tutti...

Fattore cruciale per una piattaforma itanium è il chipset che viene in genere prodotto dai vari vendors, se è fatto bene quello, tutto il sistema ne guadagna.

[LMCH]

Originariamente inviato da shodan

Attenzione, perchè dire che il set di istruzioni VLIW non sia efficiente non è propriamente corretto: in condizioni ideali (con tutti gli slot istruzioni occupati), l'architettura VLIW permette di raggiungere un elevato grado di parallelizzazione _senza_ richiede l'aggiunta di costosa (in termini di transistor) e complessa logica per esecuzione out-of-order.
Questo implica che la responsabilità relativa alla schedulazione delle istruzioni passi nelle mani del compilatore, che non sempre (per diversi motivi) riesce a risolvere le dipendenze nel migliore dei modi.
In altre parole, come giustamente fai notare, l'architettura Itanium dipende molto dalle performance del compilatore: quando queste sono basse, anche la velocità di esecuzione del codice verrà fortemente limitata; d'altro canto, se il compilatore fa bene il suo lavoro, Itanium riesce a spuntare prestazioni davvero elevate.
Ciao.

Il problema e' che Itanium non e' un "semplice" VLIW ma piuttosto
una "cpu progettata da un comitato" (ovvero con tutti a voler fare
aggiunte della loro feature hardware preferita, non importa
che se combinata con le altre crea problemi di implementazione).

Il risultato e' stato che le cpu Alpha EV6 (il cui sviluppo era ormai
bloccato da prima che uscisse quell'aborto dell'Itanium Merced)
con un semplice shinking battevano in prestazioni gli Itanium
di SECONDA generazione!!!!!! (i Mc Kinley, se ricordo bene)

Gli Alpha erano dei RISC "duri e puri" risalenti ai primi anni '90
progettati da un team e mica da un comitato, non so se mi spiego.

Quel che ha salvato gli Itanium e' che Intel ed Hp ci avevano
messo la faccia ed un pozzo di soldi di cui avrebbero dovuto render conto
agli azionisti se avessero cancellato il progetto ed Hp li aveva proposti
ai suoi clienti "pregiati" in sostituzione dei PA-RISC e degli Alpha
(ex-DEC ed ex-Compaq) a cui non poteva proporre un altra sanguinosa
migrazione di architettura; fortunatamente Intel li poteva produrre
con cache enormi rispetto alla concorrenza e questo gli ha permesso
di non sfigurare troppo senza contare che per molto software
legacy non c'erano alternative, se ad esempio vuoi qualcosa
che faccia girare il VMS praticamente l'unica scelta e' l'Itanium.

Infatti a parita' di costo e di complessita' circuitale
ci sono soluzioni basate sui POWER di IBM
che danno prestazioni superiori rispetto ai sistemi Itanium.

L'unico vero pregio dell'Itanium e' che ha dato una spinta notevole
alla competizione nel campo dei compilatori ... di cui hanno tratto
vantaggio anche le altre architetture (le ottimizzazioni "deterministiche"
valide per un grande set di registri si possono applicare in forma
"statistica" alle cache L1, le ottimizzazioni di schedulazione
si possono applicare anche alle altre architetture imponendo
dei vincoli aggiuntivi, idem per le ottimizzazioni automatiche
basate sui profili di esecuzione, ecc. ecc.).

[homero]

itanium?!?!?
simply the best