Link alla notizia: http://www.hwupgrade.it/news/business/itanium-9300-intel-presenta-le-cpu-tukwila_31544.html

Al debutto nei prossimi 3 mesi le prime cpu Itanium basate su architettura quad core, da lungo tempo attese al debutto sul mercato

Click sul link per visualizzare la notizia.

185 Watt...:O

Sul 9350 si può installare Windows 95 in cache :eek: :O :D

ahahah :D

ma gli itanium non sono processori con tecnologia nativa a 64 bit? giusto?

non vengono usati per i server o applicazioni particolari?

Che se ne fanno di un Itanium a 64bit costruito a 65 nm con 185 Watt di TDP (sapendo poi come lo calcola Intel sul consumo medio...saranno minimo 210/220)...e soprattutto con una frequenza così bassa che non giustifica neanche tali consumi?

Ok ha 24 MB di cache, ma credo che con uno Xeon basato sugli attuali i7, offra un rapporto prezzo/prestazioni/consumi di per se moooolto importante, da non giustificare tali CPU...

Poi IMHO non sono esperto.

Effettivamente non capisco nemmeno io l'utilità degli itanium. E' ormai storico che gli itanium vadano peggio degli xeon e costino tantissimo. Rapporto prezzo\prestazioni bassissimo, se poi si aggiunge prestazioni\consumi si cade ancora più in basso.

Effettivamente non capisco nemmeno io l'utilità degli itanium. E' ormai storico che gli itanium vadano peggio degli xeon e costino tantissimo. Rapporto prezzo\prestazioni bassissimo, se poi si aggiunge prestazioni\consumi si cade ancora più in basso.


sono nati per segmenti di mercati diversi, dove servono gli itanium un xeon si puo considerare alla stregua di un celeron a confronto

Il motivo della realizzazione del più conservativo processo a 65nm potrebbe essere questo:

http://www.tgdaily.com/networking-brief/48339-intel-itanium-outsells-amd-opteron

"The way Intel has designed the transistors is 100X stronger than the previous generation. They're resistant to cosmic rays.

Intel has double device data protection for the first time. The Quick Path Interconnect allows for "self healing" with half bandwidth QPI. You can hotplug practically everything delivering a virtual reliability environment."

non so' quanto l'abbiano sparata questa cosa, ma diciamo che hanno puntato in alto per qualche appalto militare :)

Hanno sempre l'architettura EPIC giusto?

Io penso che invece sia tutta una montatura commerciale-ludica. Che i 64bit siano meglio dei 32bit non lo metto in dubbio, ma qual è il vantaggio reale? Cioè quantificando in un'unità di misura come il tempo, ad esempio, qual è il vantaggio temporale?

Io non ci credo alla storiella che i 64bit sono utili per i database e il calcolo scientifico. Penso che invece vadano un pochino meglio dei 32, ma quel pochino non dovrebbe giustificare il fatto che gli itanium sono esosi e truzzi. Quindi sono per far vedere che ce l'hanno più lungo!

-edit-
Dopo i due messaggi precedenti, riconfermo ciò che ho detto.

Non esiste solo il mondo desktop e workstation, prima di commentare mettete le cose in prospettiva... :rolleyes:

Meglio i Power7 di IBM x questo segmento IMHO!!!

Non esiste solo il mondo desktop e workstation, prima di commentare mettete le cose in prospettiva... :rolleyes:

Il mondo server è pieno zeppo di aziende lucrose. Non mi sorprende che intel ne faccia parte. Secondo me vuole spacciare l'itanium come un processore insostituibile, "che non se ne può fare a meno", come nelle pubblicità che ti sponsorizzano la fascia in neoprene per perdere la pancia.

Se come è stato suggerito, intel vuole piazzare il processore in zona militare, allora è chiaro che dei consumi non frega niente nè all'uno nè all'altro.

Meglio i Power7 di IBM x questo segmento IMHO!!!
Giustamente, non c'è solo intel!
Anche i primissimi AMD, forse nessuno ne ha mai sentito parlare, ma andavano mooolto meglio degli xeon e degli itanium. Non hanno preso piede xkè intel ha fatto una strategia di mercato sfavorevole agli altri concorrenti.

