Link alla notizia: http://news.hwupgrade.it/13462.html

Secondo alcune informazioni pare che Intel presenterà all'inizio della prossima settimana nuovi modelli della famiglia Itanium, compresi processori basati su core Fanwood

Click sul link per visualizzare la notizia.

Sarebbe interessante come si comportano Opteron e Itanium2 con software a 64 bit... certo che se anche Opteron fosse un po' più lento costerebbe moooolto meno di un Itanium2. Ho visto supercomputer indifferentemente costruiti con cluster Xeon, Opteron e Itanium, per cui la potenza di calcolo c'è senz'altro.
PS. ventola di legno? :-D

nn penso siano paragonabili opteron e itanium 2 IMHO :)
neanche lontanamente...

Ma dove li trovano 'sti nomi??????

Cmq opteron e xeon nn sono paragonabili con l'Itanium.

Ciao.
Zac89

in cosa e perché non sono paragonabili opteron e xeon all'Itanium? potresti specificare, perfavore?

hanno architetture differenti, non supportano lo stesso set di istruzioni e in definitiva sono pensati per applicazioni differenti.
Lo Xeon scala male già con 4 CPU, Opteron arriva a 4 CPU (si lo so, ci sono progetti per andare oltre MA nulla di acquistabile), mentre al contrario per Itanium è difficile trovare una piattaforma solo dual.

Ciao

Federico

Federico

Gli Itanium hanno architettura EPIC che è stata pensata specificatamente per calcolo ed elaborazioni parallele.
Ogni itanium è in grado di eseguire + thread contemporaneamente .... mentre Opteron e Xeon non eseguono realmente i thread in parallelo... è una cosa simulata.

Poi gli Itanium hanno un'architettura pensata per MACINARE enormi quantità di dati ed è poco efficiente con le piccole elaborazioni ad esempio dei PC di casa.

Ultima cosa, ma non meno importante, è stato progettato fin dall'inizio per farci dei cluster e non per usarlo singolarmente, tant'è che il supercomputer + potente è un cluster di 10000 Intenium 2 e se andate a guardare la grassifica dei 500 piu' potenti sistemi della terra il Processore Itanium credo sia il piu' ricorrente.

ok... al di là di questo non capisco perché non si possa fare un paragone. Ci sono sicuramente segmenti del mercato in cui queste cpu sono tutte presenti e allora, per chi è interessato, può essere utile fare un paragone... no?!

Originariamente inviato da lamp76
Gli Itanium hanno architettura EPIC che è stata pensata specificatamente per calcolo ed elaborazioni parallele.
Ogni itanium è in grado di eseguire + thread contemporaneamente .... mentre Opteron e Xeon non eseguono realmente i thread in parallelo... è una cosa simulata.

[CUT]


Simulata? Intedi forse l'HT delle CPU intel (che le CPU AMD non hanno=, perchè se ho più cpu si possono parallelizzare le esecuzioni ;)

Originariamente inviato da Vik Viper
ok... al di là di questo non capisco perché non si possa fare un paragone. Ci sono sicuramente segmenti del mercato in cui queste cpu sono tutte presenti e allora, per chi è interessato, può essere utile fare un paragone... no?!

beh basta vedere che una la cache è di svariati MB mentre nelle altre è una frazione

sarebbe interessante magari paragonare itanium con Power5 di IBM :)

Che io sappia ogni Itanium può eseguire un solo thread in un dato istante... Il parallelismo di Itanium non è alivello di thread, ma si istruzioni...

Più che di parallelismo direi che grazie all'architettura che ha riesce ad evitare molti salti o predizioni sbagliate che comporterebbero uno svuotamento della pipeline, oltre a poter rinominare i registri per permettere l'eseguzione di cosice che altrimenti sarebbe bloccata perchè altre istruzzioni bloccano i registri necessari.

Questa news è datata 26-10-04

http://www.intel.com/pressroom/archive/releases/20041026comp_a.htm

Dov'è la classifica aggiornata dei PC più potenti della terra ??

Originariamente inviato da Duncan
Più che di parallelismo direi che grazie all'architettura che ha riesce ad evitare molti salti o predizioni sbagliate che comporterebbero uno svuotamento della pipeline, oltre a poter rinominare i registri per permettere l'eseguzione di cosice che altrimenti sarebbe bloccata perchè altre istruzzioni bloccano i registri necessari.
si chiama proprio Istruction Level Parallelilsm... In pratica parte del codice operativo specifica quali istruzioni possono essere eseguite in parallelo...

