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

Il debutto delle cpu Itanium 2 basate su core Montecito si avvicina: Intel annuncia valori record per le performances di questi sistemi nell-esecuzione di calcoli in floating point

Click sul link per visualizzare la notizia.

Quello screenshot e' veramente incredibile...

quattro processori dual core... e 16 colonne CPU? C'è puzza di HyperThreading... :)

16 unita logiche? sta minc**a (scusate il termine)

quattro processori dual core... e 16 colonne CPU? C'è puzza di HyperThreading...
lol... c'è anke scritto nell'articolo che usa l'HT ;).

Chissa che consumo... :(

JAP :oink:

guarda che quando lo compri devi sottoscrivere anche un contratto con l'enel per almeno 15Kwatt..altrimenti ti salta l'automatico..... :O

come da oggetto ;-)

io vorrei vedere quelle sedici colonnine al 100% con seti@home

va be che è pura utopia con itanium, però sbavvvvvvvv :sbav:

...bello...ma il raddoppio di volta in volta è avvenuto raddoppiando i core logici...

Nulla di particalare....

Personalmente la cosa non mi stupisce, l'ISA EPIC e l'architettura della famiglia Itanium hanno un potenziale notevole, a dispetto del loro successo commerciale. Complimenti ad Intel ache se questa pare una vittoria di Pirro..

Sbaglio o e' rimasta solo HP come partner di intel per gli itanium?

Ciao ;)

Da sempre intel considera il segmento Itanium come "palestra" per le innovazioni tecnologiche, mettendo in secondo piano i profitti derivati.

E' davvero affascinante vedere 16 cpu logiche! Ma che SO è quello? Win Server 2003? Non pensavo sapesse gestire tutte queste cpu.

l'itanium è uno dei più potenti proci esistenti per mainframe... questa notizia poi è assolutamente sconvolgente...

Da sempre intel considera il segmento Itanium come "palestra" per le innovazioni tecnologiche, mettendo in secondo piano i profitti derivati.

