Nuovi processori Itanium 2

[Redazione di Hardware Upg]

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

Intel annuncia due nuove versioni di processori Itanium 2, con 3MB di cache L3

Click sul link per visualizzare la notizia.

[TheSlug]

No Comment...

[Apocalisse84]

prestazioni al top ma fa un po' impressione pensare a questi prezzi...

[DioBrando]

considerato poi che dall'altra parte gli Opteron sn parecchio in forma e agguerriti anche nei prezzi...
costano davvero una paccata, come la news degli Xeon qlc tempo fà...

mah

[lamp76]

Ricordo che parliamo di "MOSTRI" non di PC.

[Marco71]

C'è un errore nella news: si deve correggere il termine "Linkpach" con LINPACK (che ricordo è una suite di benchmarking scritta in Fortran).

Marco.

[DevilsAdvocate]

benche' si tratti sicuramente di processori +
performanti, visto che la cpu non e' l'unico componente di un pc, ai produttori di grafica 3D
(ai quali mi pare rivolta questa news)conviene ancora
farsi una renderfarm di pIV 2,8ghz, che costando il pc completo (di base) meno della meta',consentono di comprare 2 pc ogni itanium (se non di piu') e vanno + veloci...... Insomma il rendering distribuito diminuisce di molto il valore di questi giocattoloni, fra l'altro incompatibili con la maggior parte del software esistente....

[KVL]

Ma: c'è un ma... Non tutti (università comprese) hanno le capacità tecniche per il clustering. Esperienze personali mi dicono che il 90% preferisce un Dual-Xeon a un Dual-Opteron anche se i costo sono inferiori e le prestazioni uguali se non + alte... il tutt ovviamente in un unico case, quindi niente clustering!

[flisi71]

Non sono daccordo: realizzare un cluster HPC di tipo Beowulf o openMosix è attualmente alla portata di un qualunque studentello volenteroso.
Una macchina dual Xeon costa meno di un dual Opteron, a parità circa di prestazioni (ovvio che gli Opteron 240 costano poco, ma rendono anche poco rispetto ad un Opteron 246 o 248 o rispetto ad un Xeon da almeno 2,666-2,8 GHz) inoltre parecchi software di CAD/DCC sono certificati per certe workstation complete, in gran parte con dual Xeon.
Ecco perchè se ne vendono di più.

Infine: tutti questi discorsi che facciamo poi non c'entrano assolutamente niente con i processori Itanium qui riportati.

Ciao

Federico

[Lucrezio]

qualcuno mi saprebbe dire qual è la potenza in Gflop di questi nuovi processori?
Mi sa che con buona pace di opteron ( lo dico da amd-filo ) intel è un gradino sopra come prestazioni ( e dodici come prezzi... )
peccato solo che gli itanium nn siano compatibili con x86...
ciao!
"expedit esse deos, ut expedit esse putemus"

[DioBrando]

Ricordo che parliamo di "MOSTRI" non di PC.

perchè scusa gli Opteron li trovi negli ovetti kinder?...
sn pur sempre macchinari dedicati a soluzioni la maggior parte delle volte embedded, housing hosting o cmq aziendali...dual, quad poco importa il target di riferimento è quello.

Nessuno credo abbia nemmeno confuso i normali desktop con macchine Itanium-Xeon-Opteron based...

moh

[TheDarkAngel]

eh an roba gli xeon più performanti...
in quale film? lol....
già in configurazione quad c'e' una spanna tra xeon e opteron...

[Lo ZiO NightFall]

"peccato solo che gli itanium nn siano compatibili con x86..." by Lucrezio

Non sono d'accordo. Questi processori sono usati su server dove i 64bit sono imprescindibili soprattutto per la loro capacità di indirizzare più di 4gb di ram. A quei livelli non ha senso usare codice x86 e nemmeno esiste. Per rispondere anche a coloro che ritengono il prezzo di itanium elevato, aggiungo che in questo particolare segmento di mercato esistono già da tempo altri processori (le cpu Alpha), ma costano (non le singole cpu, ma lo soluzione server in toto, ed è questa la discriminante, non la sola cpu) fino a quattro volte tanto le rispettive controparti itanium

[Lucrezio]

