AMDARM
CPU Opteron con architettura ARM a 64bit dal prossimo anno
di Paolo Corsini pubblicata il 14 Dicembre 2013, alle 09:31 nel canale Private Cloud
AMD anticipa alcune delle caratteristiche tecniche alla base della futura famiglia di processori Opteron dotati di architettura ARMv8, sviluppati pensando alle esigenze di consumo e densità di elaborazione propri dei sistemi microserver
21 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - infoPassi sulla frequenza, che potrebbe essere influenzata (ma non è scontato: in genere aggiungere qualche stadio di pipeline è sufficiente per eliminare questo problema), ma quale sarebbe l'impatto sulle unità d'esecuzione?
Non è affatto vero che la dimezzano. Persino ARM dichiara un densità di codice pari al 70% circa, ma ci sono parecchie statistiche in merito che mostrano come la densità sia buona, ma assolutamente lontana dalla metà rispetto all'originale ARM.
D'altra parte è anche ovvio che sia così: Thumb ha istruzioni a 16 e 32 bit, e non usa soltanto le prime, anche se sono mediamente le più frequenti.
Sì, ne sono a conoscenza.
Potresti fare un esempio di quello che ho evidenziato?
Ad esempio sugli ARM fu introdotta l'estensione THUMB per avere codice con compattezza comparabile a quella di cpu ad 8bit, poter fare a meno di una cache istruzioni (o usare cache istruzioni più piccole) ed avere buone prestazioni anche con bus verso la i-cache a 16bit.
Questo non c'entra con la lunghezza variabile o meno: riguarda a livello generale la densità di codice.
Inoltre anche senza cache istruzioni è possibile alleviare la decodifica delle istruzioni a lunghezza variabile. Persino processori CISC molto vecchi hanno una sorta di mini-buffer per le istruzioni, che consentono loro di evitare i problemi di allineamento per andare a caccia delle istruzioni (e implementare efficacemente il pipelining).
In generale la cache serve soltanto per memorizzare le istruzioni. E' la logica di decodifica che si occupa di allineare lo stream delle istruzioni. Ciò si verifica anche con Thumb, che infatti è un'ISA CISC (ed è il motivo per cui la densità di codice è più elevata rispetto alla classica ISA ARM).
La cache più grande incide nei costi di produzione, nel budget dei transistor, e nei consumi. E' una delle componenti più critiche. Tant'è che se ne aumenti la dimensioni spesso sei costretto ad aumentare la latenza per cercare di risparmiare silicio, e ciò incide sulle prestazioni.
Le cache istruzioni esistono da 3 decadi, ma se fosse possibile aumentare a piacimento la loro dimensione, grazie alla legge di Moore oggi avremmo cache istruzioni molto più grandi rispetto a quelle disponibili. Invece non è così.
Ciò precisato, la densità di codice incide sulle prestazioni perché richiede più spazio, e dunque a catena ha ripercursioni su: decoder (buffer usato per allineare le istruzioni), cache L0/L1/L2/L3/L4, memoria, e le TLB delle cache che ne sono dotate.
Quindi ammetti che il codice ARMv8 sia meno denso, dunque abbia bisogno di cache istruzioni più grandi, grazie a processi produttivi migliori. Ma ciò non è un problema soltanto della cache codice; vedi poco sopra.
Senz'altro ARMv8 rappresenta un grande cambiamento per ARM, ma ha dovuto sacrificare parecchio la sua ISA per votarsi alle prestazioni. Molte caratteristiche storiche, che la contraddistingueva, sono sparite. E non ha nemmeno presentato una ISA Thumb a 64 bit (ma qui penso che sia comprensibile).
Non concordo sul "contesto a 64 bit": esistevano ed esistono ISA a 32-bit che hanno molte similitudini con ARMv8 (in realtà è il contrario). Infatti ad ARM serviva un'ISA per scalare sulle prestazioni, per rendersi più competitiva su questo fronte, oltre ovviamente a poter indirizzare agevolmente più di 64 bit.
(il primo microprocessore a 64bit e per anni campione assoluto in termini
di prestazioni per singolo core, se ricordo bene, due anni dopo che smisero di svilupparne
versioni più evolute e con processo produttivo più arretrato
superava ancora in prestazioni su interi e float sia gli x86 che gli Itanium).
Itanium era molto giovane, mentre Alpha era un'ISA ben rodata. Non mi pare un confronto corretto.
Scusa, ma che c'entra questo con quello che avevo scritto. Potresti essere più chiaro, cortesemente?
Non è certo un problema. Lo sarebbe per un essere umano che dovesse scrivere codice assembly.
Fa una differenza notevole.
Il decoder Thumb è certamente più semplice di uno x86, ma pone non pochi problemi perché si tratta di istruzioni a lunghezza variabile. Non puoi espandere le istruzioni a piacimento, perché hai bisogno di conoscere la lunghezza di tutte le istruzioni che sei in grado di decodificare, per poterle poi trasformare in quelle a lunghezza fissa. Che poi è esattamente quello che si fa con x86, dove dalle istruzioni x86 si passa a quelle del RISC interno.
D'altra parte, come dicevo prima, Thumb è un'ISA CISC, e ne condivide le problematiche, ovviamente in misura diversa perché dipende dalla struttura degli opcode che è stata adottata.
I decoder paralleli esistono da tempo anche su x86, infatti. Ma si paga un certo prezzo per poterli avere.
P.S. Come mai hai risposto solo su alcuni punti?
Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".