E se non erro è da 2 anni che stà facendo la stessa cosa nell'ambito desktop e work.

Io penso che invece sia tutta una montatura commerciale-ludica. Che i 64bit siano meglio dei 32bit non lo metto in dubbio, ma qual è il vantaggio reale? Cioè quantificando in un'unità di misura come il tempo, ad esempio, qual è il vantaggio temporale?

Io non ci credo alla storiella che i 64bit sono utili per i database e il calcolo scientifico. Penso che invece vadano un pochino meglio dei 32, ma quel pochino non dovrebbe giustificare il fatto che gli itanium sono esosi e truzzi. Quindi sono per far vedere che ce l'hanno più lungo!

-edit-
Dopo i due messaggi precedenti, riconfermo ciò che ho detto.

In ambito Server, soprattutto per grosse dimensioni, i 64 bit sono fondamentali, riescono a maneggiare quantità di memoria impressionanti senza problemi, inolter possono arrivare a processare, grazie ad alcuni tipi di istruzioni, anche il doppio dei dati di un 32 Bit, giusto epr rimanere sul vago.

Per verificare quanto possa migliorare basta che vai a vedere come un applicazione banale come la compressione decompressione di un file può migliorare, poi fale le debite proporzioni con i miglioramenti che può dare su applicazioni meno banali.

Il mondo server è pieno zeppo di aziende lucrose. Non mi sorprende che intel ne faccia parte. Secondo me vuole spacciare l'itanium come un processore insostituibile, "che non se ne può fare a meno", come nelle pubblicità che ti sponsorizzano la fascia in neoprene per perdere la pancia.

Se come è stato suggerito, intel vuole piazzare il processore in zona militare, allora è chiaro che dei consumi non frega niente nè all'uno nè all'altro.


Giustamente, non c'è solo intel!
Anche i primissimi AMD, forse nessuno ne ha mai sentito parlare, ma andavano mooolto meglio degli xeon e degli itanium. Non hanno preso piede xkè intel ha fatto una strategia di mercato sfavorevole agli altri concorrenti.

E se non erro è da 2 anni che stà facendo la stessa cosa nell'ambito desktop e work.


Non ho mai detto che Itanium sia l'unico processore esistente per quella categortia di prodotti, certamente, anche perchè è praticamente l'ultima architettura nata, è molto affascinante, che poi sia un successo commerciale è un altro discorso.

Io non ci credo alla storiella che i 64bit sono utili per i database e il calcolo scientifico. Penso che invece vadano un pochino meglio dei 32, ma quel pochino non dovrebbe giustificare il fatto che gli itanium sono esosi e truzzi. Quindi sono per far vedere che ce l'hanno più lungo!

-edit-
Dopo i due messaggi precedenti, riconfermo ciò che ho detto.

ti faccio solo un esempio

io in azienda ho 6 grandi server sql e in nessuno potrei far girare un versione a 32bit di ms sql 2005 per motivi di indirizzamento di memoria e di gestione dell'IO quindi performance

inoltre anche il nostro exchange a 64bit va molto piu veloce delle versioni a 32bit (che peraltro non sono piu supportate dalla ms stessa)


altro che storiella;) qua si parla di funziona / non funziona altro che piccole differenze

ovvi che se parli da utente standard con un pc a 32bit e magari 2GB di ram allora è normale che le differenze siano minime e talvolta la versione a 64bit è persino piu esosa di risorse, ma il mondo server e tuttaltra cosa

tanto per farti capire la differenza tra i 32bit e i 64bit è la differenza tra un utilitaria e una fuoriserie, in citta vanno uguali e magari l'utilitaria ha solo vantaggi, sulle strade piu scorrevoli l'utilitaria ha dei vantaggi ma su una pista di gara non esiste nemmeno lontanamente un paragone

OK concetto afferrato!