beh penso che quantomeno all'inizio ci sperasse (visto che il progetto e' partito almeno 10 anni fa).
Poi visti i problemi (difficolta' di emulazione del codice "legacy" 32bit) e la concorrenza (Opteron) penso stia cercando solo di rientrare degli investimenti fatti :D

Sono senz'altro degli esercizi di stile molto ben riusciti ;) ;)

...quindi se ho capito bene tutto il lavoro che sta alla base di Itanium con il paradigma V.L.I.W E.P.I.C, progetto partito in epoca di Pentium PRO sarebbe solo un "esercizio di stile" mentre tutto ciò che viene concepito e prodotto ad esempio da A.M.D (che ha la sua produzione di semiconduttori in gran parte dedicata solo alle C.P.U senza controllori I/O, networking, ecc. ecc.) è "innovativo", "ad elevate prestazioni", "parco nei consumi di potenza" ecc. ecc.
Grazie.

Marco71.

bho vediamo su quanti supercomputer li metteranno la sua efficacia commerciale lo si vedra nella prossima classifica dei supercomputer.
anche se dal articolo sembrerebbe solo un test.

non penso che questo processore cambiera qualcosa per i comuni mortali.

E' davvero affascinante vedere 16 cpu logiche! Ma che SO è quello? Win Server 2003? Non pensavo sapesse gestire tutte queste cpu.

ne gestisce fino a 128 di processori 128

mode flame on

aspetta che qualcuno se ne uscirà con l'idea di metterli sui futuri mactel


mode flame off

ne gestisce fino a 128 di processori 128

voglio conoscere chi e' l'imbecille che mette windows su una macchina a 128 processori...

:ciapet: :ciapet: :ciapet:

...quindi se ho capito bene tutto il lavoro che sta alla base di Itanium con il paradigma V.L.I.W E.P.I.C, progetto partito in epoca di Pentium PRO sarebbe solo un "esercizio di stile" mentre tutto ciò che viene concepito e prodotto ad esempio da A.M.D (che ha la sua produzione di semiconduttori in gran parte dedicata solo alle C.P.U senza controllori I/O, networking, ecc. ecc.) è "innovativo", "ad elevate prestazioni", "parco nei consumi di potenza" ecc. ecc.
Grazie.

Marco71.

:cool:

ehrnm.. non mi sono forse spiegato bene, intendevo che il progetto e' buono, e' potenzialmente piu' performante del suo "quasi" diretto concorrente di casa AMD. Il parallelismo espliticito al livello di codice poi permette una scalabilita' quasi lineare in base al numero di processori/cores installati in quel sistema.. :eek:

ho usato le espressioni "esercizio di stile" e "vittoria di Pirro" perche' ora come ora, visto il mercato, itanium ha poca speranza di sfondare come piattaforma server mainstream/entry level o addirittura workstation (perdonatemi tutti gli inglesismi :) )

Spero di aver chiarito un po' il mio punto di vista :rolleyes:

Ciao

...
incredibile...
:eek:
:sbav:

Gli ITANIUM hanno sempre avuto maggiore velocità degli Opteron (ed anche degli Xeon), pur avendo la metà del clock. Questo per l'estremo parallelismo. Esistono server della Sun, mi pare, che montano fino a 128 itanium, ovviamente multi scheda. Sistemi a 16 processori logici c'erano già: quel sistema a 8 opteron dualcore con 128GB di RAM e solo 37GB di HD...

...Scusate... i 16 processori della workstation opteron sono fisici, non logici, invece qui sono 8 cpu fisiche e 16 logiche...

Prestazioni:

:sbav: :ave: :sbavvv:

Prezzo:

:eek: :cry: :sob: :doh: :eekk:


tre faccine a cinque, vince il prezzo!!! (non c'è nemmeno bisogno di cercare quello con 4 cpu dual core, anche quello "liscio" rientra nella mia classificazione).

l'itanium è uno dei più potenti proci esistenti per mainframe...
Per Workstation forse , i mainframe hanno tutt' altro hardware .
Gli ITANIUM hanno sempre avuto maggiore velocità degli Opteron (ed anche degli Xeon), pur avendo la metà del clock. Questo per l'estremo parallelismo.
Ti sei dimenticato un "in virgola mobile" , per le istruzioni "normali" gli Itanium non hanno mai fornito prestazioni velocistiche stupefacenti , gli ottimi risultati in virgola mobile sono dovuti all' estrema potenza della unità matematica , gli scarsi risultati negli interi sono dovuti all' architettura EPIC che ancora non riesce a esprimere la sua potenza , soffre troppo i programmi con poco parallellismo e i salti condizionati , dopo dieci anni di sviluppo ( anzi venti se teniamo conto dei primi esperimenti di Intel ) ancora i compilatori non riescono a ottimizzare il codice , a questo punto c' é il dubbio che non ci riusciranno mai .
Le scarse performance sono la causa prima dello scarso successo degli Itanium , specialmente se si tengono conto i prezzi e i consumi che hanno .

sono anni che lo scrivo sul forum ma nessuno mi ascoltava...
ad ogni modo i prism SGI possono gestire 512 core fisici per OS....
nulla di paragonabile attualmente in commercio.

Hai ragione, scusa, ricordavo male. Nello spec int 2000 è surclassato dagli opteron, ma surclassa gli opteron nello spec fp 2000... Ho cercato anche gli specweb... 4 opteron 852 battono 4 itanium 2 1.6ghz 9mb (!!!), anche se di poco (ma vorrei vedere le differenze di prezzo!)

sono anni che lo scrivo sul forum ma nessuno mi ascoltava...
ad ogni modo i prism SGI possono gestire 512 core fisici per OS....
nulla di paragonabile attualmente in commercio.

SGI: la classe non è acqua :ave:




ricordo ancora quando ho lavorato sulle WS Indy ed un server Challenge.. nel 1995 :) mai vista tanta fluidita' nel gestire le applicazioni..

Da sempre intel considera il segmento Itanium come "palestra" per le innovazioni tecnologiche, mettendo in secondo piano i profitti derivati.

Sarà anche palestra ma forse sarebbe ora che mettessero le conoscenze acquisite con questi processori anche a disposizione del segmento consumer! invece che proseguire a colpi di Prescott! :mad:

Personalmente la cosa non mi stupisce, l'ISA EPIC e l'architettura della famiglia Itanium hanno un potenziale notevole, a dispetto del loro successo commerciale. Complimenti ad Intel ache se questa pare una vittoria di Pirro..

Sbaglio o e' rimasta solo HP come partner di intel per gli itanium?

Ciao ;)


