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

molto interessante questo argomento, grazie delle repliche.

Quindi deduco che em64t abbia reso inutile la tecnologia itanium nonostante le differenze architetturali (in sostanza em64t non è altro che un processore ibrido: un processore 64bit che esclude funzionalità quando un sistema operativo 32bit o programmi a 32 bit sono utilizzati mutando in 32bit); siccome il processore deve adeguarsi ai processi 32bit non può supportare gli standard itanium che comportano l'incompatibilità con il 32bit (causa VLIW ed altro di cui intendo documentarmi per questioni di curiosità conoscitiva solo per cercare di intuirne i concetti).

l'inutilità dell'architettura IA-64 è probabilmente dovuta alle prestazioni, più che ai 64 bit presenti anche nelle architetture x86-64... AMD restando in argomento di nuove ISA, ha progettato k12, architettura ARM nonostante abbia già una architettura a 64 bit con prestazioni adeguate (ZEN)

Grosso modo è così.
Considera anche che come ha detto qualcuno, i processori Itanium hanno esordito con prestazioni non eccezionali sul codice nativo e con prestazioni completamente deludenti su codice classico x86.
Quindi non vi è stato, per motivi non difficili da intuire, una così calorosa accoglienza da parte del mercato.
L'architettura x86-64 ne ha dato la mazzata finale in quanto ha costituito una vera e propria testa di ponte tra la stranota piattaforma di intel e il mondo dei server che da decenni necessita di architetture a 64 bit (essenzialmente per via della ram).
Quindi ora si assiste essenzialmente ad un fenomeno peraltro piuttosto prevedibile: da un lato vi è il popolamento di datacenter con macchine x86-64 per la stragrande maggioranza delle applicazioni (web-server, backend ecc)... dall'altro lato continua ad esistere una fetta di soluzioni dotate di architetture diverse (praticamente oggi rimane solo Fujitsu con SPARC) per le applicazioni considerate più mission critical, tipo i database Oracle.
Infatti oltre a caratteristiche peculiari delle PIATTAFORME delle soluzioni proprietarie enterprise, è tutt'ora considerata maggiormente sicura una architettura meno diffusa. Molti exploit scovati dagli hacker si basano su tare a livello hardware ed x86-64 con la diffusione che ha è, nostro malgrado, l'architettura maggiormente conosciuta e quindi più bersagliata.
Sparc invece, essendo presente in pochi e selezionati contesti non è stata sufficientemente "smontata" e quindi è statisticamente meno prona ad attacchi di successo.

interessante, sono curioso di capire come evolverà l'hardware quando il software 64bit subentrerà completamente.

Nel prossimo futuro, credo si orienterà sempre di più sull'incremento del numero dei core fisici che sull'integrazione di un sempre maggior numero di componenti via via più potenti. Il futuro credo che sarà sempre più SoC. Non vi è necessità di incrementare la dimensione dei registri né di incrementare più di tanto la potenza elaborativa in termini di frequenza.

btw c'entra solo in modo infinitesimale... dato che la parte smart della tv è meglio tenerla offline ormai, sto vedendo per uno scatolotto android. sticaz che specifiche che hanno i soc che montano, a due sghei... non seguivo da un bel pò...

L'hardware evolverà esattamente allo stesso modo.
I 64 bit si sono resi necessari perché i 4GB di spazio di indirizzamento non erano più sufficienti. Hanno il beneficio di velocizzare le operazioni su interi a 64 bit (ma anche l'effetto collaterale di richiedere più cache, visto che tutti i puntatori raddoppiano di dimensione). Ma in sè non sono i 32 o 64 bit a dettare lo sviluppo delle CPU.

non solo velocizzano le operazioni su interi a 64 bit, possono velocizzare proprio alcune operazioni su sequenze lunghe dato che incamerano più bit alla volta (scusa la spiegazione semplicistica)

La fine del Mondo...

E' in arrivo la fine del Mondo, lo sento!

Apple che si degna di rifare quel pachiderma di iTunes appositamente per il Win Store... HWUpgrade che scrive finalmente un articolo di informatica seria (con annessa bellissima discussione tra i commenti, che mi fa ritornare in mente i bei tempi dell'Università, quando studiavo l'architettura base dei processori CISC e RISC... ovvero due anni fa)...


Troppo bello tutto questo... sogno o son desto?

piccola e doverosa (e spero gradita) precisazione.
Non è affatto vero che i 64 bit hanno come effetto collaterale quello di richiedere più cache dovuti a puntatori, visto che per la maggior parte del tempo l'indirizzamento della memoria è descritto come piazzamento con un numero ridotto di bit, non in termini assoluti.
L'ISA x86, che ha un set molto ricco di istruzione (da far girare la testa) ha istruzioni di Jump con indirizzamento relativo a 8- 16- 32 bit....solo in rarissimi casi si usano quelli assoluti.

L'effetto negativo di una architettura a 64 bit è che questa richiede un numero molto più elevato di transistor all'interno del core, con le ovvie ripercursione negative sui consumi...(consumi che si porterà dietro anche con codice a 32 bit sia chiaro)


La maggior velocità nell'esecuzione del codice a 64bit, è dovuta alla presenza dei registri extra che non possono essere utilizzati con codice x86-32, per motivi di compatibilità.
Per chi fosse a digiuno di Assembly, questo è dovuto al fatto che le istruzioni macchina specificano chiaramente il nome del registro in cui dovrà essere caricato il dato (a livello nominale, in realtà c'è un meccanismo di re-naming che permette entro certi limiti di superare il limite che un istruzione fin dal principio deve specificare in quale esatto registro fisico operare).

I registri general purpose, visibili al programmatore e al compilatore, sono diventati 16, dopo un attenta analisi interna fatta da AMD.
la scelta di 16 registri ha permesso di aumentare le prestazioni del 25% rispetto a 8 registri (usati nelle architetture x86 tradizionali), e con una perdita di soli 3 punti percentuali rispetto a 32 registri.
Scelta che ripeto è stata resa possibile dal fatto che non c'era nessuna compatibilità da mantenere con codice a 64 bit.

PS pensavo di scrivere meno