Newsgroup: it.comp.hardware.cpu
Titolo: Opteron e Itanium 2

Ciao,
qualcuno che ha potuto provare
i due processori in oggetto potrebbe
dirmi quali sono le loro differenze
prestazionali?

"_FranK" <as...@zxcv.qw> ha scritto nel messaggio
news:ZoXNb.100791$VW.40...@news3.tin.it...

Dubito che qualcuno qui del NG abbia già in casa (poco probabile) o al
lavoro un sistema con Itanium2...;)))
Comunque i due prodotti che appartengono a due distinte fascie
di mercato.
Ciao

 di mercato.
Ma, diciamolo una volta per tutte: uno che acquista un Itanium non potrebbe
equivalentemente, a livello di prestazioni, scegliere un Opteron al suo
posto? O per le applicazioni cui sono destinati i processori in questione
servono per forza 6 MB di cache L3?
MaxArt

servono per forza 6 MB di cache L3?
non fare paragoni "questo ha 1mb, quello ha 6mb, quindi questo e'
meglio di quello", la differente dimensione delle cache e' legata a
come l'intera architettura si sviluppa, itanium richiede una cache
enormemente piu' vasta data la sua isa (vliw con un sistema di
aggregazione delle istruzioni piuttosto avanzato, piu' grande e' la
cache piu' efficiente diventa l'esecuzione) e dato il bus verso il
resto della macchina meno efficiente (e' migliore di quello dei P4 ma
rimane un bus condiviso privo di canale dedicato verso la memoria).
insomma, sono architetture profondamente diverse che vanno esaminate
soltanto per i risultati -pratici-, fare paragoni numerici non rende
l'idea.
quanto a scegliere cosa vuoi prendere, i fattori da analizzare sono
moltissimi - opteron e' estremamente efficiente sugli interi, su
applicazioni con uso intensivo della memoria e scala benissimo in mp.
ItaniumII ha una fpu che fa spavento.
cosa richiede il tuo programma?
--
    (iao!!oai)                                    (ICQ: 10860566)
    //.aurizio
[WARNING!: togliete _nessuno_ per rispondere]
    Il segreto per essere considerato un creativo sta nel non fare
    mai riconoscere le proprie fonti [A. Einstein]

 i due processori in oggetto potrebbe
No, non ho provato... purtroppo, magari avessi un Itanium2 o almeno un
bi-opty !!
Però se guardi a 
http://www.spec.org/cpu2000/results/cpu2000.html
 vedi un
bel pò di risultati.
Mi sembra di capire che sugli interi tutto sommato siamo lì, ma nella
virgola mobile, non c'è storia.
Itanium2 è favoloso! C'è da dire però che uno potrebbe allestire una
macchinetta con qualche opteron... e andare MOOOLTO veloce... al prezzo di
un solo itanium2.


E' assai improbabilmente che qualcuno in questo ng
abbia avuto modo di provarli entrambi.
Tieni inoltre presente che con cpu simili conta tantissimo
anche "il sistema" nel complesso.
Per esempio, un quadriprocessore Opteron puo essere configurato
in modo diverso in base a quanti processori usano il memory controller
integrato "locale" e quanti link HT "locali" vengono utilizzati
per l' I/O per un totale teorico di 16 configurazioni diverse
che incidono sulle prestazioni complessive.
Pure nel caso degli Itanium2 influisce il chipset tra
quanti processori viene condiviso il FSB.
Dai risultati dei benchmark reperibili in rete sembra che
l'IA64 (l'architettura su cui sono basati tutti gli Itanium)
abbia prestazioni elevatissime rispetto al clock a cui
lavora (grazie anche alle cache enormi), ma scala decisamente
male in frequenza di clock (e veniva descritto come una cpu che
doveva scalare bene in frequenza!!!!!).
Probabilmente le troppe "cosucce in teoria molto belle" ammassate
nell'architettura IA64 si sono intralciate tra loro segando
le gambe alla possibilita di salire di frequenza.
Giusto per fare un esempio, l'IA64 integra persino un core
"simile ad un Pentium II" per poter eseguire in hardware
applicazioni a 32bit per x86 ... ma e' risultato cosi lento
(ha circa le prestazioni di un Pentium II a 500Mhz
  su Itanium ad 1Ghz) che tempo fa Intel ha rilasciato