il processore itanium è compatibile solo con la "sua" architettura. ovvero quella a 64bit di intel, a differenza di opteron che, pur essendo una cpu che lavora in maniera nativa con codice a 64 bit, supporta, sempre in maniera nativa, il codice 32 bit. Ora come ora è un peccato, nel campo di molte applicazioni, ( ovviamente parlo di fascia professionale, come la grafica!!! niente itanium per giocare ) che itanium non supporti codice x86 ( sia esso a 32 bit o a 64 bit ) in quanto richiede applicazioni ottimizzate. Ovvero una grossa spesa aggiuntiva per uno studio - azienda che voglia migrare verso il potente - ed effettivamente superiore - processore itanium2. forse però nn mi ero spiegato molto bene...
ciao a tutti!
"Expedit esse deos, ut expedit esse putemus"

[cdimauro]

Francamente sono perplesso davanti al prospettato aumento del 25% di prestazioni a parità di clock, per il solo aumento di cache L3...

x Lucrezio: Itanium non è superiore in tutto, anzi. Sulle applicazioni che usano pesantemente l'FPU, sono d'accordo. Per il resto, è meglio lasciar perdere...

[xeal]

Originariamente inviato da cdimauro
Francamente sono perplesso davanti al prospettato aumento del 25% di prestazioni a parità di clock, per il solo aumento di cache L3...

