Newsgroup: it.comp.hardware.cpu
Titolo: IA64 vs. x86-64

L'architettura IA64 di Intel prevede un restyle completo del processore,
con un nuovo set di istruzioni. Sulla  carta l'Itanium e` un vero mostro
(anche nel  prezzo ;)): 256  registri on  die, 17 unita`  di esecuzione,
grossa cache  integrata su package,  fino a  20 istruzioni per  ciclo di
clock. La  CPU  sembra  pero`  soffrire nelle  operazioni  sugli  interi
(viene  battuta da  un Athlon  a 1GHz)  e nell'esecuzione  del codice  a
32bit. L'architettura  x86-64  di AMD  e`  invece  un ampliamento  della
tecnologia  x86: 8  registri a  64bit  in  piu`, estensione  dei  vecchi
registri a 64bit e perfetta compatibilita` con il veccho codice a 32bit.
A breve  termine, la scelta  di AMD  potrebbe rivelarsi vincente  per il
minor costo,  ma rimarrebbero comunque le  limitazioni dell'architettura
x86. L'Itanium dovrebbe fare  i conti con un  costo intrinsecamente piu`
elevato e la necessita` di riscrivere tutte le applicazioni.
In ogni caso  le due architetture dovranno scontrari con  le altre CPU a
64bit in  circolazione: Ultra Sparc, Alpha, MIPS,  ecc. In questa ottica
gli Hammer potrebbero anche avere grossi problemi, mentre l'Itanium
spinto dalle maggiori prestazioni (e dal marketing Intel) potrebbe
conquistare una fetta del mercato server...
Voi cosa ne pensate?
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
Se alla sera, dopo una strepitosa vittoria, guardandoti allo
specchio dovessi notare un secondo paio di palle, che il tuo 
cuore non si riempia d'orgoglio, perche` vuol dire che ti 
stanno inculando -- Saggio Cinese

 wrote in message
news:9udod6$2u8$1...@dreamland.darkstar.net...


 conquistare una fetta del mercato server...
Si, ma l'Hammer probabilmente verra' presentato come "un buon x86 a 64bit"
(fa girare bene le applicazioni x86 che si hanno gia e se servono
 gli spazi di indirizzamento a 64bit fornisce pure quelli).
L. Micheletto

 "vecchio" codice x86.
Intendevo proprio  questo. Gli Hammer permetteranno di  ridurre le spese
per migrare verso un sistema a 64bit.
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
Mi piace avere amici rispettabili;
Mi piace essere il peggiore della compagnia.

 avrebbero potuto metterceli.
FOrse non mi sono spiegato bene, con gli Hammer i registri XMM sono 16.
Poi rispetto al codice x86 la grande differenza che con codice a 64bit 
i 16 registri XMM sono "standard" quindi non ci sono problemi di compatibilita 
tra modelli di cpu come invece si ha con gli x86 e con le SSE (presenti 
dal PIII e dall'Althlon XP in su) e con le SSE2 (attualmente solo su P4).
Ha quindi senso usare compilatori e librerie che sfruttano gli XMM
ovunque torni utile, senza doverli relegare a librerie particolari.
Sui PowerPC con estensioni Altivec (la versione PowerPC delle MMX/SSE/SSE2)
gira una versione di Linux ricompilato in modo da usare globalmente
le estensioni Altivec e la differenza di prestazioni si nota alla grande.
Mi aspetto qualcosa di simile pure per x86-64, tanto per fare un esempio
"stupido" pensa ad una ricerca di stringa in un testo.
Con 16 registri XMM si puo usare una routine "furba" che puo
tenere una stringa lunga fino a 16x14=212 byte *tutta sui registri XMM*
e con due registri XMM su cui caricare in interleaving 
il testo da confrontare.
Sembra una cosa "stupida", ma in questo modo si DIMEZZANO gli accessi
alla memoria, quindi a parita di banda del bus rispetto
ad un x86 si riesce ad elaborare il doppio dei dati
(un +100% di prestazioni "gratis").
... e si e' parlato di una semplice ricerca di stringa, ci sono molte
altre routine "fondamentali" che possono beneficiare della presenza
dei 16 registri XMM e dei 16 GPR.
L. Micheletto

 avrebbero potuto metterceli.
Ci sono vantaggi e svantaggi nell'aggiungere registri. Immagino che
superando i 16 registri gp ci sarebbero stati più svantaggi che vantaggi.
Saluti.
--
 +------> Xelloss <-------+       in real life: Wilmer Ricciotti
 | 
wirix...@libero.it
  |    * elimina il DEMONE per rispondermi *
 |     ICQ: 3233084       |  -----------------------------------------
 |IRC: Xelloss@AzzurraNet |   No one was born to be servant or slave
 +------------------------+   Can you tell me the color of the rain?

 del codice.
Beh, questa e` la filosofia dei VLIW, alla fine.
Circa un 90% di logica e` spostata nel compilatore,
da qui la conseguenza di dover ricompilare in caso
di upgrade del core...
bye,
-- 
piergiorgio

 tenere una stringa lunga fino a 16x14=212 byte *tutta sui registri XMM*
			          ^^^^^^^^^
Lapsus, intendevo 224.
L. Micheletto


Lo so, ma mentre con Linux ricompilare un applicativo e' quasi
normale (bella cosa avere il sistema di sviluppo
praticamente di serie), con altri S.O. la cosa presenta vari ostacoli.
Anche non M$ .Net mi aspetto problemi a meno che non prevedano una modalita
"power install" che invece di una compilazione JIT esegue una vera e propria
compilazione con ottimizzazione spinta al massimo.
L. Micheletto

il testo da confrontare.
si, ok, ma non e' cosi' semplice perche' nella realta' capita spesso che
la lunghezza della stringa non e' (cosi') limitata a priori. in pratica
puoi essere costretto a gestire l'interleaving anche sui registri della
stringa. certo, il 90% delle stringhe e' sicuramente piu' corto di
216 caratteri, ma stringhe cosi' corte i processori attuali non
sono da buttare via...
poi vabbe' sotto unixware la lunghezza delle stringhe per vi (ma anche
per lex) e' limitata... (oserei dire a 256 byte).

 ricompilare.
