ally
08-09-2004, 17:38
...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...
View Full Version : ...due parole sull'itanium...
Mauro82
08-09-2004, 17:59
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 (http://www.lithium.it)
in pratica credo che i punti deboli di uno siano i punti forti dell'altro, che quindi non vengono sfruttati appieno
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 (http://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
08-09-2004, 19:37
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...
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
09-09-2004, 03:36
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 (http://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...
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 (http://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
09-09-2004, 13:27
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... :D
Davide.
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... :D
Davide.
ally
09-09-2004, 19:33
...troppo gentili ;)
ally
09-09-2004, 19:40
...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
09-09-2004, 20:16
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.
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
09-09-2004, 21:10
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.
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
09-09-2004, 21:31
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
09-09-2004, 22:57
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 ;)
...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
09-09-2004, 23:10
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...)
Il problema è avere tutto il resto (dal S.O. che gestica tutto ai driver... ecc... tutti da rifare...)
cdimauro
11-09-2004, 07:33
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.
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
11-09-2004, 07:36
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...
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
11-09-2004, 07:39
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...
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
11-09-2004, 07:42
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...
...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
11-09-2004, 07:46
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...
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
11-09-2004, 10:12
infatti la cara intel continua a metterci le pezze , bus carente? l2 e l3 in quantità industriali!
cdimauro
12-09-2004, 05:31
Infatti. Processori con un'architettura "bellissima" e "ultraperformante", ma che hanno bisogno di tonnellate di cache per lavorare decentemente, debbo ancora vederne... :asd:
Goldrake_xyz
12-09-2004, 21:31
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
:muro:
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
:muro:
repne scasb
12-09-2004, 22:19
cdimauro
13-09-2004, 06:04
Originariamente inviato da Goldrake_xyz
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
:muro:
"Il sonno della ragione genera mostri" :rolleyes:
Non è la prima volta che dimostri la tua ignoranza in materia: evita, per questioni di dignità personale, di incazzarti pure, se qualcuno ti fa notare le assurdità che scrivi. :rolleyes: :muro: :mc:
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
:muro:
"Il sonno della ragione genera mostri" :rolleyes:
Non è la prima volta che dimostri la tua ignoranza in materia: evita, per questioni di dignità personale, di incazzarti pure, se qualcuno ti fa notare le assurdità che scrivi. :rolleyes: :muro: :mc:
Goldrake_xyz
16-09-2004, 20:11
OK .. :D prima rispondo a ...
repne scasb
Le idee confuse le abbiamo un pò tutti ... :Prrr:
P4 ... se vuoi usare anche lo stack index x fare i conti .. fà come ti pare ! :D
ITANIUM :
R0..R127 = 128 Registri per INTERI a 64 Bit general purpose
F0..F127 = 128 Registri per FLOAT a 82 Bit
Comunque resta il fatto che i registri del P4 sono pochi !
e mò ...
cdimauro
uhm dottore in che ... :wtf:
chirurgico ?... che opera dei poveri pazienti indifesi ... :rolleyes:
Scherzo ! , comunque se tu mi dai dell' ignorante in materia
non posso che rallegrarmi di questo ! :asd:
To be continued ....
repne scasb
Le idee confuse le abbiamo un pò tutti ... :Prrr:
P4 ... se vuoi usare anche lo stack index x fare i conti .. fà come ti pare ! :D
ITANIUM :
R0..R127 = 128 Registri per INTERI a 64 Bit general purpose
F0..F127 = 128 Registri per FLOAT a 82 Bit
Comunque resta il fatto che i registri del P4 sono pochi !
e mò ...
cdimauro
uhm dottore in che ... :wtf:
chirurgico ?... che opera dei poveri pazienti indifesi ... :rolleyes:
Scherzo ! , comunque se tu mi dai dell' ignorante in materia
non posso che rallegrarmi di questo ! :asd:
To be continued ....
Luc@s
17-09-2004, 13:34
up
cdimauro
18-09-2004, 21:38
Originariamente inviato da Goldrake_xyz
Le idee confuse le abbiamo un pò tutti ... :Prrr:
Permetti di dubitarne...
P4 ... se vuoi usare anche lo stack index x fare i conti .. fà come ti pare ! :D
E perché no? Se tu non sai usarlo, non vuol dire che gli altri non lo sappiano fare... :rolleyes: Col 68000 dell'Amiga mi è capitato di utilizzarlo per trasferire dati, o di usarlo come un qualunque registro...
ITANIUM :
R0..R127 = 128 Registri per INTERI a 64 Bit general purpose
F0..F127 = 128 Registri per FLOAT a 82 Bit
Bravo, sei andato a documentarti. Ma mancano i 64 registri di predizione all'appello... :D
Comunque resta il fatto che i registri del P4 sono pochi !
Resta il fatto che hai poca esperienza nel campo della programmazione, e non sai se, come e quanti registri servono per delle particolari applicazioni.
Per inciso, esistono studi in materia che hanno analizzato questo problema: con 8 registri general purpose si copre buona parte delle applicazioni software, con 16 la stragrande maggioranza, con 32 una piccolissima percentuale, e oltre i 32 si possono contare.
Le tue osservazioni da cosa derivano, invece? Dalla fantasia?
uhm dottore in che ... :wtf:
chirurgico ?... che opera dei poveri pazienti indifesi ... :rolleyes:
Azzecato. Se vuoi domani ho un posto libero per un intervento di lobotomia: perché non ne approfitti? :asd:
Scherzo ! , comunque se tu mi dai dell' ignorante in materia non posso che rallegrarmi di questo ! :asd:
E lo scherzo continua, vero? :rolleyes:
To be continued ....
Sei masochista? Per me non c'è problema: esco il gattone a nove code... :asd:
Le idee confuse le abbiamo un pò tutti ... :Prrr:
Permetti di dubitarne...
P4 ... se vuoi usare anche lo stack index x fare i conti .. fà come ti pare ! :D
E perché no? Se tu non sai usarlo, non vuol dire che gli altri non lo sappiano fare... :rolleyes: Col 68000 dell'Amiga mi è capitato di utilizzarlo per trasferire dati, o di usarlo come un qualunque registro...
ITANIUM :
R0..R127 = 128 Registri per INTERI a 64 Bit general purpose
F0..F127 = 128 Registri per FLOAT a 82 Bit
Bravo, sei andato a documentarti. Ma mancano i 64 registri di predizione all'appello... :D
Comunque resta il fatto che i registri del P4 sono pochi !
Resta il fatto che hai poca esperienza nel campo della programmazione, e non sai se, come e quanti registri servono per delle particolari applicazioni.
Per inciso, esistono studi in materia che hanno analizzato questo problema: con 8 registri general purpose si copre buona parte delle applicazioni software, con 16 la stragrande maggioranza, con 32 una piccolissima percentuale, e oltre i 32 si possono contare.
Le tue osservazioni da cosa derivano, invece? Dalla fantasia?
uhm dottore in che ... :wtf:
chirurgico ?... che opera dei poveri pazienti indifesi ... :rolleyes:
Azzecato. Se vuoi domani ho un posto libero per un intervento di lobotomia: perché non ne approfitti? :asd:
Scherzo ! , comunque se tu mi dai dell' ignorante in materia non posso che rallegrarmi di questo ! :asd:
E lo scherzo continua, vero? :rolleyes:
To be continued ....
Sei masochista? Per me non c'è problema: esco il gattone a nove code... :asd:
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.