Itanium 2 Montecito: livelli record in virgola mobile

Per essere precisi, l'approccio di Intel con Itanium è simile a quello di Niagara, dove la CPU cambia thread di esecuzione di fronte a uno stallo. Quindi è un approccio un po' diverso e meno efficiente di quello adottatato per il P4 o da IBM col Power5, dove i thread presenti si contendono le risorse (il Power5 ha una logica molto fine per farlo, e addirittura il s.o. può controllarne alcuni aspetti).

Francamente non ricordo se Intel ha già adottato il CMP con qualche versione di Itanium 2, o lo farà in un prossimo futuro.

Esatto: le cause sono molteplici.

Esattamente. E comunque, anche se riesce a fare un buon lavoro, di fronte a certe situazione tutt'altro che rare, è l'architettura stessa dell'Itanium a fare da freno.

Ad esempio, con un codice "poco diffuso" come questo:
[CODE]
for i := 1 to n do
[...][/CODE]
alla fine di ogni ciclo la CPU sbaglierà la predizione n - 1 volte, e sarà costretta a svuotare e riempire la pipeline a causa del salto all'inizio del ciclo. Soltanto all'n-esimo ciclo continuerà l'esecuzione senza intoppi.
In questo contesto è evidente l'efficienza di un processore ooo: il salto verrà predetto correttamente n - 1 volte, e soltanto l'ultima fallirà.

Il compilatore può aiutare Itanium, mitigando la penalizzazione dovuta ai salti, effettuando loop unrolling, ma fino a un certo punto: anche la dimensione del codice è un fattore importante, per cui sarà costretto a trovare una soluzione di compromesso fra il numero di cicli da eseguire e lo spazio occupato.
Considerato che i bundle di Itanium sono costituiti da 128 bit (sono ben 16 byte), e che contengono al più 3 istruzioni "utili" (anche sui bundle ci sono parecchi vincoli: non si possono inserire arbitrariamente le istruzioni, come avviene con la maggior parte delle architetture VLIW), è facile che lo srotolamento dei cicli porti a un eccessivo consumo di memoria. Consumo di memoria -> banda consumata per caricare il codice in cache.

Anche le rose più belle hanno pur sempre le spine...

Dimenticavo: processori ooo moderni, come gli x86, che non usano il raffinato sistema di predicazione di Itanium, hanno comunque delle migliorie architetturali che aiutano molto nei casi più comuni.

Ad esempio, il vecchio PentiumPro ha introdotto le istruzioni CMOV e FCMOV, che consentono di eseguire o saltare l'istruzioni di spostamento di un registro, a seconda del verificarsi di una precisa condizione.

Inoltre con le SSE2 Intel ha introdotto anche due speciali prefissi per le istruzioni di salto, che "suggeriscono" alla logica di branch prediction se quel salto è più o meno soggetto ad essere eseguito.

Piccole migliorie, che costano poco, ma che permettono di risolvere in maniera efficace certi problemi comuni, anche se non eleganti come la soluzione di Itanium... Ma alla fine contano le prestazioni, non l'eleganza di un'architettura...

Nemmeno il compilatore che trovi nel Dixan non produrrebbe un codice dal comportamento simile. Esistono predicati fatti ad hoc per i cicli for e while:
br.cloop, br.ctop e br.cexit per i cicli for e br.wtop e br.wexit per i cicli while.

...E poi esistono delle istruzioni che permettono di effettuare predizione statica e dinamica (solo che devono essere inserite nel codice dal compilatore): spnt, sptk, dpnt e dptk.
...Poi ci sono i prefetch hints ed i predictor deallocation hints.

La pipeline dell'Itanium, inoltre, ha solo 8 stadi (con un instruction buffer inserito tra i primi 2 stadi di front-end e gli ultimi 6 di back-end) quindi soffre poco lo stallo anche per quello...