Newsgroup: it.comp.hardware.cpu
Titolo: Itanium migliorerà il supporto per i 32bit...

Infatti a quanto pare Intel vuole correre ai ripari per non trovarsi
in una posizione svantaggiosa rispetto all'Opteron per quanto
riguarda l'ancora diffusissimo codice a 32bit degli attuali applicativi.
Bisognerà però vedere quale sarà il reale miglioramento che otterrà Intel
con questa modifica...
http://www.hardwareirc.com/shownews.asp?ID=8305
Saluti

 ha scritto nel messaggio
news:egSpa.709$K35....@news2.tin.it...

Ed anche quest'altra sembra essere un'ottima notizia!
Sono relativamente contento :-)



Interessante. Penso che si tratti all'incirca del sistema implementato dai
Transmeta Crusoe. Cioè, la prima volta compilo da x86 in IA-64, salvo la
versione in IA-64 su HD, poi , la volta dopo, carico la versione compilata
IA-64.
Saluti.

IA-64.
spero... prego che sia proprio cosi' e che eliminino quello
stupidissimo core x86 che integra itanium al momento... :-\
--
    (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]

 stupidissimo core x86 che integra itanium al momento... :-\
Si, anche se non ritengo importante la compatibilitą x86. Un server basato
su Itanium deve avere software totalmente compilato in IA-64, altrimenti č
una stupidata...
Saluti.


Ho letto la cosa su "The Register", li una portavoce di Intel dichiarava
"prestazioni simili ad uno Xeon 1.5Ghz" ma senza specificare se era
una media o un picco o altro e senza specificare su quale modello
di Itanium.
Notare che il meccanismo e' analogo a quello gia sviluppato da DEC
per le cpu Alpha e che quindi richiede un S.O. che fa girare
in emulazione/compilazione_JIT il codice x86 e che poi esegue
le chiamate di sistema in modo nativo.
Non e' che sia quindi una cosa miracolosa ed e' sconsigliata
se si pensa di prendere una macchina del genere solo per fargli girar
sopra applicazioni a 32bit.
L. Micheletto

 sopra applicazioni a 32bit.
Pienamente d'accordo. Usare Itanium 2 per far girare codice IA-32 è assurdo.
Ci vuole software totalmente compilato in IA-64, e in ambito server questo
non dovrebbe rappresentare un problema.
Saluti.


Chiaramente chi si "svena" per prendere un sistema basato
su Itanium, 99su100 non userà applicativi a 32bit, anche se
l'impegno di migliorare l'efficienza di tale codice da parte
di Intel sembrerebbe smentire tutto ciò...
Ciao


Diciamo che hanno sottovalutato la compatibilita con il passato
(come molte altre cose).
Considerato che e' in arrivo l'Opteron a 2Ghz e con vcore
*ribassato* ad 1.45V (questo secondo "the Inquirer" nell'articolo
"Opteron SKUs go to 2000MHz"), devono darsi da fare per "rinforzare"
Itanium prima che sia troppo tardi (inclusa la parte che riguarda
la "compatibilita con gli x86").
IMHO se veramente l'Opteron esce presto a 2Ghz e con vcore a 1.45V
(e questo e' un grande se) significa che i tecnici di AMD
hanno ormai completato la "messa a punto" del SOI e stanno imparando
a sfruttarlo bene (mi aspettavo che arrivassero prima a questo
punto, ma considerando le rogne che hanno passato, meglio ora che mai).
L. Micheletto


wrote:

il problema e' un altro - attualmente gli itanium integrano un _DIE_
x86 embedded che condivide stack e registri con il resto del
processore, richiedendo contest-switching quando viene usato e quindi
ha prestazioni terribili e ruba cicli dopo cicli alle applicazioni
ia64.
intel si e' resa finalmente conto che una virtual machine x86 stile
boche e' piu' veloce di quella chiavica di die embedded e ovviamente
eliminandolo libera milioni di transistor per il processore "vero" che
male non fanno di sicuro.
se continuano con queste opere di snellimento rischiano quasi che
itanium finisca per piacermi, adesso il prossimo obiettivo: le SSE!
che cavolo ci fa un'unita' specifica per elaborare delle istruzioni
simd neanche tanto efficenti separata affiancata alle unita' vliw
vere?


 punto, ma considerando le rogne che hanno passato, meglio ora che mai).
