L'ultimo dei mohicani: Intel presenta le CPU Itanium 9700

sì però non ho capito se le cpu em64t processino i dati a 32bit con indirizzamento e registri a 64bit nei sistemi operativi 64bit oppure processino i dati a 64bit. In tal caso la differenza con la tecnologia ia64 sarebbe insignificante.

le differenze con l'architettura ia-64 sono profonde, essendo un derivato del VLIW, ovvero in cui il parallelismo è definito nella stessa istruzione mentre questa viene definita dalle cpu x86 per lo più in HW..

il compilatore acquista un peso ancora maggiore, ovviamente questa dipendenza ha come risvolto positivo la possibilità di poter stipare un maggior numero di unità esecutive...

sulla comparazione X86 e IA-64, bisognerebbe fare anche il distinguo dall'isa e l'effettiva architettura....poichè quella x86 è si CISC ma le CPU sono RISC e quindi sono caratterizzati dal fatto che queste vengono decodificate in istruzioni elementari che possono, in ZEN e architetture Intel, rifuse insieme.

in sostanza gli stessi processi svolti da una cpu ia64 e da una cpu x86-x64 hanno dinamiche differenti con prestazioni differenti. La mia impressione è che i processori em64t non siano altro che 32 bit con estensione di memoria (ossia processori 32bit che riescono ad indirizzare memoria superiore al limite dei 4GiB), ma spero si sbagliare, mentre l'itanium sia tecnologia realmente 64bit. Questa differenza se reale determinerebbe, o dovrebbe determinare una differenza di prestazioni notevole tra le due tecnologie a vantaggio dell'itanium nei sistemi operativi 64bit.

Per quanto mi riguarda spero che presto sistemi operativi 32 bit non siano più realizzati proprio per favorire tecnologia 64bit pura.

Il punto è che sono due architetture COMPLETAMENTE differenti. Proprio dalla radice.

I processori x86-64 (AMD64 o EM64T che dir si voglia) sono processori a 64 bit in tutto e per tutto. Registri, indirizzamento della memoria, cache interne, ALU, AGU, tutto quanto è dimensionato per lavorare a 64 bit.
Detto questo, gli stessi processori supportano ANCHE la vecchia ISA x86, permettendo loro di funzionare con programmi ed OS a 32 bit senza penalità.

