Link alla notizia: https://www.hwupgrade.it/news/cpu/intel-dismette-ufficialmente-itanium-il-futuro-dell-architettura-ia-64-resta-ignoto_80511.html

Intel ha annunciato la morte della linea di processori Itanium: quelli attualmente presenti sul mercato, appartenenti alla serie Itanium 9700, saranno gli ultimi della stirpe. Futuro ignoro per l'architettura IA-64

Click sul link per visualizzare la notizia.

D'altronde qualcuno ha mai visto qualche server con questa CPU?

che flop

e anche solo a due anni dal lancio era un casino trovare alcuni programmi compatibili con la piattaforma

Da quel che ricordo Intel avrebbe tagliato i ponti con itanium anni fa, fu hp ad insistere... da wikipedia (tradotta con google):

Durante la causa di sostegno di Hewlett-Packard Co. contro Oracle Corp. del 2012, i documenti giudiziari aperti da un giudice della contea di Santa Clara hanno rivelato che nel 2008 Hewlett-Packard aveva pagato Intel circa $ 440 milioni per continuare a produrre e aggiornare i microprocessori Itanium dal 2009 a 2014. Nel 2010, le due società hanno firmato un altro accordo da $ 250 milioni, che ha obbligato Intel a continuare a produrre CPU Itanium per le macchine HP fino al 2017. Secondo i termini degli accordi, HP deve pagare i chip che ottiene da Intel, mentre Intel lancia Tukwila , Poulson, Kittson e Kittson + chip nel tentativo di aumentare gradualmente le prestazioni della piattaforma. [52] [53]

"con ben 128 registri" qualcuno mi sa spiegare con parole semplici ^_^ in che modo questi influiscono sul funzionamento di una CPU e che benefici ne trae? anche perché la differenza con l'x86 è abissale, non è che per mancanza di voglia degli sviluppatori è morta una piattaforma estremamente più performante? (mi ricorda molto, seppur siano due cose totalmente differenti, la fine fatta dai lumia… )

"con ben 128 registri" qualcuno mi sa spiegare con parole semplici ^_^ in che modo questi influiscono sul funzionamento di una CPU e che benefici ne trae? anche perché la differenza con l'x86 è abissale, non è che per mancanza di voglia degli sviluppatori è morta una piattaforma estremamente più performante? (mi ricorda molto, seppur siano due cose totalmente differenti, la fine fatta dai lumia… )

Per farla semplice: i registri sono molto, molto, molto più veloci della RAM. Parliamo di almeno due ordini di grandezza di differenza! Avere quindi più registri a disposizione rende la manipolazione dei dati più efficiente. Lo svantaggio è che la progettazione dell'hardware è molto più complessa e la produzione più costosa (i registri sono tra gli elementi più costosi nella produzione della CPU). Un ulteriore svantaggio, sebbene non direttamente correlato, sta nella progettazione del processore e nel modo in cui gestiva l'esecuzione. Gli Itanium non erano dotati di branch prediction, ovvero della capacità di "prevedere" la prossima istruzione (esempio pratico: la CPU ipotizza che la condizione di un costrutto "if" sia vera e quindi esegue in anticipo il codice seguente), e si affidavano pesantemente ai compilatori affinché svolgessero questo compito in fase di compilazione. Non sempre, però, i compilatori erano in grado di stabilire correttamente l'ordine delle istruzioni: in caso non ci riuscissero (ed accade più frequentemente di quanto si pensi...), il processore doveva andare in memoria a recuperare i dati necessari pagando un prezzo notevole in termini di tempo. Quindi avere così tanti registri, insieme al modello basato su compilatori anziché su logiche di branch prediction nella CPU, portava a rallentamenti durante l'esecuzione rispetto ai processori x86. Ho molto generalizzato e semplificato, se ti interessa la materia posso consigliarti alcuni testi specifici.

Non ne sentiremo la mancanza
Assolutamente no.
Se poi mi facessero fin da subito la possibilità di escludere in automatico su WSUS le patch per questa piattaforma sarebbe il TOP :asd:

non è che per mancanza di voglia degli sviluppatori
Non è mancanza di voglia (non lo è mai in una economia di mercato).
E' una questione di costi in rapporto al beneficio (il profitto) ipotetico che si stimava sarebbe stato ottenuto dalla riscrittura del codice.

