Itanium 9300: Intel presenta le cpu Tukwila

[dr.gazza]

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

[zhelgadis]

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

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.

[Duncan]

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

[Sapo84]

Originariamente inviato da zhelgadis

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

[Duncan]

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

[Space99]

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

[shodan]

Originariamente inviato da zhelgadis

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

[Pleg]

Originariamente inviato da shodan

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

[Duncan]

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.

[zhelgadis]

Originariamente inviato da shodan

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

Originariamente inviato da Duncan

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

[zhelgadis]

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

[shodan]

Originariamente inviato da Pleg

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

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

[shodan]

Originariamente inviato da zhelgadis

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

[Duncan]

Originariamente inviato da zhelgadis

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

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.

[elevul]

Originariamente inviato da Mparlav

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

http://www.tgdaily.com/networking-br...ls-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...

[lupin87]

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)