La sfida probabilmente sarà Opteron a 2 Ghz (in 0,13 micron) contro Itanium
2 a 1,5 Ghz (in 0,13 micron): scontro molto interessante.
Saluti.

 vere?
L'architettura Itanium è ancora giovane: ne vedremo delle belle...
Saluti.

punto, ma considerando le rogne che hanno passato, meglio ora che mai).
se muovono quel maledetto culo, che sono in ritardo di una vita....
:-\
insomma, rischiano seriamente di perdere il tram con tutti questi
ritardi, ci speravo proprio in quel gioiellino fin dai primi accenni
di Gabriele...


2 a 1,5 Ghz (in 0,13 micron): scontro molto interessante.
gia', molto interessante, bisogna vedere come scala in prestazioni
itanium con quelle megacaches...


processore, richiedendo contest-switching quando viene usato e quindi
ggghhh... contest...
sto diventando sempre piu' trascurato in questi messaggi :-\


L'architettura Itanium č ancora giovane: ne vedremo delle belle...
appena cacciano un po' di manager e marketeers con le idee poco chiare
su -cosa- sia un processore vliw di sicuro.
finalmente -dopo SETTE anni- stanno prendendo la direzione giusta,
spero proprio che i risultati ci siano.
per la cronaca, sta assomigliando sempre piu' a quello che era il
progetto HP originale, invece di quella Chimera del progetto Intel...
:-)


 dannosa.
E' fondamentale nella fase di transizione per "rassicurare" chi ha
molto codice da portare (per esperienza so che parecchio codice scritto
per Windows non e' stato scritto per essere 64bit clean, quindi anche se
magari hai i sorgenti ci devi metter mano e verificare che sia tutto OK).
Inoltre considerando la storia passata c'e' un sacco di codice "secondario"
che non verra' portato a 64bit ma che magari deve poter girare sul server
insieme al codice riscritto per i 64bit, quindi anche se non fondamentale
bisogna che il vecchio codice giri con prestazioni decenti.
Paradossalmente e' un problema che riguarda solo le applicazioni
"closed source"/commerciali alla faccia di quelli che continuano
ad affermare che il software "closed source" e' meglio supportato.
L. Micheletto

 vere?
Se si danno da fare a "semplificarlo" (senza rimuovere niente dal punto
di vista del programmatore, semplicemente rimuovendo l'hardware superfluo
passando ad emulazione/microcodice la sua implementazione e "consigliando"
ai programmatori ed a chi scrive i compilatori di non usare certe feature)
alla fine ne verra' fuori un "Alpha VLIW". :-) :-) :-)
L. Micheletto

 ad affermare che il software "closed source" e' meglio supportato.
Il problema dell'open source è che in pratica non permette nessuna
protezione del copyright.
Saluti.

 protezione del copyright.
Non e' un problema, anche perche buona parte del software con
licenza open source e' "copyleft". :-)
Se il software open source e' sufficientemente complesso, il copyright
non serve, basta il copyleft a proteggerti da quelli che cercano di
"chiuderlo" per il loro tornaconto personale.
Per modificare un software molto complesso serve gente che ne comprenda
bene la struttura e molta documentazione (e quella non sei obbligato
a renderla pubblica, eccetto le istruzioni minime per compilare
correttamente i sorgenti non modificati che rilasci).
Le modifiche servono sempre (per introdurre nuove feature oppure
per correggere bachi) e quindi se uno vende a *prezzo equo*
gli eseguibili precompilati ha il suo bel ritorno economico, come pure
succede per chi campa con i contratti di assistenza e manutenzione.
L. Micheletto

di Gabriele...
Se perdono il "treno" di Natale con Nforce3 + Athlon 64 (da 2.0Ghz
spero), sono cavoli amari.
Devono riuscire ad anticipare il Prescott e fare soldi in quel
periodo.
Un'altra nota: secondo te, usciranno veramente con Athlon 64 con L2
ridotta a 512Kb nel mercato desktop, quando Intel in quel periodo
dovrebbe lanciare il Prescott con 1Mb di L2?

 ha scritto nel messaggio
