Architettura ARM leader nel settore MCU per il 2011

[AnonimoVeneziano]

Originariamente inviato da cionci

L'efficienza energetica forse...non certo quella di esecuzione. Se non sbaglio sono addirittura in-order...

Se stai parlando di ATOM (quotare cosa si sta commentando please ) l'obiettivo di intel è ottimizzare il rapporto prestazioni/consumo.

Atom è in-order, ma oltre ad usare alcuni "trucchi" out-of-order su un ristretto set di istruzioni di uso comune usa anche l'hyper-threading per non lasciare in idle la sua seconda unità di esecuzione.

Vedremo come sarà l'evoluzione della cosa. Per me anche ATOM un giorno vedrà o una estensione dei trucchetti "out-of-order" a un maggior numero di istruzioni o una completa implementazione di un core out-of-order.

Intanto con il netbook atom che ho a casa su Mplayer-MT riesco a riprodurre video 1080p in H264 fino a 7-8 Mbps che non è male per una cpu in-order

Ciao

[Felix]

Infatti anche Texas (che e' un gigante, e fornisce supporto per la produzione a lunghissimo termine) ha da diverso tempo soluzioni ibride basate su ARM (dal 9 fino al piu' recente Cortex-A8), di solito affiancate ad un DSP per il lavoro sporco.
Quello che riesce a sorprendermi di queste soluzioni ARM e' sempre l'ottimo rapporto Consumo/Prestazioni, mentre dal punto di vista prestazionale puro credo che i PowerPC possano ancora dire la loro.
Riguardo agli x86, dato che scaldano gli animi, nulla da dire, gli ultimi hanno quasi un rendimento di 3 istruzioni per ciclo di clock, ma dal punto di vista dei consumi nel mercato embedded/conduction cooled nel quale lavoro fatichiamo un po' ad adottarli.

[faber80]

Originariamente inviato da AnonimoVeneziano

Se stai parlando di ATOM (quotare cosa si sta commentando please ) l'obiettivo di intel è ottimizzare il rapporto prestazioni/consumo.

Atom è in-order, ma oltre ad usare alcuni "trucchi" out-of-order su un ristretto set di istruzioni di uso comune usa anche l'hyper-threading per non lasciare in idle la sua seconda unità di esecuzione.

Vedremo come sarà l'evoluzione della cosa. Per me anche ATOM un giorno vedrà o una estensione dei trucchetti "out-of-order" a un maggior numero di istruzioni o una completa implementazione di un core out-of-order.

Intanto con il netbook atom che ho a casa su Mplayer-MT riesco a riprodurre video 1080p in H264 fino a 7-8 Mbps che non è male per una cpu in-order

Ciao

scusami, ma mi ha incuriosito una cosa: come fai a vedere fluido un mkv 1080p con cpu Atom se io con un ULV a 1.2 (2Mb di cache) - che è molto più prestante - riesco a vedere fluidi solo quelli a 720p (e con CoreAvc 1.9) ? Se sfrutti anche una gpu è un altro discorso (io no perchè ho una vecchia intel integrata). inoltre, se puoi, puoi dirmi la tua configurazione ? grazie

[gondsman]

Originariamente inviato da fabri85

che dire... Fx Pwna!!! xD

da ignorante in materia attendo e spero ansiosamente in una risposta a Fx xD