Phantom, l'economia di mercato è un falsa leggenda - al di là del caso specifico in discussione, si basa solo sul risparmio di soldi nell'immediato e l'assenza totale di lungimiranza e/o pianificazione e prevenzione di disastri. Ti basti guardare il mondo com'è conciato…
Tornando in topic grazie Slater per le info, più o meno ho capito ^_^ mi interessava una infarinatura e capire le potenzialità dell'architettura rispetto a quella più diffusa. Tanto ormai la "storia" gli ha messo una pietra sopra, e con molta probabilità Intel preferirà dirottare le risorse sulle CPU quantistiche, che ad occhio e croce saranno il futuro in quell'ambito.

No branch prediction quindi no bachi recenti?
Prestazioni mostruosamente più elevate ma bisogna sbattersi per programmare?
Ma si'... buttiamo tutto nel cesso.

Phantom, l'economia di mercato è un falsa leggenda - al di là del caso specifico in discussione, si basa solo sul risparmio di soldi nell'immediato e l'assenza totale di lungimiranza e/o pianificazione e prevenzione di disastri. Ti basti guardare il mondo com'è conciato…
Non è una leggenda, ma una realtà con cui fare i conti, e che si basa sulla creazione di profitto che non corrisponde automaticamente a un risparmio.
Che poi la si condivida o meno è un altro paio di maniche.

[...]
Ho molto generalizzato e semplificato, se ti interessa la materia posso consigliarti alcuni testi specifici.

Ciao Slater,

Io sarei interessato a qualche testo più specifico.
Potresti indicarmene qualcuno?

Grazie,
Quartz

No branch prediction quindi no bachi recenti?
Prestazioni mostruosamente più elevate ma bisogna sbattersi per programmare?
Ma si'... buttiamo tutto nel cesso.
TEORICAMENTE più elevate, nel senso che a livello pratico poi non erano così elevate a parità di costo rispetto ai RISC ed agli x86.
Fondamentalmente gli Itanium eccellevano
nell'eseguire codice che si presta ad essere eseguito bene sulle GPU, con di fatto gli stessi problemi di sviluppo software, mentre per il resto stavano nella media quando gli andava bene.

Phantom, associare la parola economia all'attuale sistema di accumulo di denaro è un ossimoro ^_^ è semplicemente un sistema feudale che invece di aver al centro la terra da coltivare, ha appunto le varie valute, è un dato di fatto, quello che dico è che usano parole associandole a cose che non rappresentano la realtà dei fatti. L'etimologia di economia ha un'accezione positiva, per quello la usano, mentre quella feudale un pochetto meno…

peccato, paradossalmente sono stati uccisi dalle gpgpu.

Ormai un normalissimo server x86 quad socket da 80-90.000€ riesce a battere in performance anche la macchina itanium più grande che vende HPE, che ha la bellezza di 16 socket e a listino viene più di 1.000.000€.

Solo in corrente consumata in un anno vale il costo del server x86 :D

Gli Itanium non erano dotati di branch prediction, ovvero della capacità di "prevedere" la prossima istruzione [...]

Non è solo questione di branch prediction, ma soprattutto di esecuzione "in order" o "out of order". I processori con capacità di esecuzione fuori ordine, come ad esempio gran parte delle architetture x86 a partire dal Pentium Pro, possono eseguire le istruzioni in ordine differente rispetto a come compaiono nel codice, anticipando l'esecuzione di istruzioni i cui operandi siano già pronti e ritardando quella di istruzioni ancora in attesa di operandi, anche se precedenti nel flusso del codice. Questo permette di sfruttare meglio le varie unità di esecuzione della CPU diminuendo gli stalli, anche in presenza di codice non ottimizzato (non correttamente schedulato dal compilatore o dal programmatore). La previsione statistica dei salti serve invece per attuare la cosiddetta "esecuzione speculativa", che consiste nell'eseguire un flusso di istruzioni prima di conoscere l'esito del salto condizionale che deciderà se devono essere eseguite o meno (salvo poi scaricarne i risultati se la previsione era sbagliata), sempre con l'intento di sfruttare al massimo le risorse di esecuzione disponibili e l'ampiezza di banda della memoria.
Spostare il compito di schedulare le istruzioni dal compilatore alla CPU è vantaggioso nelle architetture con tante CPU molto diverse fra loro sul mercato, come nel caso della giungla x86, dove risulta impossibile ottimizzare il codice a tempo di compilazione per ogni possibile CPU, salvo fare codici differenti con ottimizzazioni diverse e selezionarli a run-time dopo aver identificato la CPU. Lo svantaggio invece è che le CPU diventano più complesse e quindi più costose a parità di prestazioni massime, dovendo sobbarcarsi una parte dei compiti del compilatore o del programmatore.
In un mondo dove il software è fatto sempre più coi piedi, si definisce "programmatore" qualsiasi ragazzino che sa pasticciare con java e il business grosso sta nel rendere obsolescente l'hardware il prima possibile per venderne altro sempre più pachidermico, ci sta che la complessità si sposti sempre più sull'hw stesso (salvo poi trovarsi con problemi come la sicurezza zero, vedi Spectre e compagnia bella).