Io penso che invece sia tutta una montatura commerciale-ludica. Che i 64bit siano meglio dei 32bit non lo metto in dubbio, ma qual è il vantaggio reale? Cioè quantificando in un'unità di misura come il tempo, ad esempio, qual è il vantaggio temporale?

Io non ci credo alla storiella che i 64bit sono utili per i database e il calcolo scientifico. Penso che invece vadano un pochino meglio dei 32, ma quel pochino non dovrebbe giustificare il fatto che gli itanium sono esosi e truzzi. Quindi sono per far vedere che ce l'hanno più lungo!

Ma che c'entrano i 64 bit? Itanium ha un'architettura completamente diversa, è stato pensato per eseguire molte più istruzioni in parallelo (non per niente EPIC sta per explicitly parallel instruction computing).
Gli Intel sono limitati a 4 istruzioni per clock, e in media non superano le due, AMD si ferma a 3, un Itanium 2 se ben sfruttato riesce ad eseguire 6 istruzioni per clock.
Il che gli conferisce prestazioni che le normali cpu desktop si sognano.

Non parliamo in modo leggero di architettura che non si conoscono.

Ma che c'entrano i 64 bit? Itanium ha un'architettura completamente diversa, è stato pensato per eseguire molte più istruzioni in parallelo (non per niente EPIC sta per explicitly parallel instruction computing).
Gli Intel sono limitati a 4 istruzioni per clock, e in media non superano le due, AMD si ferma a 3, un Itanium 2 se ben sfruttato riesce ad eseguire 6 istruzioni per clock.
Il che gli conferisce prestazioni che le normali cpu desktop si sognano.

Non parliamo in modo leggero di architettura che non si conoscono.

Quoto è il primo commento serio che leggo.
Itanium poi è un 64bit nativo ma tutti lo confondono con il 64bit introdotto da amd e poi usato anche da intel ossia x64 o detto amd64.
La differenza tra i 2 64bit è notevole e non confrontabile.

Sono architetture diverse è la stessa differenza che c'è tra Power, Mips ed itanium...

Che poi i 64Bit delle architetture per comuni mortali non siano il massimo è un'altro discorso ;)

avete mai provato ad usarlo in associazione con openvms?? vi si potrebbe aprire un mondo!!

sono nati per segmenti di mercati diversi, dove servono gli itanium un xeon si puo considerare alla stregua di un celeron a confronto

Questo è ciò che il marketing Intel vende adesso... in realtà nelle intenzioni (parlo dei piani Intel di fine anni 90), IA64 doveva rimpiazzare IA32 e cominciare la "planata" nel settore workstation già nel 2002.
Intel aveva intenzione di andare avanti col PIII un po' per volta, poi introdurre il P4 come ultima CPU x86 per poi lasciar campo libero all'Itanium che, con la sua modalità di emulazione x86, avrebbe potuto proporsi come "un nuovo 64 bit in grado di far girare anche le applicazioni legacy". Come "effetto collaterale", questo avrebbe restituito il monopolio delle CPU ad Intel, visto che solo lei può produrre CPU IA64

Il K7 ha fatto saltare tutti i piani, imponendo ad Intel una ricorsa sempre più frenetica, che ha portato gli x86 a livelli prestazionali tali per cui non è più stato possibile offrire IA64 come un processore general purpose. Consumava tantissimo (si parla di 130W nel 2000), andava su codice x86 quanto un P100 (Merced) o un PII/500 (McKinley) ed i compilatori non riuscivano a sfruttare EPIC adeguatamente (ci arrivo dopo).

