Intel e supporto a x86-64: alcuni possibili scenari

Per l'architettura in primis. Per quanto riguarda l'implementazione, per fortuna con Itanium II abbiamo cominciato a vedere delle prestazioni decenti. Certo è che fa impressione notare l'utilizzo spropositato di cache di terzo livello per rendere più performante,e quindi più competitivo, questo prodotto...

Quando? Intel dispone della miglior tecnologia nel campo dei compilatori, e ancora non è riuscita a sfruttare per bene la sua nuova architettura. C'è qualcosa che non quadra, non credi?

Troppo in fretta? L'Itanium come progetto ha più di 8 anni di vita: mi sembrano abbastanza per pensare, in questo lungo arco di tempo, di renderlo competitivo...

Non solo, era un discorso generale. Esistono degli studi sugli algoritmi in cui si analizza il quantitativo di registri necessario per poter coprire interamente l'esecuziona di una routine. Buona parte richiedono fino a 8 registri, la stragrande maggioranza fino 16, e una piccolissima parte fino a 32 registri (l'implementazione del parser del linguaggio Perl, se non ricordo male), e si possono contare quelle che ne richiedono più di 32.

Compilatori realmente ottimizzati, nell'accezione accademica del termine, non ne esistono e non ne esisteranno mai. Il problema della generazione del codice ottimale a partire da un qualunque sorgente è dimostrato essere non computabile.
Diciamo che gli attuali compilatori fanno un buon lavoro...

I vantaggi sono che si utilizza (quasi sempre) il minimo numero di bit (ma è meglio parlare di byte, alla fine) che sono necessari per rappresentare l'operazione che si vuole eseguire. Sono, quindi, notevoli in termini di spazio occupato, e le implicazioni pratiche sono le seguenti:
1) minor utilizzo della cache L1
2) minor banda necessaria
3) possibilità di poter estrarre dalla linea di cache L1 un maggior numero di istruzioni
4) nessuno spreco di spazio nel caso in cui sia necessario inserire un'istruzione NOP nel flusso del codice, a causa di particolari vincoli architetturali (mi riferisco, per fare un esempio chiarificatore, ai vincoli di architettore VLIW e EPIC, che non possono eseguire sempre e comunque "n" istruzioni a causa di problemi di dipendenza e debbono quindi inserire nella "macroistruzione" delle NOP)
5) minor dimensione dell'eseguile finale

Pensa ad un'istruzione "mov registro, registro", oppure una "inc/dec registro", ad esempio: sono le più frequenti, ma occupano pochissimo spazio (la prima un byte se viene coinvolto il registro accumulatore, 2 altrimenti, mentre le altre due sempre un byte).
Il risparmio di spazio è notevole. In un'architettura RISC devi sempre e comunque occupare esattamente lo stesso spazio, anche nel caso di istruzioni piccole come quelle (ma che sono anche le più frequenti, ripeto).

Esattamente. Comunque interessa anche i cultori delle architetture...

Come del resto tutti, no?

IMHO sono anche troppi, e possono anche essere fonte di problemi. Difatti l'accesso ai 128 registri sull'EPIC non avviene tanto velocemente quanto nelle altre architetture con un minor numero proprio per questo motivo, a cui si aggiunge anche il meccanismo di "rotazione"...

Indubbiamente. Ma considera che la maggior parte del tempo che viene speso nella computazione di un'applicazione si ha nell'esecuzione di cicli, per cui alla fine è lì che devi sfruttare al meglio il numero di registri disponibile, e non mi pare che sia un'operazione difficile, anche per un compilatore, avere un tetto massimo di 16 registri...

L'EPIC è comunque un VLIW, per cui l'esperienza che hai acquisito con questi ultimi puoi applicarla più o meno anche con questa "nuova" architettura.

In effetti mi stupisce che non abbia un compilatore in grado di sfruttare al meglio l'epic.


Per quel poco che ho capito, sevono soprattutto per algo crittografici, possibilmente eseguiti in real-time.


Infatti intendevo che più di così non si può chiedere...


Se partiamo dal presupposto che la decodifica abbia lo stesso "costo" posso essere d'accordo con te. Però secondo me le dimensioni del codice sono meno critiche rispetto ad una volta.
Per questo adesso vedo più interesse per le architetture vliw.
Inoltre considera che avere istruzioni a lung fissa ti permette di sapere in anticipo dov'è la prossima istruzione (a meno di salti, ovvio): questo è un grande vantaggio per architetture in grado di "macinare" molte istruzioni per ciclo (magari per i futuri processori multicore ).

Ho dato un'occhiata all'assembly epic: effettivamente non è molto comodo da scrivere rispetto al vliw che conosco .
Ma non è che l'assembly x86 l'ho capito in un giorno, anzi sicuramente non lo conosco tuttora bene...

In altre architetture la conoscenza dell'assembly era sicuramente utile per scrivere pezzi di codice ottimizzato... Con EPIC invece è praticamente impossibile superare l'efficienza del compilatore nello scrivere codice... Uno dei motivi principali, oltre alla difficoltà del codice stesso, è l'istruction level parallelism...
Sarebbe come mettersi a scrivere a mano codice SSE2 e poi confrontare il risultato con quello generato dal compilatore Intel

Intel stessa mi sembra che sconsigli l'uso di parti di codice in assembly...

boh, io scrivo "pezzi" di codice ilp meglio del compilatore (non intel, non epic, ma vliw), certo il loop unrolling glielo lascio fare a lui , ma in altri punti mi sembra un po' troppo "conservativo"...
certo un programma intero in assembly non lo scrivo neanche per x86


Non c'è bisogno che lo sconsigli, si sconsiglia da solo...

Intendevo "pezzi" proprio nel senso che è raro scrivere un programma intero in assembly...in qualsiasi architettura...

Il discorso che facevo si riferiva interamente ad Epic...

ops, mi era scappato il riferimento ai "pezzi" nel tuo post originario...
però perchè confidi così poco nelle capacità dei bravi programmatori?

ps: mi ero scusato per essere andato ot e ci sono ricascato!

Perchè da quello che ho visto ci sono decine di barbatrucchi in Epic per mantere un alto livello di istruction level parallelism... Mantente questo livello alto è l'unico modo per far sì che Itanium dia buone prestazioni...

se intel utilizzasse le stesse istruzioni introdotte da amd non si risolverebbero tutti i problemi?