Non so con IA-64, ma un VLIW "puro" non e` compatibile
verso il basso e questo e` uno dei maggiori problemi.
A meno di non complicare la logica, che e` proprio
quello che si vuole evitare.
Eppoi compilare non e` male.
bye,
-- 
  Piergiorgio Sartor

quello che si vuole evitare.
un decoder che spezzi le istruzioni troppo lunghe non e' immediato ma non
e' certo piu' complicato dei decoder attuali.
un po' di complicazione e' necessaria: se non vogliamo istruzioni a
lunghezza variabile allora dobbiamo rassegnarci ad avere OGNI
istruzione lunga una o due dozzine di byte. ed in ogni istruzione una
sfilza di NOP da far paura... quel che guadagni in semplicita' del
processore lo perdi sulla memoria.
del resto le idee di fisher sono state un pelino aggiornate...
e poi e' vero che non e' cosi' traumatico compilare per due macchine
diverse, ma per 10 si. ed il mercato, si sa, preferisce avere la pappa
pronta.

 pronta.
Questo e` il problema vero. Il successo degli x86 deriva
dalla spinta compatibilita` verso il basso, che ha
consentito di avere sempre gli stessi esguibili su
piattaforme diverse, ma ha anche portato ad avere, alla
fine, una CPU che, francamente, fa proprio schifo.
Se si vogliono avere i vantaggi del VLIW, bisogna
rassegnarsi a ricompilare, il che, forse, potrebbe
portare ad avere SW piu` decente.
bye,
-- 
  Piergiorgio Sartor

compilazione con ottimizzazione spinta al massimo.
Microsoft che ti fa mettere mano sui sorgenti, criptati quanto vuoi?
scherzi? ^____^
--
    (iao!!oai)                                    (ICQ: 10860566)
    //.aurizio
[WARNING!: togliete _nessuno_ per rispondere]
    Time may change me
    But I can't trace time

 scherzi? ^____^
Intendevo compilazione del codice "portabile", quello della CLI
(Common Language Infrastructure).
Per il resto sono cavoli della M$, ma per far girare *bene* il codice
CLI su un IA64 bisogna eseguire una "vera" compilazione (da codice
intermedio a codice macchina) altrimenti si rischia di sottoutilizzare
i bundle da 3*n istruzioni con conseguenti prestazioni penose.
L. Micheletto

 sono da buttare via...
Piu che altro non e' cosi semplice perche la routine di confronto
andrebbe codificata a mano (accettabile visto che si tratta di codice
delle librerie di sistema ed usato molto frequentemente), ma comunque
anche tenendo solo *la testa* da 224 byte della stringa sui registri 
il guadagno in termini di velocita non e' disprezzabile. :-)
Comunque, come avevo detto prima, era un esempio "stupido", non ho neppure
considerato un algoritmo con pre-indicizzazione (dove ad ogni byte della stringa
che siricerca, si associa pure un "offset di restart" in modo tale da saltare
i confronti inutili quando il confronto fallisce e si deve
ripartire a confrontare il testo con il primo byte della stringa).
L. Micheletto

portare ad avere SW piu` decente.
Forse il giorno in cui verra' preinstallato linux (*) su ogni pc, ma
per il momento bisogna rassegnarsi T_T
(*) o i vari *bsd, o qualsiasi os a piacere senza deus domini
dall'alto
Felice Claudio
-- 
Cosa scelgo? Intel per il marketing, AMD per le cpu
le mie esigenze per l'acquisto
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 *** Usenet.com - The #1 Usenet Newsgroup Service on The Planet! ***
 
http://www.usenet.com
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=