Nel 2002 AMD poi è uscita col K8, che offriva i 64 bit (con i vantaggi conseguenti per quel che riguarda l'indirizzamento di memoria ed il calcolo intero pesante - encoding, crittografia...), l'architettura NUMA contrapposta al FSB di McKinley (per cui se il singolo K8 le prendeva in lungo ed in largo, su sistemi 8-way la musica cominciava a cambiare) e ad una frazione del costo, cosa non indifferente.

Insomma, per sua fortuna Intel aveva nel cassetto il defunto progetto Timna, che affidato agli israeliani è diventato Banias, e da lì l'architettura Core. Questo però ha voluto dire confinare gli Itanic all'unica fascia di mercato in cui gli x86 non possono (ancora?) arrivare.

Il tutto al prezzo di _centinaia_di_miliardi_di_dollari_, oltre al sacrificio di archittetture come Alpha e PA-Risc, immolate sull'altare di Itanic. BTW, visto che qualcuno parla di OpenVMS, un dirigente di HP nel 2004 affermava che era previsto per il 2005 il pareggio prestazionale tra Alpha e IA64... peccato che lo sviluppo di Alpha fosse sostanzialmente fermo dal 2000.

Se come è stato suggerito, intel vuole piazzare il processore in zona militare, allora è chiaro che dei consumi non frega niente nè all'uno nè all'altro.

Conta, conta, eccome se conta...
Consumo vuol dire affidabilità, in altri casi vuol dire durata delle batterie, il consumo è fattore sempre più importante. Che si parli di resistenza ai raggi cosmici mi fa pensare ad applicazioni spaziali, nello spazio non hai una centrale nucleare sotto mano per alimentare i sistemi :D

Ma che c'entrano i 64 bit? Itanium ha un'architettura completamente diversa, è stato pensato per eseguire molte più istruzioni in parallelo (non per niente EPIC sta per explicitly parallel instruction computing).
Gli Intel sono limitati a 4 istruzioni per clock, e in media non superano le due, AMD si ferma a 3, un Itanium 2 se ben sfruttato riesce ad eseguire 6 istruzioni per clock.
Il che gli conferisce prestazioni che le normali cpu desktop si sognano.

Si, SE è sfruttato a dovere :)
EPIC è un'architettura di tipo VLIW, che non prevede cose come OOE e branch prediction. Sta al compilatore trovare blocchi di istruzioni che possano essere mandati in esecuzione in parallelo, diversamente ogni "parola" di istruzioni (256 bit in Merced, non so se sia stata ampliata in seguito) si riempie di NOP e ti trovi con grosse parti del processore che si gira amenamente i pollici.

Qualcosa il compilatore può fare (ed il compilatore Intel è veramente cazzuto), ma se il codice è pensato per essere eseguito su CPU sequenziali (tutto il codice legacy che gira su x86, per dirne una, e molto codice che gira su altri sistemi a cui IA64 vuole rubare mercato) non è detto che basti, nel qual caso bisogna rimettere mano ai sorgenti ed ottimizzare tutto. Un po' peggio che spararsi in un piede, diciamo :)

Insomma, per essere potente è potente ma non semplice da sfruttare, e dannatamente inefficiente con codice non scritto ad hoc. Una delle combinazioni più letali, in questo mondo.

@zhelgadis

Concordo praticamente su tutto il fronte :)
EPIC rimane un'architettura eccezionale, ma come tutti deve fare i conti con la realtà ed un mare di applicazioni vecchie che costano tante e che andrebbero riscritte.

Si, SE è sfruttato a dovere :)
EPIC è un'architettura di tipo VLIW, che non prevede cose come OOE e branch prediction. Sta al compilatore trovare blocchi di istruzioni che possano essere mandati in esecuzione in parallelo, diversamente ogni "parola" di istruzioni (256 bit in Merced, non so se sia stata ampliata in seguito) si riempie di NOP e ti trovi con grosse parti del processore che si gira amenamente i pollici.

Qualcosa il compilatore può fare (ed il compilatore Intel è veramente cazzuto), ma se il codice è pensato per essere eseguito su CPU sequenziali (tutto il codice legacy che gira su x86, per dirne una, e molto codice che gira su altri sistemi a cui IA64 vuole rubare mercato) non è detto che basti, nel qual caso bisogna rimettere mano ai sorgenti ed ottimizzare tutto. Un po' peggio che spararsi in un piede, diciamo :)

