Intel dismette ufficialmente Itanium, il futuro dell'architettura IA-64 resta ignoto

[fano]

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

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

[cdimauro]

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.

[schwalbe]

Originariamente inviato da cdimauro

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.

[LMCH]

Originariamente inviato da cdimauro

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".

[LMCH]

Originariamente inviato da cdimauro

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.

[cdimauro]

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).

[fano]

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!

[fano]

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).

[Maddog1976]

Originariamente inviato da Veradun

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...

[fano]

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

[cdimauro]

Originariamente inviato da fano

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.

Originariamente inviato da Veradun

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).

Originariamente inviato da fano

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.

[Slater91]

Originariamente inviato da quartz

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. 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.