Eccomi!
L'architettura x86 non e' inefficiente rispetto agli ARM, e' inefficiente e basta.
E' ovvio che un ARM vada piu' lento (e parecchio) di un x86: e' pensato per soluzioni embedded e punta molto sul risparmio energetico e altre features che su un PC non servono a niente. I processori Intel e AMD, d'altra parte, sono sviluppati con tecnologia allo stato dell'arte e sono incredibilmente ottimizzati con soluzioni hardware all'avanguardia. Inoltre lo sviluppo di compilatori x86 e' decisamente avanzato in confronto a quelli per altre architetture.
Il fatto e' che l'ISA x86 e' vecchio, inadeguato e incredibilmente complesso. I processori x86, per mantenere la retrocompatibilita', sono costretti a implementare in hardware strutture capaci di eseguire tutte le istruzioni dell'ISA (oltre a quelle MMX, SSE, SSE2, SSE3...). "Questo i tecnici della Intel lo sanno benissimo e getterebbero volentieri il set di istruzioni x86 nella baia di San Francisco, se non fosse per le stringenti leggi anti-inquinamento in vigore in California"[1]. Gli stessi programmi, facendo uso di un ISA piu' snello e moderno, consentirebbero di liberarsi di molti "pezzi" del processore, rendendolo piu' piccolo, meno costoso e piu' efficiente.
Tutto il discorso si traduce nel fatto che esistono miliardi di applicazioni "legacy" che nessuno vuole (o sa) riscrivere, quindi cambiare architettura su PC e' semplicemente impossibile in questo momento. Questo comporta che sull'x86 siano stati investiti una quantita' di soldi inimmaginabile, portando i processori Intel compatibili a essere i piu' veloci sul mercato nonostante un ISA pessimo. Su dispositivi embedded questa necessita' di retrocompatibilita' e' di gran lunga ridotta, quindi e' ovvio che qui possano prendere piede anche soluzioni alternative come ARM.
[1] Andrew S. Tanenbaum, Structured Computer Organization, Prentice Hall, 2006

[cionci]

gondsman: sicuramente l'architettura x86 è un legame scomodo per i progettisti di CPU, ma questo legame non crea più problemi come li creava una volta (suddivisione fra istruzioni wired e istruzioni eseguite in microcodice). Attualmente la CPU internamente non esegue più istruzioni x86 e questo per Intel dal P4 e per AMD dal K7. Tutte le istruzioni eseguite sono a lunghezza fissa.
Gli x86 sono al giorno d'oggi anche più evoluti dei Risc. Chiaro che si debba pagare pegno sulla moteplicità, complessità e occupazione di die delle unità di decodifica, ma pagato questo dazio le CPU x86 sono quanto di più avanzato ci sia sul mercato.

[gondsman]

Ovvio che molte istruzioni vengano "emulate" o tradotte in combinazioni di altre istruzioni direttamente dal processore, ma se Intel, con le tecnologie che possiede, decidesse di creare un processore con un set di istruzioni "nuovo" sicuramente potrebbe creare qualcosa di molto piu' performante dei suoi attuali x86. Certo il software (specie i compilatori) non ci sarebbe o sarebbe meno sviluppato, cosa che di fatto taglia le gambe ad un'idea del genere...

[cionci]

Originariamente inviato da gondsman

Ovvio che molte istruzioni vengano "emulate" o tradotte in combinazioni di altre istruzioni direttamente dal processore, ma se Intel, con le tecnologie che possiede, decidesse di creare un processore con un set di istruzioni "nuovo" sicuramente potrebbe creare qualcosa di molto piu' performante dei suoi attuali x86. Certo il software (specie i compilatori) non ci sarebbe o sarebbe meno sviluppato, cosa che di fatto taglia le gambe ad un'idea del genere...

E IA64 ?
Comunque tutte le istruzioni x86 vengono tradotte, spezzettate, unite in istruzioni a lunghezza fissa...questo era appunto uno dei vantaggi delle architetture Risc, che grazie a questo si potevano permettere di adottare soluzioni sicuramente più fantasiose ed efficienti.
Ora questo problema non si sente più, o comunque molto meno.

[macfanboy]

Originariamente inviato da cionci

E IA64 ?
Comunque tutte le istruzioni x86 vengono tradotte, spezzettate, unite in istruzioni a lunghezza fissa...questo era appunto uno dei vantaggi delle architetture Risc, che grazie a questo si potevano permettere di adottare soluzioni sicuramente più fantasiose ed efficienti.
Ora questo problema non si sente più, o comunque molto meno.