Insomma, per essere potente è potente ma non semplice da sfruttare, e dannatamente inefficiente con codice non scritto ad hoc. Una delle combinazioni più letali, in questo mondo.
Ovviamente, d'altronde più aumenti il parallelismo e più è importante l'ottimizzazione, soprattutto con architetture del genere, alla fine il problema è sempre quello, ma dove i normali x86 cercano di far rendere al massimo l'architettura superscalare anche tramite "ottimizzazioni hardware" nel caso di Itanium è praticamente tutto a carico della scrittura del codice e della compilazione.
L'approccio per certi versi è geniale, però sappiamo bene un po' tutti che maggiore sbattimento (nella scrittura del codice) e minore flessibilità generalmente non sono caratteristiche vincenti.

Alla fine Itanium resta un buon processore con un'architettura sicuramente interessante, che non ha avuto il successo sperato per via della sottovalutazione dei lati negativi dell'architettura.
Si sono visti fallimenti peggiori in fondo :D

L'unico problema di Itanium è il software preesistente scritto non troppo bene, il software ben scritto non ha problemi.

@zhelgadis
..wow 10 anni di storia in un post..complimenti. :)
in questo step 9300 ho visto un'attenzione particolare verso bus di interconessione , bandwidth ram, cache.Che sia un test per un aumento verticale dei core nelle prossime versioni?...nonostante le difficolta' pare che su EPIC Intel continui a crederci. :)

Questo è ciò che il marketing Intel vende adesso... in realtà nelle intenzioni (parlo dei piani Intel di fine anni 90), IA64 doveva rimpiazzare IA32 e cominciare la "planata" nel settore workstation già nel 2002.
Intel aveva intenzione di andare avanti col PIII un po' per volta, poi introdurre il P4 come ultima CPU x86 per poi lasciar campo libero all'Itanium che, con la sua modalità di emulazione x86, avrebbe potuto proporsi come "un nuovo 64 bit in grado di far girare anche le applicazioni legacy". Come "effetto collaterale", questo avrebbe restituito il monopolio delle CPU ad Intel, visto che solo lei può produrre CPU IA64

Il K7 ha fatto saltare tutti i piani, imponendo ad Intel una ricorsa sempre più frenetica, che ha portato gli x86 a livelli prestazionali tali per cui non è più stato possibile offrire IA64 come un processore general purpose. Consumava tantissimo (si parla di 130W nel 2000), andava su codice x86 quanto un P100 (Merced) o un PII/500 (McKinley) ed i compilatori non riuscivano a sfruttare EPIC adeguatamente (ci arrivo dopo).

Nel 2002 AMD poi è uscita col K8, che offriva i 64 bit (con i vantaggi conseguenti per quel che riguarda l'indirizzamento di memoria ed il calcolo intero pesante - encoding, crittografia...), l'architettura NUMA contrapposta al FSB di McKinley (per cui se il singolo K8 le prendeva in lungo ed in largo, su sistemi 8-way la musica cominciava a cambiare) e ad una frazione del costo, cosa non indifferente.

Insomma, per sua fortuna Intel aveva nel cassetto il defunto progetto Timna, che affidato agli israeliani è diventato Banias, e da lì l'architettura Core. Questo però ha voluto dire confinare gli Itanic all'unica fascia di mercato in cui gli x86 non possono (ancora?) arrivare.

Ottima analisi :)


Il tutto al prezzo di _centinaia_di_miliardi_di_dollari_, oltre al sacrificio di archittetture come Alpha e PA-Risc, immolate sull'altare di Itanic. BTW, visto che qualcuno parla di OpenVMS, un dirigente di HP nel 2004 affermava che era previsto per il 2005 il pareggio prestazionale tra Alpha e IA64... peccato che lo sviluppo di Alpha fosse sostanzialmente fermo dal 2000.

Vero, però tieni conto che molto di quello che era l'Alpha 21624 è finito dei K7/K8. La vera differenza tra gli Alpha e i processi AMD è il frontend: questi ultimi, essendo CISC, dedicano parecchi transistors all'unità di decodifica e, giocoforza, perdono in qualche modo sul piano puramente prestazionale in quanto il decoder allunga la pipeline.