news:3eaece9d...@News.CIS.DFN.DE...

Non si sa mai, ma in teoria Prescott e Athlon 64 dovrebbero uscire quasi in
contemporanea. Le prestazioni dovrebbero essere simili, salvo stravolgimenti
dell'ultima ora. Superare i 2 Ghz in 0,13 micron per un microprocessore
"grosso" come il K8 è veramente dura, anche con il SOI. Comunque, non si sa
mai... Per quanto riguarda la cache, l'Athlon 64 sarà costruito in 0,13
micron, mentre Prescott in 90nm, cosa questa che facilita Prescott
nell'adozione di una cache più ampia.
Saluti.

"grosso" come il K8 è veramente dura, anche con il SOI. Comunque, non si sa
se effettivamente esiste il nuovo stepping di opteron a 1.45v una
versione con 512kb di L2 dovrebbe scalare molto meglio in frequenza,
direi che fino a 2.4-2.5ghz ce la faccia.
altrimenti i 2ghz sono piu' o meno il limite, forse arriva a  2.2 ma
bisogna vedere...


 nell'adozione di una cache più ampia.
In realta il K8 non e' poi cosi "grosso" come cpu (AMD ha dichiarato un 10%
di area in piu rispetto al K7 per implementare la cpu vera e propria).
In teoria se gli Athlon64 venissero realizzato con un layout "tutto loro"
dovrebbe risultarne qualcosa di molto simile ad un "K7 a 64bit ma piu veloce
di clock" grazie alla rimozione di tutta la roba che non e' prevista
sugli Athlon64, ovvero memory controller "ridotto a 64bit", si toglie un link
cHT, si semplifica il crossbar switch tra core, ram, bus hT 16bit e bus cHT
ed infine si riduce la cache a 256KB ...  512KB magari riducendone
ulteriormente la latenza.
Il problema e' semmai: *ora* ne vale la pena ?
[ipotesi ON]
Con i P4 con FSB ad 800Mhz di data rate ed i chipset con il supporto
per il doppio bus DDR SDRAM; con pure il Prescott in arrivo, forse non e' il
caso di proporre i K8 con 2 socket diversi e perdere soldi e tempo a
diversificarli troppo.
AMD potrebbe decidere di tenere un unico socket (quello degli Opteron)
e semplicemente di lasciare "non connessi"/"disattivati" i pin dei bus cHT
non utilizzati.
In questo modo potrebbe concentrarsi su un unico design (Opteron) realizzato
ad hoc con tagli di cache L2 diversi oppure con "un progetto base" con cache
L2 da 1MByte "divisa in sezioni", in modo da isolare le sezioni difettose e
vendere come Athlon64 degli Opteron con "solo" 256/512/768KB di cache L2
operativa.
Considerando che la cache da 1MByte occupa circa meta del chip, se venisse
realizzata in sezioni "sganciabili" dovrebbe essere possibile
recuperare un bel po di chip difettosi (meno del 50% di quelli difettosi, ma
fin che non aumentano le rese potrebbe essere un buon affare per AMD).
[ipotesi OFF]
L. Micheletto


Saluti.