Però questo transcoding in istruzioni RISC non è una cosa semplice. E' molto complessa. Anche se sono riusciti dal punto di vista prestazionale a non essere più di tanto penalizzati (e questo era semplicemente impensabile qualche anno fà quando, ad esempio, Apple-Motorola e IBM hanno deciso di sviluppare il PowerPC) comunque si portano appresso una complessità impressionante.

E se questa complessità può essere abbastanza mascherata avendo un "budget" di transistor gigantesco (come hanno ora i processori per PC), non lo è quando si ricerca l'efficienza pura sia in termini di costi (n. di transistor) che di consumo.

Per questo per me l'x86 non ha CHANCE nei dispositivi ultraportatili. E più l'efficienza sarà importante e meno gli x86 saranno competitivi (e ormai la gente compra i notebook o addirittura i netbook, non i desktop). Quindi c'è una piccola speranza che prima o poi FINALMENTE gli x86 scompariranno!!

[cionci]

Originariamente inviato da macfanboy

Per questo per me l'x86 non ha CHANCE nei dispositivi ultraportatili. E più l'efficienza sarà importante e meno gli x86 saranno competitivi (e ormai la gente compra i notebook o addirittura i netbook, non i desktop).

Dal punto di vista energetico hai ragione, porta sicuramente a consumi più alti, ma il vantaggio tecnologico che ha Intel (e qualche anno fa AMD) rispetto alle altre fonderie è tale da mascherare questa carenza.

[AnonimoVeneziano]

Originariamente inviato da cionci

Dal punto di vista energetico hai ragione, porta sicuramente a consumi più alti, ma il vantaggio tecnologico che ha Intel (e qualche anno fa AMD) rispetto alle altre fonderie è tale da mascherare questa carenza.

Questa è una grande verità .

Quando i propri processori stanno a 32nm e quelli degli altri a 65 o di più la differenza si sente ...

[LMCH]

Originariamente inviato da AnonimoVeneziano

Ricordiamoci che ATOM è il primo processore x86 che ha come primo obiettivo l'efficienza, non può altro che migliorare da adesso in poi .

Puo si migliorare, ma non oltre certi limiti, piu si cerca di migliorare l'efficienza e piu il set d'istruzioni comincia a pesare.

Infatti per reggere la concorrenza nel settore embedded la ARM Ltd. ha introdotto le varianti -M3 ed -M0 dei Cortex che supportano solo le istruzioni Thumb 2 (un sottoinsieme delle istruzioni supportate dagli ARM Cortex "completi") in modo da ridurre drasticamente i consumi "riducendo i transistor"
e "riducendo la lunghezza media delle istruzioni in un programma tipico".

Un approccio del genere con gli x86 non sarebbe conveniente proprio a causa dell'architettura "troppo contorta" che hanno.

[shodan]

Originariamente inviato da gondsman

Eccomi!
L'architettura x86 non e' inefficiente rispetto agli ARM, e' inefficiente e basta.
E' ovvio che un ARM vada piu' lento (e parecchio) di un x86: e' pensato per soluzioni embedded e punta molto sul risparmio energetico e altre features che su un PC non servono a niente. I processori Intel e AMD, d'altra parte, sono sviluppati con tecnologia allo stato dell'arte e sono incredibilmente ottimizzati con soluzioni hardware all'avanguardia. Inoltre lo sviluppo di compilatori x86 e' decisamente avanzato in confronto a quelli per altre architetture.
Il fatto e' che l'ISA x86 e' vecchio, inadeguato e incredibilmente complesso. I processori x86, per mantenere la retrocompatibilita', sono costretti a implementare in hardware strutture capaci di eseguire tutte le istruzioni dell'ISA (oltre a quelle MMX, SSE, SSE2, SSE3...). "Questo i tecnici della Intel lo sanno benissimo e getterebbero volentieri il set di istruzioni x86 nella baia di San Francisco, se non fosse per le stringenti leggi anti-inquinamento in vigore in California"[1]. Gli stessi programmi, facendo uso di un ISA piu' snello e moderno, consentirebbero di liberarsi di molti "pezzi" del processore, rendendolo piu' piccolo, meno costoso e piu' efficiente.
Tutto il discorso si traduce nel fatto che esistono miliardi di applicazioni "legacy" che nessuno vuole (o sa) riscrivere, quindi cambiare architettura su PC e' semplicemente impossibile in questo momento. Questo comporta che sull'x86 siano stati investiti una quantita' di soldi inimmaginabile, portando i processori Intel compatibili a essere i piu' veloci sul mercato nonostante un ISA pessimo. Su dispositivi embedded questa necessita' di retrocompatibilita' e' di gran lunga ridotta, quindi e' ovvio che qui possano prendere piede anche soluzioni alternative come ARM.
[1] Andrew S. Tanenbaum, Structured Computer Organization, Prentice Hall, 2006