Si, SE è sfruttato a dovere :)
EPIC è un'architettura di tipo VLIW, che non prevede cose come OOE e branch prediction. Sta al compilatore trovare blocchi di istruzioni che possano essere mandati in esecuzione in parallelo, diversamente ogni "parola" di istruzioni (256 bit in Merced, non so se sia stata ampliata in seguito) si riempie di NOP e ti trovi con grosse parti del processore che si gira amenamente i pollici.

Qualcosa il compilatore può fare (ed il compilatore Intel è veramente cazzuto), ma se il codice è pensato per essere eseguito su CPU sequenziali (tutto il codice legacy che gira su x86, per dirne una, e molto codice che gira su altri sistemi a cui IA64 vuole rubare mercato) non è detto che basti, nel qual caso bisogna rimettere mano ai sorgenti ed ottimizzare tutto. Un po' peggio che spararsi in un piede, diciamo :)

Già, l'architettura VLIW non è certo banale da programmare dal punto di vista del compilatore. Riguardo la mancanza dell'esecuzione fuori ordine, è vero che non aiuta le prestazioni, ma d'altro canto permette di risparmiare veramente tanti transistor, che si possono utilizzare nella creazione di un back-end più robusto: non a caso questa fu la scelta di IBM nel caso dei Power6. Curiosamente i Power7 hanno ripristinato l'esecuzione fuori ordine... :)


Insomma, per essere potente è potente ma non semplice da sfruttare, e dannatamente inefficiente con codice non scritto ad hoc. Una delle combinazioni più letali, in questo mondo.
Vero anche questo, però il nuovo SMT a 4 vie dovrebbe aiutare parecchio Tukwilla. Certo che però Power7 rimane un avversario davvero tosto... anzi, penso che anche Nehalem EX (8 core, 16 thread, 24 MB L3) non scherzi per niente (anche se poi ci sono in gioco altri fattori che non permettono a processori di questa tipologia la "scalata" immediata verso il mondo RISC).

A mio avviso, Intel crede troppo nella sua leadership sui processi di fabbricazione: riservare 24 MB di cache L3 "classica" (6 transistors per bit) porta a una quantità di transistors utilizzati davvero astronomica (riguardo ai consumi, dovremmo essere a circa 1 W per MB, quindi non ancora valori altissimi).
Una più lenta cache eDRAM 1T + 1C o, ancora meglio, una 1T-SRAM avrebbe probabilmente permesso a Intel di integrare anch'essa gli 8 core. Che dire, avranno avuto i loro motivi :)

Riguardo l'esecuzione fuori ordine, è vero che non aiuta le prestazioni, ma d'altro canto permette di risparmiare veramente tanti transistor, ...

Forse ho capito il contrario di quello che intendevi... perche' l'esecuzione fuori ordine aumenta le prestazioni di *tanto*, ma richiede un botto di transistor (ed e' cosi' complessa da gestire che le compagnie che sono in grado di costruire processori superscalari OOO si contano sulle dita di una mano: IBM, Intel, AMD, Fujitsu, e credo basta).

IBM ha un'esperienza e possibilità che son difficili da affrontare anche per Intel, fa ricerca sia di base e moto altro... in più l'architettura Power può contare sul fatto che IBM gli costruisca intorno tutto, sia dal punto di vista hardware che software, cosa che Intel non può fare altrettanto bene.

Vero, però tieni conto che molto di quello che era l'Alpha 21624 è finito dei K7/K8. La vera differenza tra gli Alpha e i processi AMD è il frontend: questi ultimi, essendo CISC, dedicano parecchi transistors all'unità di decodifica e, giocoforza, perdono in qualche modo sul piano puramente prestazionale in quanto il decoder allunga la pipeline.