Questo non vale per gli Itanium, che hanno un'ISA completamente diversa e non compatibile. Intel ha tentato nel tempo di offrire retrocompatibilità verso il mondo x86, in particolare
- Merced, la prima incarnazione del progetto, emulava il tutto in HW. Con il risultato che un Itanium 800MHz (correva l'anno 2000) aveva prestazioni simili ad un P75
- McKinley, evoluzione di Merced, aveva un intero core Deshutes (il vecchio Pentium II) "annegato" nel die, per cui le istruzioni x86 venivano eseguite da silicio dedicato. Meglio, ma ancora lontani dall'ideale, visto che all'epoca i K7 viaggiavano ben oltre il GHz
- Evoluzioni successive dell'architettura hanno tentato un approccio di conversione on the fly, per cui il codice x86 veniva tradotto al volo in codice IA64 ed eseguito. Non ho mai visto benchmark in merito, a quel punto il progetto Itanium era già confinato da tempo a server ultra high end.

Pure parlando di codice nativo, tirare fuori prestazioni dagli Itanium non era banale. L'architettura VLIW richiede che ad ogni ciclo di clock le pipeline vengano riempite con 3-4 istruzioni nuove ed indipendenti, altrimenti tocca inserire delle NOP con una perdita di prestazioni conseguente enorme. Questo problema si può miticare complicando enormemente il compilatore, ma in ogni caso non tutto il codice può essere parallelizzato in questo modo, per cui spremere quel chip è sempre stata un'impresa (e si pone un altro problema: se il processore nuovo aumenta il parallelismo devi creare un compilatore dedicato E ricompilare tutto quanto, altrimenti se va bene non guadagni nulla, altrimenti perdi in prestazioni!).

In tutto questo, il progetto per Intel è stato sostanzialmente un fiasco. Doveva rimpiazzare x86 nel mondo desktop, solo che costava un botto, aveva dei consumi atroci anche per l'epoca e non dava prestazioni soddisfacenti con la base di codice esistente.

Probabilmente Intel ci sarebbe riuscita lo stesso, se AMD non avesse rotto le uova nel paniere. Il lancio dell'Athlon aveva costretto Intel a rincorrere sul fronte x86, amplificando il problema (il Pentium 4 doveva uscire ben dopo, proprio per evitare concorrenza interna. Averlo lanciato un buon anno prima del previsto ha pesato su un altro prodotto che non è andato esattamente "secondo i piani" per Intel). Quando poi AMD ha presentato una propria estensione a 64 bit che non prevedeva tutti le complicazioni di IA64, non c'è più stato mercato, semplicemente.

esattamente.
la differenza come dicevo che la CPU x86 deve provvedere da sé ad eseguire contemporaneamente più istruzioni, mentre nell'IA64 questo compito è svolto in parte già dalle VLIW. Un ISA profondamente diversa che ha inevitabili conseguenze sull'implementazione HW.


i registri GP delle cpu em64t sono a 64bit come per l'itanium..

Link ad immagine (click per visualizzarla)
sulla sinistra i registri General purpose, quelli nell'isa x86-64 sono più ampi e in numero doppio...quando viene eseguito codice a 32 bit vengono usati solo i registri bianchi...

sotto i registri dell'itanium...
Link ad immagine (click per visualizzarla)
noti qualche differenza?

"Il punto è che sono due architetture COMPLETAMENTE differenti. Proprio dalla radice."

Avevo già provato a dirlo all'inizio, sperando di essere stato chiaro.
Finalmente c'è stato qualcuno che lo ha ribadito ulteriormente.

Una cosa sono i registri a 64 bit di cui tutte le cpu a 64 bit sono dotati, un'altra cosa sono le istruzioni macchina che sono in grado di comprendere ed eseguire per operare sui registri.
Le istruzioni macchina sono definite dalla ISA (instruction set architecture) e tra Itanium e x86-64 sono diverse ed incompatibili.

Il dato è il dato, composto da una sequenza di bit, inserito in un registro che è la più elementare tra le gerarchie di memoria, che deve essere elaborato mediante istruzioni macchine... diverse a seconda delle architetture di processore.

Questo basilare concetto inutile dirlo vale per ogni forma e tipo di calcolatore digitale, che sia SPARC, PA-RISC, SuperH, MIPS

cmq sia probabile che il passaggio futuribile ad isa solo 64bit avvenga quando le cpu da desktop siano non dico un ricordo ma quasi
anche per questo facevo quella nota 'ironica' di prima (ps poi magari già è così lato mobile, so nulla )

btw qualche distro sta dismettendo i pacchetti 32bit, ma più per scarsità di mantainer che per spinta volontaria, o meglio un pò e un pò penso

Francamente non credo cambi chissà cosa, quindi non vedo l'utilità di dismettere il supporto ai 32 bit.
Il problema fondamentale delle architetture a 64bit è quello di manipolare un massimo di 64bit di dati per volta oltre alla capacità di indirizzare (teoricamente) indirizzi di memoria lunghi 64bit... il che vuol dire quantità astronomiche di ram.
Che poi per i registri passino dati a 16, a 32 o a 64 bit, a meno che non debbano essere studiati onerosi sistemi di padding, non vedo particolari problemi nell'elaborazione che continua a funzionare come coi dati più lunghi.
E' ovvio che questi sono discorsi estremamente semplicistici e generalistici...visti i casini che chi progetta calcolatori deve poter gestire.

Ricordiamoci che le vere prerogative che riguardano le CPU per i mercati server, solo un tempo riguardavano la potenza bruta e la capacità di gestire parecchia RAM.
Oggi dal punto di vista delle prestazioni, le architetture desktop sono perfettamente in grado di competere con qualsivoglia architettura concorrente presente nel mercato enterprise, CISC, RISC o VLIW che sia.

Sono le peculiarità accessorie il problema sia lato CPU (ad esempio la capacità di integrare in hardware sistemi per l'accelerazione crittografica o maggiori quantitativi di cache) sia lato piattaforma (ad esempio la possibilità di gestire motherboard capaci di ridondare la RAM e di autoescluderla a caldo).

il cambio di roadmap è stato annunciato da Intel...è ufficiale.