un emulatore software (che viene eseguito come un applicazione IA64)
piu veloce della sua stessa emulazione hardware.
Gli Opteron invece sono delle cpu a 64bit per cui si e' scelto
un percorso "evolutivo" rispetto agli x86 a 32bit, sulla carta
*sembrano* meno "impressionanti" ma al lato pratico reggono
il confronto piu che bene.
Negli Opteron i cambiamenti rivoluzionari sono stati fatti
principalmente nella struttura interna e nell'interfacciamento
con l'esterno lasciando il piu possibile intatto il set d'istruzioni.
Il risultato e' che sono delle cpu a 64bit ... che vale *davvero*
la pena prendere *anche* se si usa solo software a 32bit
(con gli IA64 una cosa simile sarebbe un suicidio).
In altre parole un "acquirente tipico" di Opteron puo essere:
- qualcuno a cui serve un sistema x86 *multiprocessore* piu potente
   (e con miglior rapporto prestazioni/prezzo) di uno che
   usa gli Xeon (magari anche solo usando software a 32bit);
- qualcuno a cui serve un sistema a 64bit per qualche applicazione
   ma intende ancora usare *molto* software a 32bit per x86;
- qualcuno a cui serve un sistema a 64bit ma che non intendere
   vendere due reni per un sistema IA64 decente.
Attualmente invece un "aquirente tipico" di IA64 puo essere:
- uno che usava gia sistemi HP con cpu PA-Risc (HP vuole
   traghettare i suoi clienti PA-Risc verso itanium) oppure
   uno che usava gia sistemi SGI (per le stesse ragioni di HP);
- uno che ha deciso di "scommettere" su Itanium.
L. Micheletto


Concordo in pieno. L'IA-64 e x86-64 hanno target completamente diversi.
Saluti.

 cosa richiede il tuo programma?
Ok, bene per le considerazioni.
Quindi, un software di simulazione di tempo atmosferico, se adeguatamente
ottimizzato, è pane per i pin di un McKinley.
Avevo qualche idea della iniquità del confronto. Mi ricordo che si era detto
che gli Opteron, nel 2003, erano stati venduti in quantità doppia rispetto
agli Itanium. C'è da dire che la richiesta di processori per server è più
alta di quella di processori per emulazione/calcolo. E gli Opteron, come
processori da server, sono otttimi. I McKinley come se la cavano?
Ma un quadriprocessore Opteron in elaborazione atmosferica come se la
caverebbe? ;-)
Il mio discorso verteva unicamente su un discorso in soldoni...
letteralmente!
MaxArt

letteralmente!
per il momento Intel ha dalla sua l'immagine, AMD il rapporto
prezzo/prestazioni.


 doveva scalare bene in frequenza!!!!!).
[cut]
Cosa intendi per "scala decisamente male in
frequenza di clock"?
Quindi mi pare di capire che
l'Itanium 2 e' potenzialmente o
realmente piu' performante di un
singolo Opteron, ma quest'ultimo
su server o workstation con due o piu'
processori e' piu' conveniente come
prezzo e prestazioni.


Come prezzo non ci piove... come prestazioni putroppo il bus dell'Itanium
non è ancora efficiente come la soluzione Hypertransport
delle cpu Opteron.
Ciao

 delle cpu Opteron.
[cut]
Quindi giudichi due cpu Opteron piu'
performanti di due cpu Itanium 2?


Dipende dall'ambito applicativo preso in esame...
Se il software č stato programmato con un occhio di riguardo
al set di istruzioni WLIW di Itanium2, allora non c'č Opteron che
tenga.

 al set di istruzioni WLIW...
Ehm, intendevo dire VLIW ;-))

 piu veloce della sua stessa emulazione hardware.
Non ho mai capito cosa servisse l'emulazione hardware: mah. Forse è retaggio
del passato, quando si voleva costruire cpu IA-64 adatte a funzionare nel
2004 nei normali PC. Venuta meno questa esigenza, l'emulazione è totalmente
inutile.
Saluti.

 prezzo e prestazioni.