mi sa che sbagli... mi pare che hp abbia ufficialmente annunciato poco tempo fa di voler abbandonare il progetto dell'archyitettura epic

Sarà anche palestra ma forse sarebbe ora che mettessero le conoscenze acquisite con questi processori anche a disposizione del segmento consumer! invece che proseguire a colpi di Prescott! :mad:
Guarda che i difetti del Prescott l' Itanium li ha moltiplicati per dieci , il consumo di corrente é spaventoso e ottimizzare il codice é un incubo , da questo punto di vista i Prescott hanno copiato anche troppo !

Guarda che i difetti del Prescott l' Itanium li ha moltiplicati per dieci , il consumo di corrente é spaventoso e ottimizzare il codice é un incubo , da questo punto di vista i Prescott hanno copiato anche troppo !

asd, come non detto. :p

paragonare il prescott all'itanium e' indecoroso, visto che le due architetture sono distanti anni luce le une dalle altre.

"Ettore, leggi qua, Intel ha prodotto un sistema capace di 45 Giga Flops..."

"Oh, impressionante! Ma che bisogno c'è di sbandierare in pubblico i propri FLOP quantificandoli addirittura in Giga?..."

"Questa si chiama onestà, Ettore, onestà!"

Personalmente la cosa non mi stupisce, l'ISA EPIC e l'architettura della famiglia Itanium hanno un potenziale notevole, a dispetto del loro successo commerciale. Complimenti ad Intel ache se questa pare una vittoria di Pirro..

Sbaglio o e' rimasta solo HP come partner di intel per gli itanium?

Ciao ;)


un paio di precisazioni:
1)l'opteron 852 citato in uno degli interventi fa parte della stessa categoria degli Itanium a livello di costi (andatevi a vedere un listino...ed un 875 costa anche di più dei modelli "entry level" Itanium)
2)Intel ha intenzione di arrivare per il 2007 alla perfette parità dei costi per Xeon e Itanium oltre che all'integrazione sulla stessa piattaforma (cioè potrai scegliere cosa installare: Itanium o Xeon)...ed a questo è collegato il progetto di integrare (sul modello A64) il controller della memoria nel core: sono notizie apparse anche qui sul forum qualche settimana fa

in altri termini Intel è fermamente intenzionata a proseguire sulla strada di Itanium e forse non è lontanissimo il giorno in cui si comincerà a parlare di derivati anche per il segmento consumer.

Circa i consumi un itanium con circa 1 miliardo di transistor (la versione con 24mb di cache) ha un TDP di 150W...non è male direi per una CPU che ha 10 volte i transistor di una CPU che siamo abituati a vedere.

Si, ma l'opteron 852 è più veloce (tranne nel floating point) di un Itanium con 9MB di cache e frequenza 1,6Ghz, che non credo sia il modello entry level...

Si, ma l'opteron 852 è più veloce (tranne nel floating point) di un Itanium con 9MB di cache e frequenza 1,6Ghz, che non credo sia il modello entry level...


