...due parole sull'itanium...

[ally]

...volevo fare due chiacchere con quulache esperto per sapere qual'è il cruccio che nn permette a tale procio di avere prestazioni decenti nell'emulazione di software a 32 bit...

[Mauro82]

a parte l'ovvio (le emulazioni portano a un degrado di prestazioni), penso che sia perchè le istruzioni x86 sono poco parallelizzabili, mentre Itanium prevede un approccio chiamato EPIC (Explicitly Parallel Instruction Computing)

L'esecuzione parallela delle istruzioni è fortemente ostacolata da salti e chiamate a subroutine, a causa della natura stessa delle unità di calcolo, organizzate secondo una struttura a pipeline.

In questo tipo di struttura le istruzioni sono eseguite in più passi, proprio come in una catena di montaggio costituita da più stadi di lavorazione successiva. La pipeline ha il vantaggio di permettere l'esecuzione di più istruzioni, proprio come una catena di montaggio riesce a montare più automobili perché divide il lavoro in più fasi, ciascuna eseguita contemporaneamente all'altra su istruzioni diverse.

Se si pensa alla pipeline come ad una conduttura in cui le istruzioni transitano una dietro l'altra, appare evidente che la catena di montaggio lavorerà a pieno regime fino a che il flusso di istruzioni rimane sequenziale. In presenza di un salto o di una chiamata a subroutine, tutte le istruzioni parzialmente eseguite presenti nella catena di montaggio devono essere annullate e la conduttura riempita di nuovo. Si parla quindi di impredicibilità dei salti perché fino a che l'istruzione di salto non viene completata dall'ultimo stadio della catena di montaggio, non è noto quale sarà l'istruzione successiva e quindi non è possibile caricare nella conduttura la giusta sequenza di istruzioni.

I processori a 32 bit tentano di risolvere questo problema attraverso degli algoritmi di predizione di salti, che cercano appunto di predire quale sarà il flusso di esecuzione, in modo da bloccare il meno possibile la pipeline. Per ovvie ragioni questi algoritmi sono implementati direttamente nel chip e operano in modo trasparente al codice, ma proprio per questi motivi occupano una parte non trascurabile del chip e realizzano una predizione molto rozza.

In caso di predizione errata la catena di montaggio viene bloccata per essere svuotata e caricata di nuovo con la giusta sequenza di istruzioni. Il tempo in cui rimane bloccata è direttamente proporzionale al numero di stadi che la compongono, per cui occorre un algoritmo tanto più efficiente tanto più la pipeline è lunga. Nei processori a 32 bit la necessità di innalzare la frequenza di clock ha portato ad un progressivo allungamento delle pipeline interne (dai 5stadi del Pentium, ai 10 del Pentium II/III fino ai 20 del nuovo Pentium IV), con il risultato collaterale di rendere sempre più critici gli algoritmi di previsione (sono necessarie meno predizioni errate) e sempre maggiori le penalità in caso di predizione errata.

Nell' architettura IA-64 si è cercato di risolvere questo problema all'origine, rendendo in pratica predicibili la maggior parte dei salti grazie all'introduzione dei così detti predicati. Si tratta di vere e proprie variabili booleane (flag) implementate direttamente nel processore, il cui valore dipende dal risultato di una istruzione da noi scelta (qualcosa di molto simile al vetusto Zero Flag, ma molto più generale). Un processore IA-64 può essere programmato in modo da condizionare l'esecuzione di un'istruzione con il valore di uno dei predicati (predicative execution), senza l'aggiunta di codice addizionale. In altre parole il nuovo set di istruzioni permette di inserire direttamente all'interno dell'istruzione il predicato che dirà se al termine della pipeline l'istruzione deve essere tenuta o scartata.

spero di non aver detto troppe cazzate

comunque prova a cercare nei meandri di www.lithium.it

in pratica credo che i punti deboli di uno siano i punti forti dell'altro, che quindi non vengono sfruttati appieno

[Berno]