Se non erro con il prezzone che ti fanno per un Itanium 2
uniprocessore riesci quasi a prendere un Opteron biprocessore.
Forse gli Itanium 3 o gli Itanium 4 risolveranno i problemi
di "crescita" e di rapporto prestazioni/prezzo, ma per ora
a meno che non si abbia deciso di "scommettere sull' Itanium"
anche se serve necessariamente una cpu a 64bit
non vale la pena prenderlo, per ora sono preferibili gli Athlon64
oppure gli  Opteron, hai molte piu possibilita di scelta
in termini di prezzo e prestazioni/prezzo.
L. Micheletto

   in transito " che alla fine paga molto di piu.
nel progetto di opteron ha messo mano l'ideatore degli abortiti Alpha
EV7, la filosofia e' la stessa sia pure adattata ad un panorama
diverso.
e si vede.



all'aumentare del numero di processori il vantaggio si riduce
drasticamente... 4 itanium vs 4 opteron siamo proprio sul filo di lana
in fp-intensive, con un costo frazionario.



Certo, specie a causa dello "scarso" bus presente nelle MB Itanium...
Ma se si tratta di due cpu (ovvero quello che intendevo), allora
ripeto che non c'è storia.
Saluti

 tenga.
Non dovrebbe essere comunque, dato che dipende
dal compilatore?
bye,
-- 
   Piergiorgio Sartor

 dal compilatore?