bisogna vedere...
Con 1Mb credo che non andrà sopra i 2.0 Ghz a 0.13 (chissà, 2.2Ghz).
Ma con 512Kb potrebbe essere un po' più facile salire.
Il problema è che un Opteron da 1.6Ghz, in applicazioni workstation, è
più o meno al livello di un P4 3.0C. L'ambito server è un'altro
discorso.
Imho, un Athlon 64 con 512Kb da 2.0-2.2 Ghz (che è quello che Amd
schiererà nel mercato consumer, per poi salire ai 2.5Ghz poco prima
del lancio degli 0.09 SOI ad aprile 2004, se va' bene) potrebbe avere
difficoltà a stare dietro ad un Prescott da 3.6-3.8 Ghz a 1.1-1.2 V
(sono le frequenze di lancio previste, per scalare fino a 4-4.5 Ghz)
con 16K di L1, 1Mb di L2, ed i miglioramenti sull'HT (da non
sottovalutare in applicazioni workstation).
A quel punto Amd tornebbe a "giocarsela" praticando nuovamente prezzi
più aggressivi, cosa di cui ha tutt'altro bisogno.
Inoltre: "Vi siete chiesti perchè il Prescott uscirà con quel nuovo
socket con MOLTI più contatti (invece dei soliti piedini)?
Imho, Intel sta lavorando ad un memory controller integrato,
compatibile col prossimo bus 3GIO (o come diavolo si chiama).
Solo che non lo stanno sbandierando. 
Sarebbe un colpaccio incredibile che azzererebbe d'un colpo il grosso
del vantaggio di IPC di cui dispone il core K8 (con i clock di cui
dispone il core P4, le latenze sarebbero mostruosamente basse).

L. Micheletto
Un po l'idea dei Thorton (dei Barton con metà L2 disattivata, da
inserire nel mercato low-end)) al fine di aver un'unica linea di
produzione (finalmente a Taiwan da UMC?).
La tua ipotesi è realistica, specie considerando che Amd sarà di nuovo
costretta ad una guerra di prezzi.
Avere un'unico socket, con gli stessi chipset, è un grosso vantaggio,
specie considerando la tendenza degli ultimi anni, di un forte
avvicinamente del mercato desktop e workstation - server low-middle.
Guardando meglio l'ingrandimento del core dell'Opteron, effettivamente
la cache L2, che occupa la metà del core, sembra proprio divisa in 4
settori.

 dispone il core P4, le latenze sarebbero mostruosamente basse).
Vedremo. Io vedo una situazione di parità, forse voluta da entrambi i
contendenti.
Saluti.

 velocità in modalità 64 bit.
Non e' quella gran differenza che sembra a prima vista.
Hai escluso dal conto il memory controller a doppio canale DDR, il bus HT a
16bit, i bus cHT (1 o due in base al modello) ed il crossbar switch
(lo "snodo" tra i vari controller e la cpu che permette di sfruttarle al
  meglio), quella li e' tutta roba che sui K7 va in gran parte su un
Northbridge esterno tipo quello dei chipset NForce2.
Inoltre la cache L2 degli K8 e' implementata in modo diverso rispetto ai K7
(se non altro perche deve operare con indirizzi fisici a 40bit ed essere
  piu efficiente).
Quando si realizzano dei circuiti integrati bisogna scegliere con cura il
punto di equilibrio tra "densita" e "velocita/banda di I/O massima"
(non sono i termini esatti, ma spero che rendano l'idea).
Penso che sui K8 abbiano puntato piu su banda di I/O e velocita;
anche perche potendo iniziare con tecnologia 0.13 micron in SOI
e con la prospettiva di passare ai 90 nanometri nel 2004, potevano
permettersi di "stare larghi" rispetto alla tecnologia con
sono stati realizzati i primi K7.
Sui K8, 1Mbyte di L2 occupa circa 95 mm^2 , ovvero circa 47 mm^2 per 512KB
( occupa un area circa il 30% piu ampia rispetto alla cache L2 dei K7).
L. Micheletto

bisogna vedere...
Beh, se un Opteron a 2.0GHz tiene veramente 1.45v, un A64, con un bel
po' di transistor in meno e magari vcore a 1.55v potrebbe tenere i
2.2-2.4 senza enormi problemi... 
-- 
ZHELGADIS THE LIGHTBRINGER (ICQ 33134824)
BAG #008,DPPSJ #000,BAT #013,TFC #012, GAMERDA #026
"Aspettare non č mai stato un problema, per me.
Posso trascorrere piacevolmente ore e ore con l'aiuto di un buon caffč"

di almeno 3 Ghz) potrà tenere testa a Prescott (anche a 4,5Ghz).
Il problema sono i tempi: Intel continua ad avere un vantaggio su Amd
nel processo produttivo. Imho, Intel passerà agli 0.09 almeno 6 mesi
prima di Amd. E' tutto lì il problema.