Bè, non me ne intendo molto dell'architettura dei processori ma penso che l'esecuzione di istruzioni x86-32 da parte degli itanium sia una specie di optional, una cosa in più messa lì solo per avere un minimo di compatibilità con questo tipo di applicazioni...

Probabilmente se ci avessero lavorato su seriamente l'emulazione funzionerebbe molto meglio ma nei sistemi in cui è impiegato l'itanium questa funzione non è particolarmente importante perchè tutto il software importante è appositamente ricompilato...

Tutto questo ovviamente imho...

[cdimauro]

Originariamente inviato da Mauro82
a parte l'ovvio (le emulazioni portano a un degrado di prestazioni), penso che sia perchè le istruzioni x86 sono poco parallelizzabili, mentre Itanium prevede un approccio chiamato EPIC (Explicitly Parallel Instruction Computing)


spero di non aver detto troppe cazzate

comunque prova a cercare nei meandri di www.lithium.it

in pratica credo che i punti deboli di uno siano i punti forti dell'altro, che quindi non vengono sfruttati appieno

Non sono le istruzioni x86 a essere poco parallelizzabili: è il codice intrisecamente ad esserlo, anche se dipende ovviamento dal tipo di codice...

[xpiuma]

Il discosro Itanium è un pò complesso... Cercherò di spiegare qualcosa senza ne essere troopo tecnico ne troppo scarno di particolari.

Allora: Nei processori normali (x86-32) la sequenza di istruzioni che arriva al processore entra in un buffer, ed in base alle risosre disponibili le istruzioni vengono lanciate (issue) su una pipeline libera.
Più istruzioni possono essere lanciate in parallelo, e visto che la latenza di completamento è diversa le istruzioni possono essere completate fuori ordine.
Questo è un problema, ovviamente le istruzioni devono essere completate nella corretta sequenza, o almeno comunicate al di fuori dal core nel giusto ordine. Tutto questo è compito di una parte del procio, il reorder buffer; il lancio di più istruzioni in parallelo è necessario per aumentare le prestazioni, poi ci pensa il reorder a rimetterle a posto.

Nei processori Itanium le cose funzionano in maniera completamente diversa; le istruzioni non arrivano al processore nell'ordine del programma... Già in fase di compilazione dei sorgenti le istruzioni vengono "ordinate" in modo da poter essere eseguite in parallelo, senza controllare eventuali dipendenze.. ecc..
Questo rende l'esecuzione mooooolto più rapida, perchè si sfruttano tutte le risorse del processore, avendo una serie di istruzioni (4 per clock) sempre indipendenti, o almeno con dipendenze gestite dal compilatore, che ha moooolto più tempo per trovare i giusti "incastri" per ordinate le istruzioni di un programma.

Per questo motivo Itanium con x86-32 è messo così male...
Non avendo ne un reorder buffer, ne tantomento una unita di issueing delle istruzioni dinamica, non può trattare le istruzioni così come gli arrivano dal programma.
Serve una specie di compilazione a run-time per l'esecuzione nell'ordine corretto; il che lo porta ad avere prestazioni paragonabili a processori di 5-6 anni fa per quanto riguarda il codice a 32bit.

Le motivazioni che hanno spinto Intel a costruire l'Itanium sono dovute al fatto che l'architettura x86-32 è vecchia di più di vent'anni; ed è abbastanza inefficiente nella meggior parte delle applicazioni moderne... purtroppo però per mantenere la compatibilità con le applicazioni... ci si porta dietro sta architettura da sempre...

Spero di essere stato abbastanza chiaro, se volete discutere altri particolari dell'architettura VLIW (Very Long Instuction Word) quella dell'Itanium... bè ditemelo...

Davide.

[ally]

...troppo gentili

[ally]

