View Full Version : CPU Opteron con architettura ARM a 64bit dal prossimo anno
Redazione di Hardware Upg
14-12-2013, 08:31
Link alla notizia: http://www.businessmagazine.it/news/cpu-opteron-con-architettura-arm-a-64bit-dal-prossimo-anno_50167.html
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
Click sul link per visualizzare la notizia.
Ottima mossa, ma non capisco perché non fatta prima.
potrebbero avere potenzialità nel rendering?
s0nnyd3marco
14-12-2013, 08:57
Ottima mossa, ma non capisco perché non fatta prima.
Per me prima i tempi non erano ancora abbastanza maturi. Dopo piu' di un decennio di appiattimento sul binomio wintel finalmente si torna a vedere un po di diversificazione.
Tedturb0
14-12-2013, 09:01
mi piacerebbe capire le prestazioni per watt di cores ARM vs x86.
Considerando che AMD aveva la licenza di produrre proci x86, immagino questo significhi che ARM sia piu performante come architettura?
Pier2204
14-12-2013, 09:14
mi piacerebbe capire le prestazioni per watt di cores ARM vs x86.
Considerando che AMD aveva la licenza di produrre proci x86, immagino questo significhi che ARM sia piu performante come architettura?
Ha ancora licenza per produrre x86 e x86-64, penso vogliano diversificare l'offerta, anzi nell'articolo parla espressamente di strategia di tipo misto e offrire differenti soluzioni in base allo scenario di utilizzo, parlando di soluzioni server.
Credo che l'utilizzo di questa architettura sia proprio in funzione del minor consumo a parità di prestazioni, che poi da qui derivi anche un futuro SoC per il mercato mobile marchiato AMD sarebbe interessante saperlo...avendo in casa anche tecnologia per la GPU
ha quattro anni, ma dovrebbe essere ancora valido:
http://www.appuntidigitali.it/4375/arm-vs-intel-i-cut-the-power/
PaulGuru
14-12-2013, 09:37
mi piacerebbe capire le prestazioni per watt di cores ARM vs x86.
Considerando che AMD aveva la licenza di produrre proci x86, immagino questo significhi che ARM sia piu performante come architettura?
ARM come IPC è nettamente inferiore ad X86, la mossa è stata fatta sicuramente per migliorare il rapporto performance / watt.
Ed è una sonora sconfitta per AMD
ARM come IPC è nettamente inferiore ad X86, la mossa è stata fatta sicuramente per migliorare il rapporto performance / watt.
Ed è una sonora sconfitta per AMD
strano, non avrei mai potuto immaginare un tuo giudizio così critico verso questa mossa di amd, solitamente sei molto più accomodante verso l'azienda.
Speleosax
14-12-2013, 10:17
AMD vuole avere una copertura totale dell' offerta processori in modo da coprire tutto il mercato con le sue offerte: IMHO è una buona mossa per fronteggiare lo strapotere di Intel ed ARM nei rispettivi settori.
s0nnyd3marco
14-12-2013, 11:13
Ha ancora licenza per produrre x86 e x86-64, penso vogliano diversificare l'offerta, anzi nell'articolo parla espressamente di strategia di tipo misto e offrire differenti soluzioni in base allo scenario di utilizzo, parlando di soluzioni server.
Credo che l'utilizzo di questa architettura sia proprio in funzione del minor consumo a parità di prestazioni, che poi da qui derivi anche un futuro SoC per il mercato mobile marchiato AMD sarebbe interessante saperlo...avendo in casa anche tecnologia per la GPU
Anche nvidia ha sia la licenza arm che la tecnologia per le gpu, e purtroppo nel mobile non ha raccolto molto. Vedremo se amd avra' fortuna in questo settore cosi competitivo.
dobermann77
14-12-2013, 13:48
Fatemi capire,
AMD una volta produceva CPU,
ora progetta CPU,
il futuro è rivendere CPU?
Tedturb0
14-12-2013, 16:24
Anche nvidia ha sia la licenza arm che la tecnologia per le gpu, e purtroppo nel mobile non ha raccolto molto. Vedremo se amd avra' fortuna in questo settore cosi competitivo.
Il problema di nVidia e' che si trova a competere con aziende con molta piu esperienza e know-how sui core ARM. E core ottimizzati, nel mobile, fanno la differenza.
AMD lavora per i server, quindi suppongo che un Chip con core A5x, anche se non ottimizzato troppo per i consumi, consumerebbe comunque molto meno dei rispettivi cugini x86, giusto?
Si tecnicamente un opteron ARM serve a realizzare server a bassissimo consumo tipo per il cloud. In realtà i core arm sono molto vantaggiosi perché non si portano dietro una grande serie di istruzioni che in tali ambiti sarebbe totalmente inutile. C'è anche da dire che se andiamo a fare un confronto perfomance/watt non è che arm ne esca così vincente. Avere core arm significa usare prodotti a basso costo e che producono pochissimo calore, un rasperry single core che lavora tra 700mhz ed 1 ghz non monta alcun dissipatore, cosa che per gli x86 equivalenti non si è mai vista.
AMD ha fatto una scelta che la porterà ad avere una base unica con più varianti x86 , ARM , GPU.
si potrebbe arrivare a integrare tutti e tre sullo stesso chip in modo da soddisfare diverse necessita.
ARM bassi consumi
X86 compatibilità con il software
GPU per i calcoli paralleli
in modo da soddisfare il mercato in tutte le sue varianti
coschizza
14-12-2013, 22:03
potrebbero avere potenzialità nel rendering?
la cosa che meno si addice all'architetture e all'isa arm è proprio il rendering o in generale l'utilizzo di istruzioni vettoriali ad alte prestazioni. Quindi no il rendering è l'ultimo utilizzo per qel tipo di processore.
coschizza
14-12-2013, 22:07
un rasperry single core che lavora tra 700mhz ed 1 ghz non monta alcun dissipatore, cosa che per gli x86 equivalenti non si è mai vista.
la cpu di un rasperry è talmente lenta che qualsiasi cpu x86 di pari performance o anceh molto superiore non ha bisogno disipatore. Ti ricordo che la cpu è equivalente a un Pentium II a 300MHz quindi anche una xpu x86 10x piu veloce puo funzionare senza dissipatore a quel regime di performance.
s0nnyd3marco
15-12-2013, 08:46
AMD ha fatto una scelta che la porterà ad avere una base unica con più varianti x86 , ARM , GPU.
si potrebbe arrivare a integrare tutti e tre sullo stesso chip in modo da soddisfare diverse necessita.
ARM bassi consumi
X86 compatibilità con il software
GPU per i calcoli paralleli
in modo da soddisfare il mercato in tutte le sue varianti
Mica banale integrare architetture differenti sullo stesso core, specialmente quando sono cosi radicalmente differenti.
ARM come IPC è nettamente inferiore ad X86, la mossa è stata fatta sicuramente per migliorare il rapporto performance / watt.
Ed è una sonora sconfitta per AMD
L'IPC dipende principalmente dall' implementazione del core, non dal set d'istruzioni, ne dall'architettura logica visibile al programmatore.
Paradossalmente, per quel che riguarda il set d'istruzioni, gli ARM si presterebbero a soluzioni con un IPC più elevato di quello ottenibile con gli x86.
Quindi al massimo puoi dire "per ora le implementazioniARM come IPC sono inferiori a quelle X86".
Per ottenere un IPC più elevato Intel ha di fatto esaurito tutti i metodi disponibili (per questo ora puntano molto su nuove estensioni al set d'istruzioni).
Le architetture ARM sul mercato invece non sono così "spinte" perchè certe cose richiedono consumi più elevati o superficie del chip più ampia che non sono accettabili su SoC per smartphone e tablet.
Ovviamente se qualcuno deciderà di produrre cpu ARM con gli stessi consumi ed area su chip di cpu x86 "per desktop/server" le cose potrebbero cambiare drasticamente.
cdimauro
16-12-2013, 21:04
L'IPC dipende principalmente dall' implementazione del core, non dal set d'istruzioni, ne dall'architettura logica visibile al programmatore.
Anche l'ISA conta, e non poco. Non foss'altro perché l'implementazione dipende, ovviamente, da essa.
Paradossalmente, per quel che riguarda il set d'istruzioni, gli ARM si presterebbero a soluzioni con un IPC più elevato di quello ottenibile con gli x86.
Per quale motivo dovrebbe essere così?
Quindi al massimo puoi dire "per ora le implementazioniARM come IPC sono inferiori a quelle X86".
Questo è normale, al momento la situazione è quella e potrebbe anche cambiare in futuro, ma segnali di cambiamento non se ne vedono.
Per ottenere un IPC più elevato Intel ha di fatto esaurito tutti i metodi disponibili
E' senz'altro vero che sia difficile pensare a balzi notevoli sul fronte del calcolo "general purpose", ma come fai a escludere a priori che non possa saltare fuori qualche idea per innovare (e migliorare le prestazioni, ovviamente) qualche particolare aspetto dell'implementazione dell'ISA? Le innovazioni non sono certo mancate finora...
(per questo ora puntano molto su nuove estensioni al set d'istruzioni).
Veramente lo fa da più di 20 anni ormai, e per ottime ragioni: mentre è difficile spingere le prestazioni single-thread per il codice general purpose, per quello parallelo una soluzione economica a livello implementativo, e che si presta a essere molto scalabile, è l'approccio SIMD.
Per questo sono nate tante estensioni, e altre ancora arriveranno, con contributi che non sono legati soltanto all'aumento della dimensione dei registri o all'aggiunta di nuove istruzioni.
In quest'ambito i RISC hanno parecchi problemi dovuti all'opcode di dimensione fissa (32 bit, in genere), per cui sono costretti a limitare l'instruction set e alle funzionalità impacchettate nelle istruzioni.
Al contrario i CISC, potendo contare su istruzioni di lunghezza variabile, possono mettere a disposizione funzionalità più interessanti / ricche, che ovviamente incidono positivamente sulle prestazioni.
Le architetture ARM sul mercato invece non sono così "spinte" perchè certe cose richiedono consumi più elevati o superficie del chip più ampia che non sono accettabili su SoC per smartphone e tablet.
E' anche vero che i processi produttivi sempre migliori hanno consentito di impaccare molti più transistor a parità di superficie, riducendo anche i consumi. L'A7 di Apple conta 1 miliardo di transistor (anche se bisogna tenere presente pure la GPU), e ha "appena" due core.
Con numeri così elevati in gioco anche la "x86 tax" non ha più un peso così rilevante nel computo della dimensione del die e nei consumi.
Senza dimenticare che pure ARM si porta dietro la sua "tax", che consiste nelle diverse ISA che deve supportare, non ultima quella a 64-bit che presenta un'opcode table e una struttura delle istruzioni molto diversa da quella tradizionale. Anche questo ha un costo; non elevato come nel caso di Intel, ma che incide sia nel numero di transistor che nell'implementazione della pipeline.
Ovviamente se qualcuno deciderà di produrre cpu ARM con gli stessi consumi ed area su chip di cpu x86 "per desktop/server" le cose potrebbero cambiare drasticamente.
Bisogna vedere gli obiettivi che ci pone. Consumi e/o area del chip non sono gli unici parametri importanti per misurare la "bontà" di un'architettura.
Anche l'ISA conta, e non poco. Non foss'altro perché l'implementazione dipende, ovviamente, da essa.
Ed infatti l'ISA x86 fa decisamente pena sotto tale aspetto, servono decoder molto più complicati che creano colli di bottiglia sia sulle unita di esecuzione a valle che sulla frequenza di clock massima.
Invece l'ISA ARM è molto più pulita, al punto che quando hanno introdotto le estensioni THUMB (che dimezzano la lunghezza media delle istruzioni) il "decoder THUMB" è in pratica uno stadio in più a "mappatura fissa" (senza stati interni) sul decoder istruzioni di ARM32.
Inoltre la differenza di prestazioni "tra istruzioni a lunghezza fissa" ed "istruzioni a lunghezza variabile" dipende anche dalla semantica delle singole istruzioni e dalla presenza o meno della cache istruzioni.
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.
Ma per roba ad alte prestazioni basta avere un i-cache più grande e gran parte della differenza tra istruzioni di lunghezza fissa e variabili viene meno.
E' inoltre da notare che il set d'istruzioni A64 a 64bit dei nuovi ARMv8 ha parecchie differenze rispetto al "vecchio" A32 proprio per scalare bene in prestazioni in un contesto "a 64bit" (bus dati almeno a 64bit, processi produttivi che permettono di avere minimo una certà densità, ecc. ecc.).
Guardacaso alcune feature di A64 ricordano le "vecchie" cpu Alpha
(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).
Con numeri così elevati in gioco anche la "x86 tax" non ha più un peso così rilevante nel computo della dimensione del die e nei consumi.
E' rilevante se va a creare un collo di bottiglia sui decoder istruzioni rispetto agli ARM.
Senza dimenticare che pure ARM si porta dietro la sua "tax", che consiste nelle diverse ISA che deve supportare, non ultima quella a 64-bit che presenta un'opcode table e una struttura delle istruzioni molto diversa da quella tradizionale. Anche questo ha un costo; non elevato come nel caso di Intel, ma che incide sia nel numero di transistor che nell'implementazione della pipeline.
La differenza è che i vari set d'istruzione ARM sono ad alta simmetria (con molte meno eccezioni nella decodifica) con la possibilità di passare da un istruzione THUMB ad ARM32 con una "espansione fissa" senza stati interni aggiuntivi e con previsto sin dal principio un meccanismo di espansione del set d'istruzioni (usando gli opcode per i coprocessori) che permettono di avere decoder molto semplici che possono operare in parallelo e che rendo più semplice commutare da uno all'altro.
Fa una differenza notevole.
cdimauro
17-12-2013, 06:23
Ed infatti l'ISA x86 fa decisamente pena sotto tale aspetto, servono decoder molto più complicati che creano colli di bottiglia sia sulle unita di esecuzione a valle che sulla frequenza di clock massima.
Passi 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?
Invece l'ISA ARM è molto più pulita, al punto che quando hanno introdotto le estensioni THUMB (che dimezzano la lunghezza media delle istruzioni)
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.
il "decoder THUMB" è in pratica uno stadio in più a "mappatura fissa" (senza stati interni) sul decoder istruzioni di ARM32.
Sì, ne sono a conoscenza.
Inoltre la differenza di prestazioni "tra istruzioni a lunghezza fissa" ed "istruzioni a lunghezza variabile" dipende anche dalla semantica delle singole istruzioni
Potresti fare un esempio di quello che ho evidenziato?
e dalla presenza o meno della cache istruzioni.
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).
Ma per roba ad alte prestazioni basta avere un i-cache più grande e gran parte della differenza tra istruzioni di lunghezza fissa e variabili viene meno.
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.
E' inoltre da notare che il set d'istruzioni A64 a 64bit dei nuovi ARMv8 ha parecchie differenze rispetto al "vecchio" A32 proprio per scalare bene in prestazioni in un contesto "a 64bit" (bus dati almeno a 64bit, processi produttivi che permettono di avere minimo una certà densità, ecc. ecc.).
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.
Guardacaso alcune feature di A64 ricordano le "vecchie" cpu Alpha
(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.
E' rilevante se va a creare un collo di bottiglia sui decoder istruzioni rispetto agli ARM.
Scusa, ma che c'entra questo con quello che avevo scritto. Potresti essere più chiaro, cortesemente?
La differenza è che i vari set d'istruzione ARM sono ad alta simmetria (con molte meno eccezioni nella decodifica)
Non è certo un problema. Lo sarebbe per un essere umano che dovesse scrivere codice assembly.
con la possibilità di passare da un istruzione THUMB ad ARM32 con una "espansione fissa" senza stati interni aggiuntivi e con previsto sin dal principio un meccanismo di espansione del set d'istruzioni (usando gli opcode per i coprocessori) che permettono di avere decoder molto semplici che possono operare in parallelo e che rendo più semplice commutare da uno all'altro.
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?
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.