Nel caso di Itanium, Intel adottò il paradigma "epic" di HP: in pratica il compilatore incorpora nelle istruzioni le indicazioni sia sul parallelismo di esecuzione sia sulla previsione dei salti. Il vantaggio consiste nella semplificazione della CPU e relativa riduzione del rapporto costo/prestazioni, ed era perfettamente logico in uno scenario dove non ci sarebbero state mille diverse architetture di CPU ognuna con le sue esigenze di ottimizzazione differenti.

Il motivo del fallimento di Itanium è da ricercarsi nella mancanza del supporto software e nel ritardo dello sviluppo (il progetto parte concretamente nel 1994 e non si concretizza prima del 2001), con il condimento della cattiva idea di supportare anche il codice x86 (fino al 2006) con pessime prestazioni. Poi nel 2003 AMD ha proposto l'estensione a 64 bit di x86, cosa vantaggiosissima per i produttori sw per la piena compatibilità con tutto il codice esistente (senza penalità di prestazioni), e Intel ha dovuto inseguire per non essere tagliata fuori dal mondo PC. Dopodiché x86 64 ha trovato spazio anche in ambito enterprise, fino a farci i supercomputer, e per Itanium non è rimasto molto spazio, indipendentemente dal fatto che fosse più o meno valida come architettura. La stessa Intel ha offerto le versioni enterprise "Xeon" delle sue CPU già a partire dal Pentium II, per poi proseguire anche con i 64 bit.

L'associazione con GPU computing che qualcuno ha fatto è infondata: Itanium non è un'architettura massivamente parallela, nonostante l'ampia disponibilità di registri (128 integer e 128 floating point). Ha delle limitate capacità SIMD, non più di qualunque CPU x86 dall'introduzione delle istruzioni SSE2 (anno 2000).