onestamente al di là di quello che si legge nei forum da gente che tra l'altro non li avrà mai visti all'opera nessuno qui ha mai potuto confrontarle quindi credo che queste affermazioni lascino il tempo che trovano...nei test che si leggono l'opteron è più veloce con gli interi (ma già nel rapporto con gli Xeon questo non è vero e gli Xeon top di gamma non sono certo inferiori, anzi) ma decisamente più lento in FP (mentre nel rapporto con gli Xeon è il contrario)...i prezzi sono confrontabili quindi credo che la scelta dipenda dall'utilizzo e nessuna delle 3 soluzioni batte le altre sempre e comunque.

Non ci sono solo i costi dei processori.. ma anche quelli della piattaforma, nel caso di Itanium tutto "l'intorno" costa molto di più che non nel caso di Xeon e Opteron.
Senza contare che per calcoli Fp la spesa per Itanium può essere giustificata... ma per gestione database, siti web, ecc. ecc. non ne vale proprio la pena.

Non ci sono solo i costi dei processori.. ma anche quelli della piattaforma, nel caso di Itanium tutto "l'intorno" costa molto di più che non nel caso di Xeon e Opteron.
Senza contare che per calcoli Fp la spesa per Itanium può essere giustificata... ma per gestione database, siti web, ecc. ecc. non ne vale proprio la pena.

e' vero, ma come diceva giustamente Spectrum7glr intel sta cercando di uniformare le piattaforme lasciando all'utente la possibilita' di montare CPU Xeon o Itanium. Questo tra l'altro si tradurrebbe in una riduzione dei costi di sviluppo delle piattaforme da parte dei partner intel (dovendo svilupparne una sola e non due).
Personalmente non vedo un futuro roseo per questa classe di processori (itanium) .. spero di essere smentito dai fatti..


bye

X Marco71:
Non mi pare che il Pentium Pro avesse qualcosa a che fare con IA64

Secondo me è geniale il sistema di predicazione dell'Itanium2, che lo rende molto efficiente in presenza di codice con molti salti condizionati.
Per i prezzi e i consumi, la gamma mi sembra abbastanza ampia. I Deerfield costano circa 500$ x 1000 unità e hanno un TDP di 62W.

l'unica cosa che hanno in comune il PPRO con l'itanium e' il salto generazionale che in epoche diverse i due processori hanno costituito, ciascuno nella sua.
per il resto sono due sistemi radicalmente diversi.
ITANIUM non predice una mazza, semplicemente perche' puoi decidere nel codice cosa caricare in cache e su quale core.
quindi predirre cosa? quello che e' gia' stato deciso dal codice.?

quindi predirre cosa? quello che e' gia' stato deciso dal codice.?

Io ho parlato di predicazione e non di predizione.
http://www.intel.com/cd/ids/developer/asmo-na/eng/76929.htm

un codice del tipo:
// Conditional statement in 'c' language
if(x)
y++;
else
y--;

nelle CPU IA-32 viene tradotto in:
; Conditional statement in IA-32 assembly language

; Note: ax is variable x and dx is varibale y.

cmp ax,0 ; if(x)

je ELSE ; branch to else case

inc dx ; y++

jmp DONE ; branch to done

ELSE: dec dx ; y--

DONE:

mentre nell'Itanium in:
; Conditional statement in IA-64 assembly language

; Note: r2 is variable x and r3 is varibale y.

cmp.ne p1,p2=r2,r0 // if(x)

(p1) add r3,1 // y++

(p2) sub r3,1 // y--

In soldoni, invece che cercare di prevedere l'esito di un salto condizionato come fanno gli x86, l'Itanium sfrutta le sue doti di calcolatore parallelo per calcolare contemporaneamente entrambi gli esiti del confronto e poi scarta successivamente il "branch sbagliato". Scusa se sono stato impreciso, ma sta per partire il GP e non mi voglio perdere la partenza... :)

In soldoni, invece che cercare di prevedere l'esito di un salto condizionato come fanno gli x86, l'Itanium sfrutta le sue doti di calcolatore parallelo per calcolare contemporaneamente entrambi gli esiti del confronto e poi scarta successivamente il "branch sbagliato". Scusa se sono stato impreciso, ma sta per partire il GP e non mi voglio perdere la partenza... :)