Boh... Magari avendo più dati a disposizione riescono a sfruttare meglio i 128 (credo) registri interni e ad ottimizzarne la rotazione (che se non ricordo male richiede dei cicli di clock, anche se rispetto alle prime versioni dovrebbe avvenire in background), oltre alla gestione della branch prediction (che però dovrebbe essere affidata in massima parte all'ottimizzazione del codice).

Magari l'architettura degli itanium risulta tanto più efficiente quanto più si riducono i tempi di riempimento/aggiornamento dei registri, specie se effettuano calcoli pesanti su una grossa mole di dati (visto che prima o poi la cpu dovrà "perdere" - magari sarebbe meglio dire "dedicare" - del tempo per gestire i registri, se alcuni - molti - contengono dati non utili e occorre aggiornarli accedendo alla memoria di sistema può darsi che l'efficienza di calcolo ne risenta un po' - molto - in termini percentuali; dipende da quanto effettivamente il meccanismo di gestione dei registri incide sulle prestazioni di questa cpu e da quanto, per la sua architettura interna, essa necessiti di avere a disposizione molti dati reperibili in tempi brevi per sfruttare pienamente la propria potenza di calcolo). Se fosse così, ciò vorrebbe dire che grazie alla maggior quantità di cache la potenza di calcolo dell'itanium (rimasta invariata) viene sfruttata meglio.

Magari sono completamente fuori strada e i dati sono leggermente gonfiati per motivi pubblicitari, o magari l'aumento di prestazioni è reale, ma dovuto ad altri motivi (quali?). Certo che 1,5 MB di L3, in aggiunta alla cache L2 (che non ricordo a quanto ammonta, ma sicuramente non è poca) non erano pochi, e il 25% in più è un aumento considerevole...

Ciao a tutti.

[cdimauro]

Originariamente inviato da xeal
Boh... Magari avendo più dati a disposizione riescono a sfruttare meglio i 128 (credo) registri interni e ad ottimizzarne la rotazione (che se non ricordo male richiede dei cicli di clock, anche se rispetto alle prime versioni dovrebbe avvenire in background),

Questo non dipende alla maggior cache L3: se si usano i registri, il codice è già molto veloce, e la rotazione non ha nulla a che vedere con ciò.

oltre alla gestione della branch prediction (che però dovrebbe essere affidata in massima parte all'ottimizzazione del codice).

Idem come sopra: questa caratteristica non dipende dalla maggior cache L3.

Magari l'architettura degli itanium risulta tanto più efficiente quanto più si riducono i tempi di riempimento/aggiornamento dei registri,

Esattamente. Per questo motivo una maggior cache L3 potrebbe dare risultati migliori, ma dipende anche dal tipo di accesso ai dati.

specie se effettuano calcoli pesanti su una grossa mole di dati (visto che prima o poi la cpu dovrà "perdere" - magari sarebbe meglio dire "dedicare" - del tempo per gestire i registri, se alcuni - molti - contengono dati non utili e occorre aggiornarli accedendo alla memoria di sistema può darsi che l'efficienza di calcolo ne risenta un po' - molto - in termini percentuali;

Dipende tutto dal tipo di accesso. Per applicazioni di calcolo "massiccio", generalmente l'accesso è sequenziale, o comunque facilmente predittibile dall'unità di data prefetch, per cui il maggior quantitivo di cache L3 dovrebbe incidere poco. Discorso diverso per le applicazioni che eseguono accessi meno "uniformi", per cui costringono a caricare/scaricare continuamente dati dalle cache: in tal caso i vantaggi sono consistenti.

dipende da quanto effettivamente il meccanismo di gestione dei registri incide sulle prestazioni di questa cpu e da quanto, per la sua architettura interna, essa necessiti di avere a disposizione molti dati reperibili in tempi brevi per sfruttare pienamente la propria potenza di calcolo). Se fosse così, ciò vorrebbe dire che grazie alla maggior quantità di cache la potenza di calcolo dell'itanium (rimasta invariata) viene sfruttata meglio.

Vedi sopra: l'uso dei registri interni è comunque necessario per ottenere delle ottime prestazioni, a prescindere dal loro meccanismo di gestione (mi sembra che siano 3 i cicli di latenza dovuti all'uso di un registro). Il problema della reperibilità dei dati dipende esclusivamente dalla natura del codice eseguito.

Magari sono completamente fuori strada e i dati sono leggermente gonfiati per motivi pubblicitari, o magari l'aumento di prestazioni è reale, ma dovuto ad altri motivi (quali?). Certo che 1,5 MB di L3, in aggiunta alla cache L2 (che non ricordo a quanto ammonta, ma sicuramente non è poca)

E' poca invece: 256KB.

non erano pochi, e il 25% in più è un aumento considerevole...

Ciao a tutti.

Appunto. Ma non si può applicare a tutto: bisogna vedere dove effettivamente è stato registrato un aumento così consistente...

Ciao

[xeal]

Ricordo di aver letto ai tempi dell'introduzione di questa cpu (purtroppo non riesco più a trovare la recensione ) che dovrebbe consentire una qualche forma di "parallelizzazione" di parte dei calcoli, grazie all'ottimizzazione del codice e dell'architettura interna (in realtà dovrebbe trattarsi di una gestione ottimale - presunta o reale - della pipe e il codice dovrebbe entrare in gioco per la gestione della branch prediction e il maggior "controllo" sulle operazioni della cpu consentito dai flag interni, che non ricordo cosa hanno di "diverso" da quelli convenzionali - in questo momento sono troppo pigro per fare una bella ricerca ... quindi preferisco chiedere ).

Magari per sfruttare al meglio la propria architettura, l'itanium ha particolarmente bisogno di avere il maggior numero possibile di registri riempiti con dati utili: se l'architettura interna è così efficiente da permettere ad esempio di utilizzare le alu contemporaneamente quando è richiesto il loro utilizzo (oltretutto se non ricordo male una di esse viene utilizzata anche per l'indirizzamento), se i dati su cui si potrebbe operare parallelamente non sono subito disponibili nei registri interni si perde parte della pontenzialità di calcolo della cpu, annullando il vantaggio (forse più una necessità) di avere molti registri interni; dato che la gestione dei registri dell'itanium poi richiede un certo tempo, se il loro aggiornamento avviene di frequente lo spreco di tempo può essere considerevole a prescindere dalla quantità di L3 (non vorrei dire una cavolata, ma credo che la rotazione dei registri implichi che si impieghi del tempo anche per decidere in quale registro caricare i dati); se infine a questo "spreco" di tempo si aggiunge anche la necessità di accedere frequentemente alla ram si chiude il cerchio e si spiega (forse) un po' più in dettaglio il boost fornito dalla maggiore cache (ok, dipende sempre dal tipo di accesso). Ovviamente le mie sono supposizioni: non conosco in dettaglio l'architettura EPIC e potrei essere fuori strada.

Quanto alla L2, credevo fosse di più, 256K sono un po' pochi. Magari aumentando questa (e appoggiandosi meno alla L3) otterrebbero risultati migliori. Probabilmente si tratta di un limite progettuale.

Ciao.

[cdimauro]

Originariamente inviato da xeal
Ricordo di aver letto ai tempi dell'introduzione di questa cpu (purtroppo non riesco più a trovare la recensione ) che dovrebbe consentire una qualche forma di "parallelizzazione" di parte dei calcoli, grazie all'ottimizzazione del codice e dell'architettura interna (in realtà dovrebbe trattarsi di una gestione ottimale - presunta o reale - della pipe e il codice dovrebbe entrare in gioco per la gestione della branch prediction e il maggior "controllo" sulle operazioni della cpu consentito dai flag interni, che non ricordo cosa hanno di "diverso" da quelli convenzionali - in questo momento sono troppo pigro per fare una bella ricerca ... quindi preferisco chiedere ).

La "parallelizzazione" a cui ti riferisci è probabilmente quella offerta dai "bundle" in cui vengono "impaccate" le istruzioni ed eseguite "in parallelo" (tutte e tre assieme). Il lavoro di "scelta" viene effettuato però dal compilatore, mentre nei processori x86-64 ciò avviene a run-time, cosa che per EPIC/Itanium non è assolutamente possibile. Entrambe le CPU sono in grado di eseguire istruzioni "in parallelo", ma hanno scelto strade completamente diverse per poterlo fare.

Per quanto riguarda i flag, si tratta di alcune "variabili" booleane che conservano il risultato di alcune precedenti operazioni. Nelle istruzioni da eseguire vengono indicate quali di queste "variabili" sono ad esse associate, e al termine dell'esecuzione verranno controllate per decidere se quanto eseguito è valido oppure no. In pratica Itanium esegue le istruzioni, e decide alla fine se può tenere il risultato oppure no. E' un meccanismo utile per implementare i blocchi if-else, perché permette di non svuotare mai la pipeline.

Però sia questo che quello precedente è un tipo di approccio "statico", in quanto è il compilatore a decidere tutto. Al contrario, nei processori "tradizionali" si decide tutto a run-time, e IMHO è molto più utile, in quanto un'istruzione non dipende soltanto dal risultato precedente, ma anche dalle risorse disponibili in quel preciso momento. L'esecuzione out-of-order permette, appunto, di effettuare una scelta migliore e di ottimizzare (per quanto possibile) l'uso delle risorse di sistema.

Magari per sfruttare al meglio la propria architettura, l'itanium ha particolarmente bisogno di avere il maggior numero possibile di registri riempiti con dati utili: se l'architettura interna è così efficiente da permettere ad esempio di utilizzare le alu contemporaneamente quando è richiesto il loro utilizzo (oltretutto se non ricordo male una di esse viene utilizzata anche per l'indirizzamento), se i dati su cui si potrebbe operare parallelamente non sono subito disponibili nei registri interni si perde parte della pontenzialità di calcolo della cpu, annullando il vantaggio (forse più una necessità) di avere molti registri interni;

Infatti. D'altra parte se hanno previsto così tanti registri, è proprio per cercare di minimizzare gli accessi alla cache o alla ram.

dato che la gestione dei registri dell'itanium poi richiede un certo tempo, se il loro aggiornamento avviene di frequente lo spreco di tempo può essere considerevole a prescindere dalla quantità di L3 (non vorrei dire una cavolata, ma credo che la rotazione dei registri implichi che si impieghi del tempo anche per decidere in quale registro caricare i dati);

Non mi preoccuperei più di tanto: anche nei processori x86 l'accesso ai registri non avviene in un ciclo di clock.

se infine a questo "spreco" di tempo si aggiunge anche la necessità di accedere frequentemente alla ram si chiude il cerchio e si spiega (forse) un po' più in dettaglio il boost fornito dalla maggiore cache (ok, dipende sempre dal tipo di accesso). Ovviamente le mie sono supposizioni: non conosco in dettaglio l'architettura EPIC e potrei essere fuori strada.

C'è un interessante articolo su Lithium che potrebbe chiarirti meglio le idee.

Quanto alla L2, credevo fosse di più, 256K sono un po' pochi. Magari aumentando questa (e appoggiandosi meno alla L3) otterrebbero risultati migliori. Probabilmente si tratta di un limite progettuale.

Ciao.

La cache L2 è molto veloce, per cui non so se sarebbe comunque possibile aumentarla pur mantenendo questa caratteristica.

Ciao