Hai ragione, mi ero dimenticato di accennare alla cosa... :)
In fondo si può dire che gli Alpha abbiano avuto la loro rivincita. Certo però che un Alpha EV8 sviluppato senza il vincolo della retrocompatibilità x86... mah, mi sa che me lo posso giusto sognare di notte :rolleyes:
Fra l'altro con un transistor count ridicolo, il 21264 aveva (se non vado errato) il 30-50% in meno dei transistor del K7, al netto della cache.
Insomma, frequenze da P4 con un'efficienza superiore a quella del K7, il tutto nel 1999 :(

A mio avviso, Intel crede troppo nella sua leadership sui processi di fabbricazione: riservare 24 MB di cache L3 "classica" (6 transistors per bit) porta a una quantità di transistors utilizzati davvero astronomica (riguardo ai consumi, dovremmo essere a circa 1 W per MB, quindi non ancora valori altissimi).
Una più lenta cache eDRAM 1T + 1C o, ancora meglio, una 1T-SRAM avrebbe probabilmente permesso a Intel di integrare anch'essa gli 8 core. Che dire, avranno avuto i loro motivi

Guarda, sicuramente in Intel questi conti sono capaci a farli ;)
Purtroppo i ricordi sono un po' sbiaditi, ma avevo letto ai tempi una splendida disamina dell'architettura fatta da uno dei saggi di ICHC, in cui spiegava che Itanium, per come è concepito, ha bisogno di cache non solo mastodontiche, ma pure veloci.
Di usare memoria DRAM per la cache se ne parla già da un po' ma nessuno ha ancora messo in pratica i buoni propositi, chissà se ci si arriverà in futuro... certo, sarebbe un risparmio di silicio non da poco.

L'unico problema di Itanium è il software preesistente scritto non troppo bene, il software ben scritto non ha problemi.

Cosa significa "bene"? Pensi che tutto il codice x86 in giro sia stato scritto da incapaci?
Semplicemente, è codice scritto avendo presente la CPU su cui doveva girare, molto diversa dall'Itanium.

Pensa che bello se tu comprassi un programma che gira lentissimo sul tuo sistema e ti spiegassero che è una cosa voluta perché sono già pronti a supportare le architetture che ci saranno tra dieci anni :D

Il mio post di sopra nel forum si legge bene, nella pagina della notizia malissimo... :rolleyes:

Forse ho capito il contrario di quello che intendevi... perche' l'esecuzione fuori ordine aumenta le prestazioni di *tanto*, ma richiede un botto di transistor (ed e' cosi' complessa da gestire che le compagnie che sono in grado di costruire processori superscalari OOO si contano sulle dita di una mano: IBM, Intel, AMD, Fujitsu, e credo basta).

E' che mi sono espresso male io... :D

Si parlava della non presenza dell'OOO e quindi ho sottinteso la parola "mancanza"... mea culpa (si scrive così?) :D

Hai ragione, mi ero dimenticato di accennare alla cosa... :)
In fondo si può dire che gli Alpha abbiano avuto la loro rivincita. Certo però che un Alpha EV8 sviluppato senza il vincolo della retrocompatibilità x86... mah, mi sa che me lo posso giusto sognare di notte :rolleyes:
Fra l'altro con un transistor count ridicolo, il 21264 aveva (se non vado errato) il 30-50% in meno dei transistor del K7, al netto della cache.
Insomma, frequenze da P4 con un'efficienza superiore a quella del K7, il tutto nel 1999 :(

Già... mi pare che le sole unità di decodifica delle istruzioni CISC occupino l'8% del die di un Athlon64


Guarda, sicuramente in Intel questi conti sono capaci a farli ;)

Ah questo senza dubbio... non volevo sottintendere di saperne più di loro (magari! :D), però pensavo al fatto che in Intel è un po' "cronica" la volontà di sfruttare la loro leadership nella fabbricazione del chip per integrare cache sempre più grandi

Purtroppo i ricordi sono un po' sbiaditi, ma avevo letto ai tempi una splendida disamina dell'architettura fatta da uno dei saggi di ICHC, in cui spiegava che Itanium, per come è concepito, ha bisogno di cache non solo mastodontiche, ma pure veloci.