Giusto, non mi ricordavo il termine tecnico ;)

In pratica è una esasperazione del coccetto del'esecuzione out of order

L'esecuzione out of order se la gestisce la CPU...qui si tratta proprio di specificare il parallelismo nel codice operativo... In pratica è il compilatore a dotare l'applicazione del parallelismo... Ovviamente i compilatori sono stracomplicati...

Originariamente inviato da cionci
L'esecuzione out of order se la gestisce la CPU...qui si tratta proprio di specificare il parallelismo nel codice operativo... In pratica è il compilatore a dotare l'applicazione del parallelismo... Ovviamente i compilatori sono stracomplicati...

Infatti con EPIC gran parte della complessita che era inserita nel core e stata spostata nei compilatori ad esempio la brach prediction (si scrive così? :D )

In pratica gran parte del lavoro di ottimizzazione viene fatto dal compilatore, al contrario di come viene fatto su sistemi x86, principio semplice ma efficente

Branch ;)
Originariamente inviato da Duncan
In pratica gran parte del lavoro di ottimizzazione viene fatto dal compilatore, al contrario di come viene fatto su sistemi x86, principio semplice ma efficente
Fino ad un certo punto... Infatti l'architettura è talmente complessa che credo ci sia ancora spazio epr l'ottimizzazione...

Guarda che il register renaming esiste da molto ma molto tempo, a occhio direi dal ppro!

Beh, se proprio voleste fare una comparazione tra processori per sistemi "hi-end" forse dovreste anche includere Niagara di Sun.. :)

Ciao

Originariamente inviato da Superboy
Guarda che il register renaming esiste da molto ma molto tempo, a occhio direi dal ppro!

Deve essere l'arteria che avanza, ultimamente perdo colpi :D

Originariamente inviato da cionci
Branch ;)

Fino ad un certo punto... Infatti l'architettura è talmente complessa che credo ci sia ancora spazio epr l'ottimizzazione...

Scusa non mi è chiaro di cosa... del compilatore o dell'hardware? :O

ma volete paragonare la scorreggium2 con un bel silicon graphics? naaaaaaa non c'e' paragone

Originariamente inviato da Duncan
Scusa non mi è chiaro di cosa... del compilatore o dell'hardware? :O
Dell'hardware...

Originariamente inviato da ilmanu
ma volete paragonare la scorreggium2 con un bel silicon graphics? naaaaaaa non c'e' paragone
Guarda che SGI sviluppa anche sistemi con Itanium 2...

Originariamente inviato da cionci
Dell'hardware...

Non lo so... gran poarte del lavoro fatto da Intel con EPIC è stato propio quello di semplificare il design dei core cercando di portare la parte di ottimizzazione dell'esecuzione del codice sul compilatore, infatti se non mi sbaglio tra itanium e itanim 2 non ci sono grosse differenze, ma dovrei andare a rivedere, stasera se ho tempo do un'occhiata

A mio modesto parere è più facile che un miglioramento delle performance venga da ulteriori ottimizzazioni dei compilatori

Originariamente inviato da cionci
Guarda che SGI sviluppa anche sistemi con Itanium 2...

Infatti il sistema installato alla NASA è con Itanium 2 mi pare... (e Linux :D )

Originariamente inviato da Duncan
A mio modesto parere è più facile che un miglioramento delle performance venga da ulteriori ottimizzazioni dei compilatori
Forse ci siamo spiegati male... Non intendevo "ottimizzazione dell'hardware"...intendvo "ottimizzazione dei compilatori"... Credevo che la tua domanda fosse riferita a "l'architettura è talmente complessa"...e credevo che mi chiedessi se era l'architettura hardware o l'architettura dei compilatori ad essere complessa...

Certo...la penso proprio come te...anche se forse Intel ha semplificato troppo, non dotando Itanium di una vera e propria ALU...infatti anche i calcoli sugli interi vengono svolti dalla FPU... L'ALU viene utilizzata solamente per i calcoli sugli indirizzi...

per giudicare dovremmo vedere lo sviluppo che avrà l'architettura nei prossimi anni, in particolare se riuscirà ad essere impiegato anche in altri ambiti