...ma c'è la possibilità che l' x86-32 venga sostituito o è possibile continuare su questa strada?...ma qual'è il fattore che spinge a continuare su questa strada?...la sola compatibilità o anche la possibilità bene o male di mantenere le prestazioni ad un livello sufficiente?...ed un ultima cosa...l'itanium digerisce qualsiasi codice o in particolari situazioni potrebbe avere dei problemi?...nel senso...una tecnologia come la sua è pensata per particolari situazioni di calcolo o potrebbe gestire bene qualsasi tipo di software se ottimizzato?...e questa ottimizzazione sarebbe facile da gestire ed implementare?...

[xpiuma]

La X86-32 andrà avanti ancora per un bel pò... forse avremo qualche cambiamento quando tutti i proci saranno a 64 bit... ma ne dubito...
Le prestazioni dei proci ottenibili con la tecnologia attuale potrebbero essere moooolto maggiori con un'altra architettura (vedi appunto l'Itanium), quindi la x86 non si mantiene per quello.


La seconda domanda... non ho capito bene...

Se intendi se l'Itanium digerisce ogni applicativo a 32bit... bè, si... ma talvolta le prestazioni sono al livello di un 386.

[Goldrake_xyz]

dico anch'io qualcosa ...

nell x86-32 si ha solo 4 registri di uso generale ....
quindi si deve fare tutto con questi.

Viceversa l'Itanium ha 64 registri e quindi può parallelizzare
molte instruzioni, Esempio :
MOV R1,R2 e MOV R8,R11 vengono eseguite nello stesso ciclo di clock.

[checo]

appunto perchè parli di emulazione dovresti sapere che le prestazioni del codice emulato sono sempre base rispetto alla potenza impiegata, inpiù se ci metti l'architettura totalmente differente dalla x86 hai quei risulatati

[ally]

Originariamente inviato da xpiuma
...la seconda domanda... non ho capito bene...

Se intendi se l'Itanium digerisce ogni applicativo a 32bit... bè, si... ma talvolta le prestazioni sono al livello di un 386.

...scusa mi sono espresso maluccio...volevo sapere se un procio del genere digerirebbe senza problemi il ruolo degli attuali processori x86-32 oppure è stato progettato per un utilizzo piu' specifico...si insomma se tutto fosse compilato secondo le sue esigenze potrebbe gestire il ruolo di un odierno athlon/p4 o l'uso da pc soho nn si confa alla sua struttura...forse ho già trovato risposta nelle parole di goldrake

[xpiuma]

Se i programmi venissero compilati tutti per IA64 andrebbero sicuramente come una bomba...
Il problema è avere tutto il resto (dal S.O. che gestica tutto ai driver... ecc... tutti da rifare...)

[cdimauro]

Originariamente inviato da xpiuma
Nei processori Itanium le cose funzionano in maniera completamente diversa; le istruzioni non arrivano al processore nell'ordine del programma... Già in fase di compilazione dei sorgenti le istruzioni vengono "ordinate" in modo da poter essere eseguite in parallelo, senza controllare eventuali dipendenze.. ecc..

"Ottimizzate" se il codice ti permette di farlo. E soprattutto se hai un ottimo compilatore (che comunque non ti potrà mai garantire di tirare fuori il codice più ottimizzato).

Questo rende l'esecuzione mooooolto più rapida, perchè si sfruttano tutte le risorse del processore,

No, perché quella che hai riportato è una visione statica dell'esecuzione, mentre nella realtà le cose vanno diversamente, e le risorse non sono sempre disponibili come pensa il compilatore e come vorrebbe l'architettura EPIC...

avendo una serie di istruzioni (4 per clock) sempre indipendenti,

Sono 3, al massimo.

o almeno con dipendenze gestite dal compilatore, che ha moooolto più tempo per trovare i giusti "incastri" per ordinate le istruzioni di un programma.

Hai detto bene: molto più tempo. Perché ci vuole molto tempo per tirare fuori un buon codice.

Le motivazioni che hanno spinto Intel a costruire l'Itanium sono dovute al fatto che l'architettura x86-32 è vecchia di più di vent'anni; ed è abbastanza inefficiente nella meggior parte delle applicazioni moderne...

Veramente mi sembra che goda di buona salute, e che le prestazioni siano spesso superiori anche ai processori più "rinomati"...