Di cache ne ha bisogno tanta, è vero, in quanto la codifica VLIW porta via parecchio spazio (soprattutto quando hai delle word piene di nop). Riguardo alla velocità necessaria, per fare una stima spannometrica avrei bisogno di alcuni valori che non ho (capacità di fetch, numero di porte/banchi e cache line size per L1/L2). Comunque non c'è dubbio che Itanium ha bisogno di una veloce L3. Certo che una cella 1T-SRAM o Z-RAM tanto lenta non è ;)

Di usare memoria DRAM per la cache se ne parla già da un po' ma nessuno ha ancora messo in pratica i buoni propositi, chissà se ci si arriverà in futuro... certo, sarebbe un risparmio di silicio non da poco.

Bhe il Power7 implementa proprio 32 MB di eDRAM, e il risultato si vede: 8 core + 32 MB di eDRAM per un computo totale di 1,2 miliardi di transistors. Non certo pochi, ma neanche tantissimi: un ipotetico "Nehalem X2" da 8 core e 16 MB di L3 starebbe intorno agli 1,5 miliardi, il futuro (e non ipotetico) Nehalem EX (8 core e 24 MB L3) ne avrà circa 2,2 miliardi, mentre Tukwila (4 core e 30 MB L2) sta a oltre 2 miliardi.

Ciao. :)

Hai ragione, mi ero dimenticato di accennare alla cosa... :)
In fondo si può dire che gli Alpha abbiano avuto la loro rivincita. Certo però che un Alpha EV8 sviluppato senza il vincolo della retrocompatibilità x86... mah, mi sa che me lo posso giusto sognare di notte :rolleyes:
Fra l'altro con un transistor count ridicolo, il 21264 aveva (se non vado errato) il 30-50% in meno dei transistor del K7, al netto della cache.
Insomma, frequenze da P4 con un'efficienza superiore a quella del K7, il tutto nel 1999 :(



Guarda, sicuramente in Intel questi conti sono capaci a farli ;)
Purtroppo i ricordi sono un po' sbiaditi, ma avevo letto ai tempi una splendida disamina dell'architettura fatta da uno dei saggi di ICHC, in cui spiegava che Itanium, per come è concepito, ha bisogno di cache non solo mastodontiche, ma pure veloci.
Di usare memoria DRAM per la cache se ne parla già da un po' ma nessuno ha ancora messo in pratica i buoni propositi, chissà se ci si arriverà in futuro... certo, sarebbe un risparmio di silicio non da poco.



Cosa significa "bene"? Pensi che tutto il codice x86 in giro sia stato scritto da incapaci?
Semplicemente, è codice scritto avendo presente la CPU su cui doveva girare, molto diversa dall'Itanium.

Pensa che bello se tu comprassi un programma che gira lentissimo sul tuo sistema e ti spiegassero che è una cosa voluta perché sono già pronti a supportare le architetture che ci saranno tra dieci anni :D

Il codice è scritto con linguaggi di programmazione di alto livello se un compilatore non riesce a compilarlo in modo efficiente significa che è stato scritto male, codice scritto bene è anche facilmente ottimizzabile.
In più, in genere, più il codice è scritto bene più è portatile, eccetto specifiche occasioni.

Il motivo della realizzazione del più conservativo processo a 65nm potrebbe essere questo:

http://www.tgdaily.com/networking-brief/48339-intel-itanium-outsells-amd-opteron

"The way Intel has designed the transistors is 100X stronger than the previous generation. They're resistant to cosmic rays.

Intel has double device data protection for the first time. The Quick Path Interconnect allows for "self healing" with half bandwidth QPI. You can hotplug practically everything delivering a virtual reliability environment."

non so' quanto l'abbiano sparata questa cosa, ma diciamo che hanno puntato in alto per qualche appalto militare :)

Non so perché ma questa news + il tuo commento mi suonano molto familiari... :stordita:

ma oggi come oggi questo tipo di cpu dove viene utilizzata?sui server non si usano le cpu a 64 bit?(chiaramente con i relativi applicativi a 64 bit)