Uhmmm... Dipende anche da cosa fa l'applicazione. Deve prestarsi ad
avere luuuuunghe strisce di codice eseguibile fp. Un programma che fa
fp ma non si riesce a parallelizzare abbastanza e` penalizzato un
pochetto.
-- 
Valentino Volonghi, Regia SpA, Milan
Linux User #310274, Gentoo Proud User

 inutile.
Ma per favore... Tu la storia non sai da che parte stia.


 pochetto.
Questo vale in tutti casi, sia IA-64 che K8.
bye,
-- 
piergiorgio

 in fp-intensive, con un costo frazionario.
Senza contare che per ora le FPU SSE2 sia su P4 che su K8
producono DUE valori a 64bit
(il risultato su un registro XMM in formato 64+64bit floating point)
ogni DUE cicli di clock.
Se con il K9 o con il K10 con qualche genialata o sfruttando il passaggio
a scale d'integrazione superiori (piu area sul chip, ecc. ecc.)
"sacrificano" in parte la crescita in frequenza per arrivare
a poter produrre DUE valori a 64bit per UN ciclo di clock, l'impennata
in prestazioni sul floating point potrebbe portare allo scavalcamento
delle prestazioni FP degli Itanium.
L. Micheletto

 e si vede.
Dicono che per il 2006 e' prevista l'uscita di una nuova versione
di Itanium sviluppara da (quel che resta) del team di sviluppo degli Alpha
che lavorava per Compaq.
Avevano alcune ideuzze non male, tipo l'architettura "Piranha" con 8..16
cpu "virtuali".
L'idea e' che "cpu virtuali" si spartiscono le risorse sullo stesso
chip eliminando la necessita' di circuiti che selezionino istruzioni da
eseguire in parallelo su un singolo thread (le si prende da thread
distinti, quindi a parte le istruzioni di sincronizzazione non
hanno dipendenze tra loro) e rendendo accettabili latenze alte sulle unita
di esecuzione  visto che nei vari stadi delle pipeline si possono
inserire istruzioni provenienti da thread diversi e quindi gia
disaccoppiate (e se si predice male un jump basta "annullare" solo
le istruzioni del thread che deve "ricaricare", senza svuotare
la pipeline o bloccare l'esecuzione sugli altri thread).
Non si tratterebbe di "Hyperthreading" (o di SMT come dicevano
quelli che lavoravano sugli Alpha) ma della sua evoluzione
(con cache L1 decenti e tutto il resto opportunamente
  dimensionato, non roba striminzita come hanno fatto con i P4).
L. Micheletto

 piu veloce della sua stessa emulazione hardware.
Recentemente Intel ha rilasciato un nuovo "Execution Layer" che
dovrebbe migliorare ulterioemente l'efficienza di esecuzione
delle applicazioni a 32bit... dovrebbe avere delle prestazioni
paragonabili alle cpu XeonMP a 1.5GHz.
Ciao

 wrote:
(cuttone)
Innanzitutto grazie infinite per questo thread, leggervi è un vero
piacere... :-)
Poi, potreste dirmi qualcosa riguardo a *cosa* hanno messo in IA-64?
Insomma, quali sono queste features di cui l'hanno riempito?
Ve lo chiedo perché da noi al poli, a fine febbraio arriveranno due
macchine IA-64, nuovissime (nei miei sogni più arditi vedo già due
madison, *sbav* - anche se ovviamente non ci conto poi tanto...),
courtesy of HP, su cui sarà installato un porting di OpenVMS e,
ovviamente, appena ho sentito parlare di una tesina di sicurezza dei
sistemi operativi lì sopra, mi sono fiondato come un avvoltoio ;-)
Ora, passato l'entusiasmo inizio a rendermi conto di quale grana
rischio di essermi scelto :P 
Quindi volevo chiedervi se potete dirmi qualcosa in più su IA-64 o se
mi sapete consigliare qualche link che spieghi l'architettura (senza
scendere troppo nel dettaglio, in fondo non mi faranno programmare in
assembler... :P)
Grazie mille, comunque ^____^
-- 
ZHELGADIS THE LIGHTBRINGER (ICQ 33134824)
BAG#008,DPPSJ#000,BAT#013,TFC#012,GAM#026,ZZZZ#027,CID#027,PAN#015
"Aspettare non è mai stato un problema, per me.
Posso trascorrere piacevolmente ore e ore con l'aiuto di un buon caffè"

 rischio di essermi scelto :P
Iinfatti... buona fortuna ;-pp
 Saluti

Iinfatti... buona fortuna ;-pp
Lascia perdere, penso che inizierò a sognarmelo pure di notte O_o;;;


 rischio di essermi scelto :P 
Gia, OpenVMS e' un pianeta a parte.
In compenso gli esperti di VMS/OpenVMS sono pagati bene.
L. Micheletto

cpu "virtuali".
tutto vapore, hanno soltanto riciclato alcune idee di IBM temo. :-\


disponibile in quel periodo...
Un po' di tempo fa avevo letto su questo ng che uno dei fattori che
aveva stroncato l'Alpha era che, viste le scarse vendite, si usavano
processi produttivi al risparmio, finalizzati a otimizzare le rendite
ma penalizzando le frequenze... ma in definitiva, com'č andata? ^^;
Oltretutto, CompaQ non aveva rilevato anche una parte degli
sviluppatori di Alpha? Quelli che non erano andati ad AMD, per
intenderci...
-- 
ZHELGADIS THE LIGHTBRINGER (ICQ 33134824)
BAG#008,DPPSJ#000,BAT#013,TFC#012,GAM#026,ZZZZ#027,CID#027,PAN#015
"Aspettare non č mai stato un problema, per me.
Posso trascorrere piacevolmente ore e ore con l'aiuto di un buon caffč"

intenderci...
come si dice, bisogna giudicare le persone da quello che fanno, non da
quello che dicono di saper fare.
e quello che hanno fatto in questi anni si e' visto.
niente.
assolutamente niente.
hanno trasformato quella che era proabilmente una delle piu' belle
architetture in assoluto in spazzatura.


architetture in assoluto in spazzatura.
Con che budget, però?
Insomma, da quel che mi hai detto mi sembra di capire che CompaQ ci
abbia messo il minimo indispensabile e forse qualcosa di meno... con
tutti i soldi che ci vogliono a sviluppare una CPU, con risorse così
limitate come si fa a combinare qualcosa?
BTW certo che mi piacerebbe vedere un EV6 lanciato a 3 GHz con un
processo produttivo all'altezza di quelli Intel, AMD o IBM...:-)
-- 
ZHELGADIS THE LIGHTBRINGER (ICQ 33134824)
BAG#008,DPPSJ#000,BAT#013,TFC#012,GAM#026,ZZZZ#027,CID#027,PAN#015
"Aspettare non è mai stato un problema, per me.
Posso trascorrere piacevolmente ore e ore con l'aiuto di un buon caffè"

 wrote:
*snip*
Grazie mille dei link, corro subito a leggere ;)
-- 
ZHELGADIS THE LIGHTBRINGER (ICQ 33134824)
BAG#008,DPPSJ#000,BAT#013,TFC#012,GAM#026,ZZZZ#027,CID#027,PAN#015
"Aspettare non č mai stato un problema, per me.
Posso trascorrere piacevolmente ore e ore con l'aiuto di un buon caffč"

sfugge qualche passaggio logico ^___^;;
sull'argomento mi girano troppo per essere completamente logico... :-)


sull'argomento mi girano troppo per essere completamente logico... :-)
Eh, ti capisco... ^^;


 parecchi dollaroni.
La fusione HP-CompaQ e` arrivata da meno di quando Intel ha iniziato a
lavorare su Itanium. HP stava gia` lavorando ai chipset per quel
processore (zx1 si dice faccia miracoli) e inoltre lavora a stretto
contatto con Intel per Itanium che e` simile (nel package) agli HP-PA
(questo qualche tempo fa almeno, ora non saprei).
Indubbiamente come al solito i markettari avranno fatto i conti nelle
tasche dei tecnici/ricercatori imponendo mezzi e modi di lavorare (e`
questa l'assurdita` del mondo moderno...).