prima di Amd. E' tutto lģ il problema.
E poi, bisognerą vedere la bontą dei processi produttivi...
In effetti sarei curioso di vedere quanti MHz saprebbe tirar fuori
Intel dal K7, con le sue fabs, magari a paritą di processo forse
l'Athlon potrebbe essere ancora davanti al P4, nonostante l'etą ;)


Dresda non è inferiore alle fabbriche di Intel.
il processo produttivo in .13 di intel e' tanto superiore a quello amd
quanto quello amd in .18 lo era da quello intel...
purtroppo nel passaggio in .13 amd ha preso dei tonfi terribili, deve
essere andato qualcosa terribilmente storto, probabilmente  pensavano
fin dal principio ad ottimizzare per il soi che pero' e' arrivato
molto piu' tardi del previsto.
speriamo che in .09 non ci siano gli stessi problemi.


 l'Athlon potrebbe essere ancora davanti al P4, nonostante l'età ;)
Molto improbabile, AMD ha pompato i K7 a colpi di layer aggiuntivi
(che aiutano ad avere scorciatoie extra per il routing delle
  connessioni tra le componenti sul chip), probabilmente usando
un processo in 0.13 come quello di Intel potrebbero guadagnare
qualcosa ma niente di impressionante.
Semmai sarebbe interessante vedere cosa potrebbero ottenere
a parita di tool di progettazione.
Dalle informazioni filtrate sul Prescott (in particolare
le immagini che mostravano il clock skew sul chip e la dissipazione)
si vede che hanno fatto qualcosa di fenomenale riguardo l'ottimizzazione
del layout.
L. Micheletto

del layout.
Nel caso, in AMD rischiano parecchio, se la superiorità di processo
produttivo resta (e c'è pure lo Strained Silicon... AMD ha in mente di
implementarlo, prima o poi?) rischiano di avere un ottimo processore
che però non tiene le frequenze che gli servono per competere col
Prescott :/
-- 
ZHELGADIS THE LIGHTBRINGER (ICQ 33134824)
BAG #008,DPPSJ #000,BAT #013,TFC #012, GAMERDA #026
"Aspettare non è mai stato un problema, per me.
Posso trascorrere piacevolmente ore e ore con l'aiuto di un buon caffè"

quanto quello amd in .18 lo era da quello intel...
Beh grazie tante, AMD aveva il rame :-)
In 0.09 Intel avrà lo Strained Silicon se non sbaglio... se questo
bilancia il SOI e il divario per il resto resta invariato sono cazzi,
anche per noi :/
-- 
ZHELGADIS THE LIGHTBRINGER (ICQ 33134824)
BAG #008,DPPSJ #000,BAT #013,TFC #012, GAMERDA #026
"Aspettare non è mai stato un problema, per me.
Posso trascorrere piacevolmente ore e ore con l'aiuto di un buon caffè"

 produzione (finalmente a Taiwan da UMC?).
Ma si sa nulla di questo Thorton? E' realistica l'ipotesi che
possa avere un FSB a 266Mhz per favorire la retro compatibilita`
con le vecchie mobo?
Neppure sul sito AMD ho trovato informazioni al riguardo.

 del layout.
Hai qualche link? Thanks.
Saluti.

Gianluca wrote:

Guarda su 
www.chip-architect.com
, sugli articoli riguardanti
il Prescott vi sono le stesse immagini riportate anche
nelle anteprime fatte da Intel, basta guardare le immagini
riguardanti il clock skew ed il thermal management
per vedere ad occhio che differenza c'e'.
L. Micheletto

Neppure sul sito AMD ho trovato informazioni al riguardo.
E' stato lanciato l'Athlon XP 2800+, con core Barton, che immagino
abbia il bus a 266 visto che l'AMD 760MPX più di quello non regge...
Immagino costerà un po' caro, ma nel peggiore dei casi è comunque una
possiblità.


 Guarda su 
www.chip-architect.com
, sugli articoli riguardanti
Molto interessante. Non conoscevo l'esistenza di questo sito.
Saluti.