Ma con le CPU Prescott Dual core di Intel questa strategia non avrebbe senso vero? fammi capire.

Ma con le CPU Prescott Dual core di Intel questa strategia non avrebbe senso vero? fammi capire.

Certamente no.
La predicazione sugli Itanium avviene all'interno di ogni singolo core. E poi gli Itanium sono architetture in-order, i Prescott out-of-order. I Prescott effettuano predizione del branch in hardware, gli Itanium no. I Prescott sono orientati (soprattutto) al calcolo sequenziale, gli Itanium a quello parallelo....

finalmente uno che scrive il codice!!!!
BRAVO!!!

finalmente uno che scrive il codice!!!!
BRAVO!!!

A dire il vero quello snippet era della Intel .... :fiufiu:
:D

e' vero, ma come diceva giustamente Spectrum7glr intel sta cercando di uniformare le piattaforme lasciando all'utente la possibilita' di montare CPU Xeon o Itanium. Questo tra l'altro si tradurrebbe in una riduzione dei costi di sviluppo delle piattaforme da parte dei partner intel (dovendo svilupparne una sola e non due).
Personalmente non vedo un futuro roseo per questa classe di processori (itanium) .. spero di essere smentito dai fatti..
bye

Credo sia un pò difficile uniformare le due architetture dal punto di vista HW... forse a livello di sviluppo SW si avranno IDE unificate.

in altri termini Intel è fermamente intenzionata a proseguire sulla strada di Itanium e forse non è lontanissimo il giorno in cui si comincerà a parlare di derivati anche per il segmento consumer.
Non credo proprio: dovrebbe tagliare la cache L3, o comunque ridurla considerevolmente, e le prestazioni scenderebbero drasticamente.
Meglio un Duron a 1Ghz con 128KB di cache L2 che un Itanium a 1 Ghz con 256KB di cache L2, per il mercato desktop...

Ma con le CPU Prescott Dual core di Intel questa strategia non avrebbe senso vero? fammi capire.
Hanno già (tutti i processorie x86 da un po' di anni a questa parte, come pure tantissimi RISC) un'unità di esecuzione fuori ordine, che a giudicare dai risultati fa decisamente meglio il suo lavoro.

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?

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/techtrends/emea/ita/191240.htm

(chissà se Doom3 "scatta" :asd: )

(chissà se Doom3 "scatta" :asd: )

lol! :D

Grazie delle precisazioni!

Hanno già (tutti i processorie x86 da un po' di anni a questa parte, come pure tantissimi RISC) un'unità di esecuzione fuori ordine, che a giudicare dai risultati fa decisamente meglio il suo lavoro.

Grazie mille per l'info :)

Questo supercomputer della NASA ha 10,240 processori Itanium2:

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

(chissà se Doom3 "scatta" :asd: )

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

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?
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à.

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).

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

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! :)

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

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" (statica, però, e demandata al compilatore e non alla CPU) 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.

cioè stai dicendo che n vi sn condizioni in cui sia possibile una situazione di stallo negli Itanium?
Ovviamente sì, e dipendono da diversi fattori, fra quelli da elencati prima quando parlavo in generale di processori in-order, e a cui neppure Itanium può sottrarsi (anzi).

x Cecco BS: di niente. :)

Ovviamente sì, e dipendono da diversi fattori, fra quelli da elencati prima quando parlavo in generale di processori in-order, e a cui neppure Itanium può sottrarsi (anzi).

Nella ignore list deve aver messo anche la predicazione. Non parlarne e far finta che non esista sembra l'unico modo per sostenere questa tesi... :asd:

