Itanium 2 Montecito: livelli record in virgola mobile

ma perchè gli itanium sono in-order? Nono ffrirebbe migliori prestazioni il calcolo ooo? Forse per il discorso della predicazione è più logico il calcolo in order?

Senza dubbio sulle CPU con esecuzione OOO è inutile un sistema simile alla predicazione, sarebbe un doppione. La tecnologia dell'Itanium comunque lo rende molto competitivo nelle soluzioni multi-CPU, visto che le prestazioni scalano quasi linearmente con il numero di CPU, mentre per soluzioni x86 l'incremento di prestazioni è comunque sensibile, ma non in misura uguale a quella dell'Itanium.
Diciamo che "a occhio" su macchine a 1, 2 o 4 vie conviene Opteron o Xeon (come rapporto prezzo/prestazioni). A 8 vie se la giocano e oltre le 8 CPU è molto più performante Itanium.
Questo supercomputer della NASA ha 10,240 processori Itanium2:

http://www.intel.com/cd/corporate/t.../ita/191240.htm

(chissà se Doom3 "scatta" )

lol!

Grazie delle precisazioni!

Grazie mille per l'info

caspita! ne voglio uno anch'io prima però devo procurami un capannone per mettercelo, ad occhio quanto potrebbe costare?

Ogni approccio ha dei pro e dei contro.

I processori in-order sono più semplici da progettare / costruire e richiedono meno transistor, perché il costruttore ha preferito spostare parte della complessità dall'hardware (chip) al software (compilatore). Per contro, le prestazioni con codice "generico" non possono essere "ottimali", in quanto lo stato del processore è noto soltanto al momento dell'esecuzione.

Viceversa, i processori out-of-order sono più complicati da progettare / costruire e richiedono molti più transistor, perché è la logica ooo a stabilire in che modo devono essere eseguite le istruzioni, e quindi impegnate le risorse, al momento dell'esecuzione. Le prestazioni con codice "generico" sono, quindi, migliori di un s.o. in-order.

L'uso di processori in-order per l'esecuzione di codice "generico" non è quindi consigliata, anche perché il risparmio di transistor (e quindi silicio) non è più un fattore estremamente importante: poteva avere un senso anni fa, ma non adesso che i processori si avvicinano alla soglia del miliardo di transistor (che supererà guarda caso Itanium).

Vanno benissimo in quelle applicazioni massicciamente parallelizzabili e che non risentono di problemi dovuti a stalli della pipeline dovuti a un'errata predizione dei salti, a risorse non disponibili o alla dipendenza dei risultati (anche se quest'ultima è risolta dal compilatore, spesso avviene inserendo istruzioni NOP).
Questo è il motivo per cui Itanium ha delle discrete prestazioni nell'ambito general purpose, ed eccellenti in quelle applicazioni che fanno intenso uso di dati in virgola mobile (in genere si tratta di problemi poco o per niente sensibili ai problemi di cui sopra), mentre con processori x86 o Power si verifica l'esatto contrario.

Un approccio "misto" (integrando logica ooo) per Itanium non avrebbe senso: verrebbero meno i motivi per cui l'architettura stessa è stata creata, oltre ad aumentare la complessità del chip e quindi diminuirne la scalabilità.

Con il sistema di predicazione degli Itanium non c'è ne predizione dei salti ne stallo...

cioè stai dicendo che n vi sn condizioni in cui sia possibile una situazione di stallo negli Itanium?

la discussione si fa veramente interessante! Grazie delle delucidazione, cdimauro!

Non può esserci "stallo per errata predizione", visto che non c'è predizione, come non può ingolfarsi il carburatore in un'auto a iniezione visto che il carburatore non c'è l'ha.

...O meglio, la "predizione" ([u]statica, però, e demandata al compilatore e non alla CPU[/u]) esiste negli Itanium per il programmatore che decide di non avvalersi della predicazione, solo in quel caso puoi avere stallo.
Secondo me, però, sarebbe come comprare una Ferrari e metterci l'impianto a GPL. L'Itanium è fatto per sfruttare il parallellismo a livello di istruzioni (ILP) attraverso la predicazione. Scegliere di utilizzare i salti condizionati invece dei predicati equivale a scegliere di far andar piano i programmi.