"con ben 128 registri" qualcuno mi sa spiegare con parole semplici ^_^ in che modo questi influiscono sul funzionamento di una CPU e che benefici ne trae? anche perché la differenza con l'x86 è abissale,
Aggiungo un dettaglio a ciò che già t'è stato scritto: i 128 registri non erano tutti direttamente indirizzabili dalle istruzioni. Lo erano soltanto 32. Itanium, però, implementava un meccanismo "a finestre" nelle chiamate a funzioni, dove i registri "scorrevano in avanti" (una parte dei registri della funzione chiamante divenivano i registri coi parametri passati alla funzione chiamata, e e quest'ultima si trovava coi "nuovi" registri a disposizione per le sue variabili locali o per passare eventualmente parametri a un'altra funzione) e "indietro" al ritorno.
E' un meccanismo utilizzato dai processori SPARC, ma l'implementazione qui era più efficiente (perché il processore aveva 128 registri direttamente a disposizione, per l'appunto, mentre SPARC doveva scaricare un po' di registri sullo stack).
Il costo è che il context-switch diventa molto più elevato, ovviamente.
non è che per mancanza di voglia degli sviluppatori è morta una piattaforma estremamente più performante? (mi ricorda molto, seppur siano due cose totalmente differenti, la fine fatta dai lumia… )
No, è morto per altre motivazioni. Ne parlo brevemente dopo.
Un ulteriore svantaggio, sebbene non direttamente correlato, sta nella progettazione del processore e nel modo in cui gestiva l'esecuzione. Gli Itanium non erano dotati di branch prediction, ovvero della capacità di "prevedere" la prossima istruzione (esempio pratico: la CPU ipotizza che la condizione di un costrutto "if" sia vera e quindi esegue in anticipo il codice seguente), e si affidavano pesantemente ai compilatori affinché svolgessero questo compito in fase di compilazione.
In realtà Itanium aveva un elegante meccanismo di predicazione delle istruzioni, col quale avrebbe dovuto sopperire per lo più a questi casi. Al costo di eseguire, però, troppe istruzioni non utili (perché non facente parti della predicazione che successivamente si sarebbe dimostrata essere quella corretta).
Non sempre, però, i compilatori erano in grado di stabilire correttamente l'ordine delle istruzioni: in caso non ci riuscissero (ed accade più frequentemente di quanto si pensi...), il processore doveva andare in memoria a recuperare i dati necessari pagando un prezzo notevole in termini di tempo.
Il nocciolo della questione sta tutto qui. Infatti a parte l'inefficienza della predicazione (che va benissimo per casi di poche istruzioni. Infatti è quel che ARM e altri processori hanno implementato, mettendo le istruzioni condizionate. Anche se come meccanismo è di gran lunga meno flessibile rispetto a quello di Itanium), c'è il problema che:
1) tale meccanismo non si può applicare a tutto il codice;
2) l'accesso alla memoria non è sempre prevedibile, e si pagano costi elevatissimi in caso di miss dei dati;
3) i compilatori NON possono mai e poi mai sostituire la logica out-of-order, che è in grado di sapere in ogni ciclo di clock esattamente quali risorse sono a a disposizione, e tentare una schedulazione migliore per le istruzioni, in modo da massimizzare il più possibile l'uso delle risorse.
No branch prediction quindi no bachi recenti?
I bachi recenti non richiedono necessariamente la presenza della branch prediction.
TEORICAMENTE più elevate, nel senso che a livello pratico poi non erano così elevate a parità di costo rispetto ai RISC ed agli x86.
Fondamentalmente gli Itanium eccellevano
nell'eseguire codice che si presta ad essere eseguito bene sulle GPU, con di fatto gli stessi problemi di sviluppo software, mentre per il resto stavano nella media quando gli andava bene.
No, Itanium è abbastanza diverso dalle GPU. Specialmente rispetto a quelle dell'epoca, che non erano certo processori come quelli moderni.
peccato, paradossalmente sono stati uccisi dalle gpgpu.
Vedi sopra.
Ennesimo flop. Chissa' cosa sarebbe successo senza pratiche illegali.
A parte che non c'entrano niente le pratiche illegali, quando Itanium è stato progettato da Intel e HP (ricordiamocelo) non era certo chiaro cosa sarebbe successo dopo.
Erano stati fatti degli studi che portavano a quelle conclusioni, e quindi si è tentata quella via, anche tenendo conto del fatto che i compilatori stavano migliorando molto.

Col senno di poi, insomma, è facile giudicare.

D'altra parte se prendi i RISC e le motivazioni per cui sono stati introdotti, puoi vedere tu stesso che sono stati costretti a rimangiarsi quasi tutti i pilastri su cui erano stati fondati, e praticamente divenire dei CISC (oltre al fatto che l'esecuzione OoO è venuta fuori proprio dai RISC, per superare i loro intrinseci limiti).

Per il resto almeno Intel e HP hanno provato a tirare fuori qualcosa di originale, invece di una penosa pezza su x86 messa lì in fretta e furia pur di contrastare Intel con Itanium.
Spostare il compito di schedulare le istruzioni dal compilatore alla CPU è vantaggioso nelle architetture con tante CPU molto diverse fra loro sul mercato, come nel caso della giungla x86, dove risulta impossibile ottimizzare il codice a tempo di compilazione per ogni possibile CPU, salvo fare codici differenti con ottimizzazioni diverse e selezionarli a run-time dopo aver identificato la CPU. Lo svantaggio invece è che le CPU diventano più complesse e quindi più costose a parità di prestazioni massime, dovendo sobbarcarsi una parte dei compiti del compilatore o del programmatore.
In un mondo dove il software è fatto sempre più coi piedi, si definisce "programmatore" qualsiasi ragazzino che sa pasticciare con java e il business grosso sta nel rendere obsolescente l'hardware il prima possibile per venderne altro sempre più pachidermico, ci sta che la complessità si sposti sempre più sull'hw stesso (salvo poi trovarsi con problemi come la sicurezza zero, vedi Spectre e compagnia bella).
La "giungla" non è un problema tipico di x86. L'esecuzione OoO è nata nei RISC, come dicevo prima.

Inoltre non è anche pigrizia di programmatori e ragazzini improvvisati. Tutt'altro, ma è un discorso complesso.

D'altronde qualcuno ha mai visto qualche server con questa CPU?

purtroppo si, un dbserver su cui era difficile farci girare le cose che non fossero MS