Ciao,
capisco quello che vuoi dire e condivido il fatto che ARM ha un netto margine di vantaggio per quanto riguarda i consumi, ma credo che stai trascurando alcuni aspetti:
1) se è vero che l'ISA x86 non è il massimo, è anche vero che i maggiori grattacapi vengono dati dalle istruzioni x87. Queste istruzioni ormai possono essere in gran parte abbandonate, in quanto le SSE2 permettono di sostituire quasi completamente le istruzioni x87 (per esempio, su tutte le architetture x86-64 il GCC 4.x sfrutta di default le SSE2 al posto delle istruzioni x87);
2) con l'introduzione del set x86-64, AMD ha rimosso diverse istruzioni e opcode raramente utilizzati e ha uniformato in diversi modi le altre istruzioni. Tanto per fare un esempio, è stata rimosso l'opcode di incremento (INC) in quanto c'era già quello di addizione (ADD) che faceva egregiamente il suo lavoro. Altro esempio: è stata rimossa la modalità virtual-386; è questo il motivo per cui i sistemi Windows x64 _non_ fanno girare diversi programmi DOS;
3) è vero che il deconding delle istruzioni CISC nelle micro/macro ops RISC interne porta via spazio sul silicio e un aumento del consumo, ma a livello prestazionale non incide più di tanto in quanto i decoder sono calibrati per alimentare in maniera adeguata il back-end di elaborazione. Oltre a questo, considera che avere un'ISA esterna di tipo CISC comporta un migliore uso della RAM e della cache, in quanto le istruzioni sono più "dense". Uno dei motivi per cui i processori RISC sono stati i primi a usare cache di una certa dimensione (l'Alpha aveva 96 KB di L2 on-die) è proprio perchè le loro istruzioni occupavano, mediamente, più memoria;
4) se parliamo di Atom, i processori ARM sono tutto sommato comparabili in quanto a velocità/capacità. Se però tiriamo in ballo genericamente tutta la famiglia x86, il paragone non regge: seppur in qualche modo penalizzate dalla loro ISA esterna, i processi x86 hanno mostrato una densità di potenza notevole, e si sono fatti strada anche nel mercato dei supercomputer. Ovvio che, oltre una certa soglia, aumentare la velocità del processore sia inefficiente da un punto di vista energetico, ma questo è il prezzo da pagare per avere le migliori prestazioni in assoluto. Per esempio, un'archiettura out-of-order consuma sicuramente di più di una in-order, ma nel codice con molti salti e/o accessi alla memoria è incontestabilmente più veloce.

Detto questo, come giustamente hai fatto notare, anche i progettisti Intel vorrebbero girare pagina e ripartire con un'ISA e un'architettura completamente nuova, e in realtà lo hanno già fatto con ITANIUM. Hanno adottato un'architettura in-order e un ISA VLIW supportati da un back-end di prim'ordine, dando così a quei processori un'efficienza niente male. Nel normale codice applicativo, però, spesso un x86 è più veloce in quanto il codice delle normali applicazioni spesso è poco parallelizzabile ed è pieno di salti condizionali. Nelle applicazioni in cui il core VLIW può stendere la gambe, però, ITANIUM è un missile!