La predicazione è geniale... se non fosse che c'è spreco di risorse. Mi spiego meglio: ci sono unità che fanno dei calcoli che poi verranno buttati. Sarebbe stato carino avere qualche modalità del processore in cui farlo funzionare come il Niagara della SUN: 2 o più thread che si contendono le risorse. Non essendo OOO, capiterà spesso che delle unità sono libere e possono essere assegnate ad un altro thread. Considerando poi la quantità spropositata di cache che hanno... Anche per questo consumano tanta potenza: ci sono tanti calcolo fatti inutilmente. Se una pipeline stalla, non consuma potenza. Se una pipeline fa calcoli (inutili) si.

Lo spreco di risorse c'è ma è relativo: una pipeline che fa calcoli in più è sprecata tanto quanto una pipeline che non fa' calcoli. Sicuramente una che non fa' calcoli non consuma corrente, ma bisogna tener presente che nelle CPU OOO, l'unità di branch prediction consuma comunque un fottio di corrente ed è sempre attiva.
...E poi le CPU pensate per il calcolo parallelo con molte pipeline non hanno il problema di occupare una pipeline in più per quei pochi cicli che intercorrono tra quando si iniziano a riempire le pipeline stesse e quando il predicato viene processato effettivamente...
Con la tecnologia degli sleep transistors dinamici che verrà introdotta nel processo a 65nm, poi, ci sarà la possibilità di attivare o disattivare risorse inutilizzate (del core e della cache) con una notevole riduzione del leakage. Su una CPU OOO, il branch predictor deve restare comunque sempre attivo e non può essere mai disabilitato per poter ridurre il leakage.

stavo per fare la stessa obiezione di bjt2, ma fantoibed ha ribattuto dissipando tutti i miei dubbi! ;)

Ha ragione fantoibed... ma io non criticavo lo spreco di risorse, ma la mancanza di una modalità Niagara-Like. Mi spiego meglio: se voglio un mostro di calcolo parallelo, prendo un Itanium (2). Se voglio un sistema che possa gestire bene molti thread, devo per forza aumentare le CPU. Si poteva, senza complicare troppo la CPU, adottare un'altra modalità operativa come quella Niagara (visto che la logica OOO non c'è), avendo un ultra hyper threading (riflettendoci mi pare che gli itanium 2 ce l'abbiano, ma non ne sono sicuro...), magari a 4 o più thread, vista la cache ed il numero di unità di calcolo presenti in quella CPU...

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. ;)

Io non ho parlato di stallo per errate predizione, ho detto semplicemente stallo.


...O meglio, la "predizione" (statica, però, e demandata al compilatore e non alla CPU) 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.

La predicazione non risolve tutte le possibili situazioni in cui uno stallo può verificarsi, ad es. perchè il codice per quanto il compilatore possa ottimizzare il codice per l'architettura EPIC, non riuscirà mai a "parallalelizzarlo" completamente.

a quanto ne so la difficoltà maggiore da questo punto di vista sta nel progettare compilatori che riescano a rendere il codice il più possibile parallelizzabile esplicitamente, no?

a quanto ne so la difficoltà maggiore da questo punto di vista sta nel progettare compilatori che riescano a rendere il codice il più possibile parallelizzabile esplicitamente, no?

stanno nel fatto che un compilatore per quanto efficiente non può risolvere tutte le situazioni che si presentano.
Il codice è una sequenza di istruzioni e ci saranno casi in cui, compilatore + o - affinato, un'istruzione non potrà essere eseguita in parallelo perchè l'istruzione successiva ad es. è collegata alla precedente.
Esempio stupido:

nel mio programma mi trovo ad un certo punto a dover sommare la variabile1 alla variabile 2. Subito dopo il risultato dell'addizione dovrà essere sommato alla variabile 3.

Come faccio ad eseguire in parallelo le due istruzioni?
Non posso.