Molti commenti partono da una premessa dell'articolo sbagliata: L'architettura IA-64, arrivata sul mercato con i processori Itanium, avrebbe dovuto sostituire l'architettura x86 secondo i piani di Intel.
L'IA-64 non è mai stata presentata come sostituto per il mondo x86.

Certo che avrebbe dovuto sostituire x86, l'idea era di fare prima i server (costosi come un cavallo) e poi con il tempo "riscalarle" verso il basso... ma AMD ci ha fregato tutti ed ora ci teniamo l'accrocchio sfigato chiamato AMD64 :cry:

Magari se LLVM ci fosse già stato o se si fossero usati linguaggi con JIT, Itanium ce l'avrebbe fatta, chi lo sa?

No, è il principio su cui si basa Itanium (che, in linea generale, riguarda i processori VLIM) che è sbagliato. I compilatori non possono assolutamente schedulare in anticipo le istruzioni da eseguire, come fa un backend con logica out-of-order; e questo vale anche per un compilatore JIT (che sempre compilatore è).

Sul resto concordo, soprattutto su AMD64: è stata buttata via la possibilità di ridisegnare x86 fornendo un'ISA migliore (peraltro buttando a mare una delle sue qualità: la buona densità di codice. Il codice AMD64/x64 è scandalosamente meno denso di x86), accontentandosi di una brutta pezza giusto giusto per introdurre i 64 bit e raddoppiare i registri.

accontentandosi di una brutta pezza giusto giusto per introdurre i 64 bit e raddoppiare i registri.
Infatti all'epoca il marketing le chiamava CPU a 64 bit, ma i tecnici contestavano e le chiamavano CPU con estensioni a 64 bit.

No, Itanium è abbastanza diverso dalle GPU. Specialmente rispetto a quelle dell'epoca, che non erano certo processori come quelli moderni.

Mica ho scritto dell'architettura, il riferimento era alla tipologia di software che girava meglio su Itanium, che giardacaso corrisponde a quello che gira bene sulle GPU "recenti".

Sul resto concordo, soprattutto su AMD64: è stata buttata via la possibilità di ridisegnare x86 fornendo un'ISA migliore (peraltro buttando a mare una delle sue qualità: la buona densità di codice. Il codice AMD64/x64 è scandalosamente meno denso di x86), accontentandosi di una brutta pezza giusto giusto per introdurre i 64 bit e raddoppiare i registri.
Concordo pure io, un occasione perduta.
Ma AMD64 non è malaccio considerando le alternative possibili ed il requisito di retrocompatibilità con gli x86.

Preferisco AMD64 ai RISC e concordo sulla retrocompatibilità con x86, ma non ho idea di quali potevano essere le alternative possibili a cui ti riferisci.
Di alternative (parlando a livello astratto) ce ne possono certamente essere (e pure di gran lunga meglio).

Quindi cdimauro secondo te le architetture VLIM sono belle sulla carta, ma non realmente applicabili?

Alla fine sta retrocompatibilità con x86 secondo me sta bloccando il progresso, quanto faremo CPU "quantistiche" quasi "IA" non pretenderemo mica che siano in grado di eseguire code x86?

Il "problema" poi dovrebbe essere risolto dal... 2000 da quando esistono Java e C# non è necessario scrivere per forza tutto in codice nativo ormai!

Secondo questo è un po' un "mito" anche il JIT genera codice nativo che potrebbe anche essere più ottimizzato per la macchina in cui gira (per esempio potrebbe usare istruzioni vettoriali SSE mentre il codice nativo potrebbe essere compilato per il minimo comun denominatore cioè i386) o si può sempre compilare in modo AOT ed allora anche C# / Java sono "codice nativo".

Il discorso è sempre quello il 99% delle applicazioni sono scritte in C/C++ mica perché sono "real time", ma per antica usanza... e poi hanno buffer overflow ovunque e ci costringeranno ad avere computer quantistici con emulazione x86!

Windows on ARM per potere avere successo deve essere in grado di emulare x86... per me Microsoft avrebbe dovuto essere più coraggiosa ed aver già realizzato uno "windows" tutto basato su .Net invece di fermarsi alla sola ricerca (Midori / Singularity).

Se vuoi le performance il codice nativo è una necessità

Già... e ricordo un mio progetto in cui ho rigirato le istruzioni core di un ciclo in maniera meno ovvia per favorirne gli accoppiamenti, oltre a triplicare le routine per eliminare i controlli sul segment overflow quando la gestione del dato non finiva allineata...