Valentino Volonghi aka Dialtone wrote:

C'e' anche da dire che c'erano altri vincoli.
Intel aveva stretto accordi ferrei con HP riguardo Itanium, questo
perche Intel aveva bisogno di un azienda produttrice di computer
"di fascia alta" che la appoggiasse al 100% ed HP non aveva piu
le risorse per continua a spingere i suoi processori RISC contro
la concorrenza diretta Sun ed IBM.
In precedenza negli anni '90, nel periodo in cui la cpu x86 di punta
era il 486, Intel aveva tentato di fare il balzo verso la "fascia alta"
delle cpu con il processore RISC i80860 (da non confondere con
il chipset i860) ma proprio perche non fu "adottato" da nessuno
dei grossi produttori di workstation/server (e neppure dai "piccoli"
se ricordo bene) alla fine fu praticamente abbandonato
(lo usarono come "processore grafico" in alcune schede video
  di fascia alta).
Quando Intel ci riprovo' con l'Itanium fece due cose:
- preannuncio' che "non avrebbe fatto prigionieri" ovvero
   dichiaro' Itanium (a quel tempo ancora chiamato solo EPIC o "Merced")
   *LA* sua cpu a 64bit, ovvero che avrebbe cercato in tutti
   i modi di "traghettare" (con calma) tutti gli utilizzatori
   di x86 verso Itanium;
- strinse accordi con produttori di computer "di fascia alta"
   che ormai erano agli sgoccioli a livello tecnologico/economico
   con le loro cpu proprietarie (SGI che usava cpu MIPS ed HP
   che usava cpu HP-PA), in modo tale da avere un sicuro supporto
   a livello di produttori di pc con l'immagine "giusta" per
   vendere a chi compra sistemi di fascia alta.
Quando HP si e' ritrovata con la cpu Alpha da mantenere
ha fatto solo lo stretto necessario (visto che aveva gia scommesso
troppo su Itanium).
L. Micheletto

questa l'assurdita` del mondo moderno...).
Difatti la seconda opzione nel mio post era che i contratti firmati da
Intel non lasciassero via d'uscita... ;-)
-- 
ZHELGADIS THE LIGHTBRINGER (ICQ 33134824)
BAG#008,DPPSJ#000,BAT#013,TFC#012,GAM#026,ZZZZ#027,CID#027,PAN#015
"Aspettare non č mai stato un problema, per me.
Posso trascorrere piacevolmente ore e ore con l'aiuto di un buon caffč"

Intel non lasciassero via d'uscita... ;-)
insomma, in HP non sono proprio del tutto idioti....
approposito: server opteron, pure loro ;-)


approposito: server opteron, pure loro ;-)
Già, visto... a quanto pare i contratti con Intel non sono così
stringenti.
A questo punto però mi chiedo il senso di esistere di un K8 / s754
senza i 64bit... un ottimo modo per ritardare l'adozione di AMD64,
IMVHO.
-- 
ZHELGADIS THE LIGHTBRINGER (ICQ 33134824)
BAG#008,DPPSJ#000,BAT#013,TFC#012,GAM#026,ZZZZ#027,CID#027,PAN#015
"Aspettare non è mai stato un problema, per me.
Posso trascorrere piacevolmente ore e ore con l'aiuto di un buon caffè"