Non solo...accade n così di rado che siano i programmatori stessi a dover rivedere il codice di un programma ( ad es portandolo da una piattaforma x86 all'IA-64) perchè la macchina non può arrivare ad un certo risultato, richiesto per poter beneficiare il + possibile dell'architettura EPIC.

Queste operazioni in termini di tempo possono essere costose e tempo = denaro

La predicazione è geniale... se non fosse che c'è spreco di risorse.
Sarà geniale, ma alla fine si è rivelata poco adatta rispetto alla realtà, a come funziona il codice nelle applicazioni che usiamo tutti i giorni.

Predicazione e predizione alla fine sono due strumenti che nascono per risolvere lo stesso problema, anche se in maniera completamente diversa: quello di gestire le condizioni che portano o posso portare a un cambiamento nel flusso del codice.
Mi spiego meglio: ci sono unità che fanno dei calcoli che poi verranno buttati. Sarebbe stato carino avere qualche modalità del processore in cui farlo funzionare come il Niagara della SUN: 2 o più thread che si contendono le risorse. Non essendo OOO, capiterà spesso che delle unità sono libere e possono essere assegnate ad un altro thread.
Non penso che sia fattibile: proprio per la natura stessa della predicazione, quelle istruzioni DEVONO essere eseguite, e quindi impegneranno sempre e comunque quelle risorse. Quando il processore si vede costretto ad eseguire il rollback di un'istruzione la cui predicazione non è andata a buon fine, sarà comunque troppo tardi: il lavoro è già stato fatto, le risorse impegnate, usate e rilasciate.

Il discorso di Niagara è diverso, è simile a quanto avviene nel P4 con l'HT e nel Power5, ed è quel che Intel dovrebbe fare con le prossime versioni di Itanium, per utilizzare le risorse rimaste libere (perché non usate, o perché un thread è fermo a causa di uno stallo, e quindi è costretto a non usarle).
C'è da dire che, anche se sulla carta ha buone possibilità grazie alla presenza di numerose unità di esecuzione, il compito non è affatto semplice, a causa dei vincoli dell'architettura EPIC: le risorse devono essere impegnate in toto per portare a termine un intero bundle, e non qualcuna delle sue istruzioni.
Un processore con logica ooo è molto più facilitato in questo, perché può organizzare le istruzioni come vuole, e usare al meglio le risorse disponibili in quel preciso momento. "Posso eseguire 3 istruzioni liberamente, mi serve un load, una moltiplicazione intera e una somma FP, ma ho disponibile soltanto un'AGU e un sommatore FP: ne eseguo due, e per l'altra ci penso dopo".
Considerando poi la quantità spropositata di cache che hanno... Anche per questo consumano tanta potenza: ci sono tanti calcolo fatti inutilmente. Se una pipeline stalla, non consuma potenza. Se una pipeline fa calcoli (inutili) si.
Indubbiamente, e per fortuna la cache non consuma molta potenza (soltanto spazio, prezioso, su chip).

Ha ragione fantoibed... ma io non criticavo lo spreco di risorse, ma la mancanza di una modalità Niagara-Like. Mi spiego meglio: se voglio un mostro di calcolo parallelo, prendo un Itanium (2). Se voglio un sistema che possa gestire bene molti thread, devo per forza aumentare le CPU. Si poteva, senza complicare troppo la CPU, adottare un'altra modalità operativa come quella Niagara (visto che la logica OOO non c'è), avendo un ultra hyper threading (riflettendoci mi pare che gli itanium 2 ce l'abbiano, ma non ne sono sicuro...), magari a 4 o più thread, vista la cache ed il numero di unità di calcolo presenti in quella CPU...
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.

Io non ho parlato di stallo per errate predizione, ho detto semplicemente stallo.
Esatto: le cause sono molteplici.
La predicazione non risolve tutte le possibili situazioni in cui uno stallo può verificarsi, ad es. perchè il codice per quanto il compilatore possa ottimizzare il codice per l'architettura EPIC, non riuscirà mai a "parallalelizzarlo" completamente.
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" :D come questo:

for i := 1 to n do
[...]
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 :D 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... :p

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... ;)

Ad esempio, con un codice "poco diffuso" :D come questo:

for i := 1 to n do
[...]
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à.

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...