Avevi un compilatore "bacato"?
O eri su CPU a 8 bit da 3 KHz?

Quindi cdimauro secondo te le architetture VLIM sono belle sulla carta, ma non realmente applicabili?
Mai detto questo. Semplicemente la filosofia VLIW non paga in ambito "general computing".

Va benissimo, invece, per un tipo di codice abbastanza "lineare", che consenta di sfruttare al massimo tutti gli slot a disposizione in un bundle, perché oggettivamente l'implementazione è di gran lunga più economica rispetto a un processore OoO.
Alla fine sta retrocompatibilità con x86 secondo me sta bloccando il progresso, quanto faremo CPU "quantistiche" quasi "IA" non pretenderemo mica che siano in grado di eseguire code x86?
Le CPU quantistiche saranno sempre relegate ad applicazioni molto particolari (quelle in cui eccellono): per il "general computing" rimarranno le CPU tradizionali.

Con x86/x64 che penso sia destinata a rimanere per lungo, vista la quantità di codice (specifico) che è stato scritto.
Il "problema" poi dovrebbe essere risolto dal... 2000 da quando esistono Java e C# non è necessario scrivere per forza tutto in codice nativo ormai!
In assembly non ci scrivo da un bel pezzo (anche se in questo periodo lo sto riprendendo un po', perché sto scrivendo un assembler per una nuova ISA), ma arrivare a così basso livello in genere non è necessario.

Personalmente preferisco linguaggi di altissimo livello, come Python, perché mi focalizzo sul problema che voglio risolvere. Ovviamente se mi servono più prestazioni devo pensare ad altro.
Se vuoi le performance il codice nativo è una necessità
In genere sì, anche se ci sono delle eccezioni (in alcuni casi i compilatori JIT possono produrre codice più veloce rispetto anche a un C/C++ compilato direttamente per una determinata architettura).
Secondo questo è un po' un "mito" anche il JIT genera codice nativo che potrebbe anche essere più ottimizzato per la macchina in cui gira (per esempio potrebbe usare istruzioni vettoriali SSE mentre il codice nativo potrebbe essere compilato per il minimo comun denominatore cioè i386) o si può sempre compilare in modo AOT ed allora anche C# / Java sono "codice nativo".
E' vero, ma coi linguaggi di più alto livello in genere si perdono un po' di prestazioni.
Il discorso è sempre quello il 99% delle applicazioni sono scritte in C/C++ mica perché sono "real time", ma per antica usanza... e poi hanno buffer overflow ovunque e ci costringeranno ad avere computer quantistici con emulazione x86!
Sì, è vero che c'è un sacco di legacy, ma dove servono le prestazioni Fortran e C/C++ continuano a dominare. x86 non c'entra niente in ciò.
Windows on ARM per potere avere successo deve essere in grado di emulare x86... per me Microsoft avrebbe dovuto essere più coraggiosa ed aver già realizzato uno "windows" tutto basato su .Net invece di fermarsi alla sola ricerca (Midori / Singularity).
Bisogna vedere i risultati: se un s.o. basato su .NET ha prestazioni (CPU e/o memoria) peggiori rispetto a un altro "tradizionale", potrà essere "bello" quanto vuoi, ma rimarrà relegato a un esperimento di ricerca.

Per ribaltare lo status quo ci vogliono i numeri. E non con qualche selezionato benchmark sintetico, ma usando un buon parco di software reale nonché variegato.

Ciao Slater,

Io sarei interessato a qualche testo più specifico.
Potresti indicarmene qualcuno?

Grazie,
Quartz

Ringrazio cdimauro e frncr per le correzioni e le aggiunte alla mia spiegazione.
Per quanto riguarda i testi: consiglio di leggere sia "Struttura e progetto dei calcolatori" di Patterson e Hennessy (in Italia edito da Feltrinelli) che "Operating Systems: Three Easy Pieces", disponibile gratuitamente sul sito ufficiale (http://www.ostep.org/). Il secondo in particolare si focalizza molto sul perché è importante che ci siano buone prestazioni nell'esecuzione di codice out of order e sulle problematiche introdotte da quest'ultimo e dalla branch prediction (con tutti i problemi collegati alle cache, ad esempio). Ho studiato su entrambi i testi per gli esami in università; ho studiato sul secondo la scorsa estate per l'esame di sistemi operativi e l'ho trovato un ottimo testo, approcciabile da chiunque abbia delle fondamenta di informatica.