Comunque siamo finito abbastanza off-topic...

Ciao.

[macfanboy]

Originariamente inviato da shodan

Oltre a questo, considera che avere un'ISA esterna di tipo CISC comporta un migliore uso della RAM e della cache, in quanto le istruzioni sono più "dense". Uno dei motivi per cui i processori RISC sono stati i primi a usare cache di una certa dimensione (l'Alpha aveva 96 KB di L2 on-die) è proprio perchè le loro istruzioni occupavano, mediamente, più memoria

Gli ARM sono (credo) gli unici tra i processori RISC ad avere una versione delle istruzioni "compattata", le THUMB-2. Questo annulla praticamente l'unico vantaggio teorico dell'architettura CISC rispetto ai RISC.

Originariamente inviato da shodan

Ovvio che, oltre una certa soglia, aumentare la velocità del processore sia inefficiente da un punto di vista energetico, ma questo è il prezzo da pagare per avere le migliori prestazioni in assoluto. Per esempio, un'archiettura out-of-order consuma sicuramente di più di una in-order, ma nel codice con molti salti e/o accessi alla memoria è incontestabilmente più veloce

Non è un'esclusiva degli x86 l'architettura Out-of-order. Anzi credo sia nata sui Power IBM (ovviamente RISC). La cosa interessante è che ora IBM l'ha abbandonata nei suoi processori di ultima generazione come i Cell e i Power 6.

Comunque leggevo sull'articolo di wikipedia che una caratteristica "simpatica" dell'ISA degli ARM che è tutte le istruzioni possono essere eseguite condizionalmente. Questo un po' compensa la mancanza della branch-prediction e rende il codice ulteriormente compatto.

[shodan]

Originariamente inviato da macfanboy

Gli ARM sono (credo) gli unici tra i processori RISC ad avere una versione delle istruzioni "compattata", le THUMB-2. Questo annulla praticamente l'unico vantaggio teorico dell'architettura CISC rispetto ai RISC.

Vero, ma il set di istruzioni THUMB non è ricco come quello ARM nativo. Da quanto ho letto, è da usare in certe determinate situazioni, spesso in accoppiata al codice ARM. Dato che parliamo di microcontroller, però, il set THUMB è un vantaggio non da poco, dato che è stato inventato proprio per questo spettro di utilizzo.

Non è un'esclusiva degli x86 l'architettura Out-of-order. Anzi credo sia nata sui Power IBM (ovviamente RISC). La cosa interessante è che ora IBM l'ha abbandonata nei suoi processori di ultima generazione come i Cell e i Power 6.

Assolutamente si, l'ooo non è nata su x86. Al momento, però, gli x86 ne sono forse i massimi rappresentanti in quanto ogni iterazione dal K5/P6 in poi ha cercato di aumentare il numero di istruzioni on the fly in un determinato momento.

Riguardo al Cell/Power6: l'utilizzo di uno schema in-order permette di risparmiare parecchi transistor rispetto a un ooo, transistor che possono essere dedicati a "rinforzare" il back-end con un numero maggiore di porte/execution unit. Di conseguenza i processori in-order mostrano spesso performance di picco molto elevate, ma è più difficile mantene elevato il livello di performance medio. La verità, probabilmente, è che tutto dipende dalla tipologia di applicazione che si intende usare: se questa ha pochi salti e accessi alla memoria e, magari, è facilmente parallelizzabile, i core in-order si troveranno a loro agio (non a caso Labaree dovrebbe essere in-order). Viceversa, nell'uso comune di un PC, i processi ooo sono nettamente più veloci.

Comunque leggevo sull'articolo di wikipedia che una caratteristica "simpatica" dell'ISA degli ARM che è tutte le istruzioni possono essere eseguite condizionalmente. Questo un po' compensa la mancanza della branch-prediction e rende il codice ulteriormente compatto.

Questa non la sapevo... grazie dell'interessante info