purtroppo però per mantenere la compatibilità con le applicazioni... ci si porta dietro sta architettura da sempre...

E qual è il problema? L'importante è che sia veloce.

[cdimauro]

Originariamente inviato da xpiuma
La X86-32 andrà avanti ancora per un bel pò... forse avremo qualche cambiamento quando tutti i proci saranno a 64 bit... ma ne dubito...

Anch'io ne dubito, specialmente con l'arrivo dei 64 bit anche negli x86...

Le prestazioni dei proci ottenibili con la tecnologia attuale potrebbero essere moooolto maggiori con un'altra architettura (vedi appunto l'Itanium), quindi la x86 non si mantiene per quello.

Sbagliato, e le prestazioni sul campo lo dimostrano. Con quelle su carta non si va molto avanti...

[cdimauro]

Originariamente inviato da Goldrake_xyz
dico anch'io qualcosa ...

nell x86-32 si ha solo 4 registri di uso generale ....
quindi si deve fare tutto con questi.

Sono 8, non 4.

Viceversa l'Itanium ha 64 registri

Sono 128, non 64.

e quindi può parallelizzare
molte instruzioni, Esempio :
MOV R1,R2 e MOV R8,R11 vengono eseguite nello stesso ciclo di clock.

Si può fare la stessa cosa anche con gli x86. Dimentichi, poi, l'esistenza dei rename register, che sopperiscono in parte alla dipendenza fra le varie istruzioni...

[cdimauro]

Originariamente inviato da ally
...scusa mi sono espresso maluccio...volevo sapere se un procio del genere digerirebbe senza problemi il ruolo degli attuali processori x86-32 oppure è stato progettato per un utilizzo piu' specifico...si insomma se tutto fosse compilato secondo le sue esigenze potrebbe gestire il ruolo di un odierno athlon/p4 o l'uso da pc soho nn si confa alla sua struttura...forse ho già trovato risposta nelle parole di goldrake

L'Itanium va bene nelle applicazioni che fanno MASSICCIO uso di dati in virgola mobile: qui è veramente imbattibile. Per il resto, lasciamo perdere: un economicissimo x86 è capace di fargli le scarpe...

[cdimauro]

Originariamente inviato da xpiuma
Se i programmi venissero compilati tutti per IA64 andrebbero sicuramente come una bomba...
Il problema è avere tutto il resto (dal S.O. che gestica tutto ai driver... ecc... tutti da rifare...)

C'è già, e ciò che dici non si verifica. Pensi che i s.o. non siano compilati appositamente per Itanium? E i driver? E le applicazioni?
E' chiaro che in emulazione x86-32 è una chiavica, ma chi compra un Itanium oggi lo fa per farci girare applicazioni nel suo ambiente naturale, ma le scarse prestazioni di questi processori, fatta eccezione per ciò che ho scritto sopra, sono davanti gli occhi di tutti...

[checo]

infatti la cara intel continua a metterci le pezze , bus carente? l2 e l3 in quantità industriali!

[cdimauro]

Infatti. Processori con un'architettura "bellissima" e "ultraperformante", ma che hanno bisogno di tonnellate di cache per lavorare decentemente, debbo ancora vederne...

[Goldrake_xyz]

Originariamente inviato da cdimauro
Sono 8, non 4.
Sono 128, non 64.
Si può fare la stessa cosa anche con gli x86. Dimentichi, poi, l'esistenza dei rename register, che sopperiscono in parte alla dipendenza fra le varie istruzioni...

x86_32 REGISTRI INTERI :
per uso generale sono 4 : EAX, EBX, ECX, EDX
per uso puntatore a memoria altri 4 : ESP,EBP,ESI,EDI
oltre ai registri di segmento, flag, ecc.
x86_32 REGISTRI FLOAT a 80 Bit
Stack ring composto da 8 registri ST(0)...ST(7)

ITANIUM2 :
64 REGISTRI x INTERI
128 REGISTRI x FLOATING POINT