Beh, non è che sia nuovissima come architettura ci lavorano da 10 anni, ed è già commercializzata da 3 circa. Sappiamo che Intel sviluppa degli eccellenti compilatori, ma per Itanium la situazione non è migliorata molto.
IMHO il fatto di spostare la complessità dal chip al compilatore ha portato più problemi per quanto riguarda le prestazioni.
D'altra parte, ormai "salvare spazio" in termini di transistor per la logica out-of-order non ha più molto senso, visto che i processori ormai ne contano 100 e passa milioni.

SI ma lo spazio salvato lo posso usare per inserire più registri, flag e cache, potrebbe essere vataggioso,o almeno è quello che deve dimostrare EPIC

Originariamente inviato da Duncan
SI ma lo spazio salvato lo posso usare per inserire più registri, flag e cache, potrebbe essere vataggioso,o almeno è quello che deve dimostrare EPIC

Non sempre aumentare il numero di registri comporta dei vantaggi: al di là delle teorie (dimostrate) sul basso numero di applicazioni che necessitano realmente di più di 16 registri (su questo Cesare dovrebbe poterti dare qualche indicazione in più), un più elevato numero di registri può comportare un sensibile aumento delle latenze, in particolare per il renaming e, nel caso di Itanium, per la rotazione. Ricordo che all'uscita di Itaninum (versione 1) si parlava di una certa incidenza di queste latenze, causa di una diminuizione del IPC se non drammatica, comunque non trascurabile, problema che avrebbe dovuto essere risolto nei core successivi (non so poi cos'abbiano fatto) effettuando queste operazioni durante gli idle (sempre che non siano necessarie prima). Quanto alla cache, fin dall'inizio questo processore è stato dotato di una quantità consistente: può darsi che, più che un punto di forza, sia una necessità (le istruzioni sono a lunghezza fissa, e questo incide sulla quantità necessaria), inoltre all'aumentare della cache aumentano anche le latenze per la ricerca di dati e istruzioni: non si può esagerare (con le versioni multicore magari questa scelta sarà meglio "giustificabile"). Poi, mi sa tanto che tra registri vari, "flag" predicativi e cache il numero di transistor della logica out of order è di gran lunga superato (e forse reintrodurlo varierebbe di poco il numero dei transistor): più che altro è una diversa scelta di "filosofia", e qui bisognerebbe stabilire quanto la maggior libertà nell'ottimizzazione del calcolo parallelo lasciata al compilatore (che comunque fa previsioni "statiche", non conoscendo lo stato reale delle risorse a runtime) possa fornire risultati superiori a quelli dell'out-of-order (per sistemare le cose a runtime) effettuata su un codice già parallelizzato ("staticamente") dai compilatori (con qualche limitazione in più rispetto a EPIC; su questo chiamo in causa ancora Cesare e chiunque abbia conoscenze approfondite sulla realizzazione di compilatori nativi, non sono la persona più indicata per addentrarmi in questi dettagli :D)

Ciao a tutti.

Originariamente inviato da Duncan
SI ma lo spazio salvato lo posso usare per inserire più registri, flag e cache, potrebbe essere vataggioso,o almeno è quello che deve dimostrare EPIC
T'ha già risposto abbondantemente xeal, vedo. Aggiungo che Itanium ha già 128 registri interi e altrettanti per l'FPU, oltre a 64 "registri" di predicazione: direi che sono abbastanza, anche considerando il fatto che degli studi hanno evidenziato che la STRAGRANDE maggioranza delle applicazioni utilizza al più 16 registri (per la maggioranza ne bastano 8), e una piccola percentuale 32, mentre oltre i 32 sono rarissimi i campi d'utilizzo.

Quanto all'approccio out-of-order VS compilatore, posso soltanto farti un esempio: cosa succede se un'istruzione inserita in un bundle si trova a corto di risorse (es.: aspetta un dato dalla cache)? Il bundle non può essere portato a termine. Mentre in un'architettura con OOO execution questa viene messa "in letargo", per poi ripresa non appena sarà disponibile il dato.
Questo nessun compilatore al mondo lo potrà mai prevedere, ma un'unità OOO sì, perchè conosce AL MOMENTO ESATTO DELL'ESECUZIONE quali sono le risorse disponibile, e può decidere il modo migliore per portare avanti l'esecuzione delle istruzioni.

Grazie per i chiarimenti :)