Round-up ARM board: sfida al Re x86

[Fottemberg]

Se riusciamo a farci mandare qualcosa realizzeremo una comparativa molto più ampia.

[Rafy93]

Personalmente sono molto curioso di una review sul Raspberry Pi 2,non tanto per la sua potenza pura( il suo HW non è paragonabile ad altri chip ARM) ma per il suo prezzo molto aggressivo, curioso anche dei suoi consumi.
In ogni caso, IMHO un giorno questi "chippettini" sostituiranno la fascia bassa delle CPU x86, penso in particolare ai sistemi per casa e ufficio,del resto gestiscono già egregiamente documenti e navigazione web.

[quarantadue]

Se riusciamo a farci mandare qualcosa realizzeremo una comparativa molto più ampia.

Esiste un modo (teorico? pratico?) per farsi un'idea precisa di cosa significherebbe un evoluzione multi-core spinta, o multi-processing, con parallelo sviluppo delle Applicazioni per girare su cluster di piccoli ARM invece che su grossi x86 singoli o al massimo dual?

Mi piacerebbe che anche gli A(n) di Apple potessero rientrare nei confronti, sebbene l'ottimizzazione dei software consenta sempre ad Apple di minimizzare le potenze impiegate invece che inseguire i livelli prestazionali puri.

Io naturalmente la vedo in ottica Apple in cui il passaggio ad ARM è nelle paure di Brian Krzanich e Stacy Smith.
Per Apple riscrivere il proprio software, e farlo riscrivere alle terze parti, è un'abitudine con cadenza decennale. Ora però è andata ben oltre il software Universal Binary del 2006. Ha anche allestito tutto quanto il necessario per farlo con comodità: dal programma Swift al compilatore LLVM e il run time di Objective C integrati in Xcode per non risentire delle differenze di partenza fra OS X ed iOS o non tralasciare nulla delle potenzialità degli ambienti di programmazione originali di ogni Applicazione. La riscrittura multipiattaforma dei software in bundle è pressoché completata. I software di produttività sono persino disponibili a tutti sul web anche se per ora ancora in versione beta (e ci vorrà ancora qualche tempo per raggiungere i livelli di iWork '09 del 2013).

[dobermann77]

In ogni caso, IMHO un giorno questi "chippettini" sostituiranno la fascia bassa delle CPU x86, penso in particolare ai sistemi per casa e ufficio,del resto gestiscono già egregiamente documenti e navigazione web.

E perché mai? Che vantaggi offrono rispetto alle CPU x86? E Windows?

Tra l'altro sull'articolo si dice che Windows 10 per ARM ci sarà... fonte?
Io vi do' questa "DisARMed"
http://www.extremetech.com/computing/19 ... t-doubtful

Non vorrei che siccome hanno cambiato nome a Windows Phone 10 in Windows 10 for Phones,
e questo ci sarà sicuramente per ARM, allora si fosse arrivati a generalizzazioni strane...

[Alessio89]

Windows 10 per ARM = Windows per telefoni e piccoli tablet (Che tra l'altro avranno lo stesso sistema operativo). Fine. Se Apple vuole portare ARM sui potatili voglio vedere che scusa si troveranno per convincere gli IMacachi che il loro software non più funzionante sia una feature.

[Fottemberg]

Da quello che ho capito, Windows vuole far sì che le applicazioni per Windows Desktop possano funzionare su Windows Mobile e viceversa senza problemi, quindi alla fine la distinzione tra i due SO la farà l'interfaccia grafica.

[Sasha]

alla fine

[Cesoia]

Con ARM-64 hai il doppio dei registri ed il supporto obbligatorio a NEON, né più ne meno.

Con ARM-64 hai un datapath esteso,unita' di calcolo obbligatorie quali NEON e VFP,ABI unificato,ISA a 64 bit complementare,semplificata e separata (rispetto al 32). La retrocompatibilita' con i 32 bit risulta esserci ma solo con solo con la revisione AArch32 del set.
La situazione e' abbastanza differente rispetto al metro di paragone x86 a 32 e 64 bit dove quest'ultima risulta essere una semplice estensione della prima.

http://www.realworldtech.com/arm64/2/

Sostanzialmente,in ARM hanno semplificato,ridotto e corretto anziche' limitarsi ad aggiungere.

ARM NEON è imparagonabile alle diverse estensioni di X86.

ARM NEON non e' altro che l'unita' SIMD del RISC ARM alla pari di VIS per SPARC,Altivec per PowerPC,ecc.

Comunque concordo con te che e' imparagonabile alle diverse estensioni x86.NEON mantiene la sua specificita' operativa. Storicamente i RISC sono stati dotati di FPU molto potenti e ben progettate sia a livello di silicio sia a livello di ISA. Cosa che ovviamente non ha mai avuto l'x87 di Intel. Le varie estensioni x86 vanno quindi ad affiancare ma molto piu' spesso a sostituire le x87 che sono state da sempre il tallone d'achille dell'architettura.

Il fatto che lo diano in licenza e che chiunque ci possa fare quel che vuole è il motivo per cui i compilatori ARM come GCC fanno pietà e chi sviluppa protti basati su ARM è praticamente obbligato a fornire un proprio ambiente di sviluppo ottimizzato se vuole far rendere le sue macchine.

ARM 64 dovrebbe costringere i produttori a standarizzare il percorso evolutivo dell'architettura. Per quanto riguarda GCC,purtroppo,fa' pieta' su tutte le architetture e non da ieri. Non c'e' architettura che abbia un supporto soddisfacente.Ho avuto esperienze negative sia con SPARC sia con Alpha sulla quale compilava addirittura codice errato. Di certo Alpha non ha mai sofferto dei problemi delle architetture custom di ARM. Non credo quindi che GCC su ARM faccia pieta' per quel motivo li'.Semmai e' un motivo ulteriore per peggiorare la situazione del compilatore.
Ho la netta sensazione che molti progetti opensource si limitino a “fare” il lavoro anziche' preoccuparsi di farlo bene.

C'è un po' di confusione: l'ISA di x86 è CISC, ma le CPU sono implementate come RISC, ed è così dall'era 486 e compatibili,

Difatti e' quello che avevo scritto: nucleo RISC + traduttori).Precisamente dall'archiettura 686.

anzi sono molto più RISC le CPU x86 (molto simili a dei MIPS internamente) che le stesse CPU ARM.

Su questo ci sarebbe da discutere. Il design RISC impone dei vincoli realizzativi stringenti e semplificati rendendo l'ISA ed il silicio sottostante intimamente legati fra loro. E' sempre stato cosi'.Sicuramente internamente le CPU x86 lo sono. Tuttavia anteporre un livello di traduzione fra l'ISA x86 e ed il nucleo RISC (slegando completamente il set “visibile” dal silicio) come avviene nei moderni x86 e' una bestialita' senza pari. Probabilmente queste scelte sono il frutto di un compromesso che ha permesso ad intel di crescere enormemente in questi vent'anni ma fermiamoci a questo. L'architettura e' andata molto bene quando si trattava di “crescere” ed “aggiungere” mentre i problemi sono sorti nel momento in cui era necessario ridurre e mantenere un buon compromesso energetico. Il nodo realizzativo di certo aiuta ma ad oggi,di variazioni importanti sull'architettura non se ne sono visti.

x86 è nato nell'era 16-bit, nell'era 16-bit l'unica soluzione veramente sensata era fare ISA e hardware CISC a meno che non si volesse fare processori per lavatrici. Le cose poi sono cambiate.

Vero. Difatti tutti i sistemi CISC hanno trovato degna sepoltura fra la fine degli anni '80 e la meta' degli anni '90.Non cosi' e' stato per x86 dove Intel ha trovato il modo di ancorarsi ad una soluzione che non ha piu' senso da troppo tempo.

Il creare il binario alla fine non è un problema, l'ISA di x86 è sempre coerente nel corso degli anni e delle generazioni (e per fortuna che non è passata quella porcheria di IA64 invece!), il fatto che l'ISA (e di conseguenza il binario) sia slegato dal microcodice della CPU taglia la tesa al toro e permette a chi sviluppa le CPU di fare quello che vogliono una volta aggiornato il controller di traduzione (che ha impatto prestazionale del tutto ininfluente).

L'x86 e' un insieme di aggiunte successive senza una visione globale di quello che si andava ad implementare. E' come far lavorare diversi team di sviluppo senza un capoprogetto. Non vorrei esserci!
il P4 ha avuto molto in comune con Itanium (a livello di pipeline) e forse la sua inefficienza nasceva proprio da quello.IA64 era fantastico sulla carta,ma demandare la complessita' al compilatore si e' rivelato piu' difficile di quanto si pensasse.
Come detto sopra,aggiungere un livello di complessita' fra ISA x86 e nucleo RISC senza avere il coraggio di tirare una riga e ricominciare da capo (Intel come capofila poteva e doveva farlo) e' stata la peggior dimostrazione di quello che e' Intel.

Non è questione di gerarchie delle memorie, quella è ovvia che vi sia, il problema è il concetto di memoria, come essa è implementata e come essa comunica con la CPU.
L'approccio register-register di ARM (che non significa essere per forza un'architettura RISC)

I RISC sono tutti registro-registro. Che poi sia implementata anche altrove,questo,non lo escludo.

è perfetta per quello che è stata pensata ARM: bassi consumi e basse prestazioni, ambiti che, almeno inizialmente, erano prevalentemente occupati da operazioni di calcolo che si ripetevano spesso prima di accedere alla memoria per ottenere nuovi input, pertanto il register-register si adattava benissimo.

Errato. ARM e' stato concepito e sviluppato per le alte prestazioni. Archimedes ne era la dimostrazione. Pipeline cortissima e logica cablata. I tecnici,mutuando le ricerche del Berkley RISC II hanno preferito semplificarlo evitando l'implementazione del register window cosa avvenuta sullo SPARC. A posteriori la scelta si e' rivelata vicente.

L'adeguamento al mercato embedded avvenuto solo in fasi successive ha modificato pesantemente lo sviluppo (standarizzato e coerente) dell'architettura.

Nel gestire la memoria gli ARM sono polverizzati da x86 che adotta un approccio register-memory: x86 non è nato per elettrodomestici o telefoni, è nato per ambienti dove la potenza di calcolo conta molto e dove le operazioni di load e store sono frequenti.

Stai descrivendo una delle motivazioni che portarono a precise scelte progettuali che portarono alla realizzazione dell'architettura RISC di Stanford nei primi anni '80 da parte del Prof. Hennessy. Proprio perche' l'inefficienza e la limitazione dell'approccio registo-memoria dei CISC presenti allora,come x86,erano intollerabili. Oggi x86 e' spinto da hw sottostante completamente differente. Magari le prestazioni non sono esattamente dovute al set d'istruzioni x86,giusto? Poi,scusa,me lo confronti con un'architettura embedded? Attendiamo almeno di avere qualcosa di piu' confrontabile,magari da AMD, e poi vediamo.

Il compito di un programma alla fine è prendere dei dati input, trasformarli e ritornarli in output (che non è affatto l'implementazione 1:1:1 fra funzione matematica - software - hardware come i boriosi della programmazione funzionale vogliono far credere - fine sfottò a tutti i matematici falliti che giocano a fare gli sviluppatori software).

X86 e' nata come architettura general purpose limitata ed a bassissimo costo. Le sue caratteristiche rispecchiano il periodo: meta' anni '70. Le prestazioni fino a meta' degli anni '90 con l'arrivo dell'i686 non erano nemmeno paragonabili ai sistemi RISC utilizzati in qualunque ambito lavorativo e professionale. La fortuna di questa architettura e' agganciata alla diffusione dovuta al successo del PC IBM,Microsoft Windows come standard ed il costo relativamente basso. Solo in seguito sono arrivate le prestazioni che hanno ribaltato definitivamente la situazione:un po' quello che rischia di fare ARM oggi,nei confronti del monopolista x86.

Se ti interessa la velocità di esecuzione del programma allora ti interessa che la memoria venga gestita al meglio in termini di performance.

Vero. Ma oggi,in generale,non contano piu' solo le performance straripanti garantite da x86 se lo scotto da pagare e' l'efficienza.

Il fatto dei nodi di produzione colpisce e colpirà entrambi, ovvio che se fai qualcosa di più complesso allora i costi aumentano ma sarà sempre così. Se credete che un giorno ARM soppianterà x86 su server e PC ad alte prestazioni sbagliate di grosso.

Mai detto questo e tutto sommato non ho mai sentito dire ad ARM nulla del genere. Piuttosto l'obiettivo e' dimostrare che si possono fare le stesse cose a performance paragonabili con molta meno potenza e meno dispendio di energia.

Chi notoriamente alimenta questo genere di falso confronto (potenza pura) in cui ovviamente ARM risulta perdente e' proprio il marketing di Intel,lo stesso che ci ha raccontato per vent'anni che i Gigaherz erano tutto,lo stesso che ci voleva convincere che un P4 era meglio di un Athlon64.

Lo stesso che evita di parlare accuratamente di efficienza,inventandosi termini fantasiosi come l'SDP al posto del piu' onesto TDP.

Se poi c'è qualcuno che vuole rifilare delle console fra 3-4 ad un pubblico con un hardware forse paragonabile ad un PC di fascia medio-bassa di oggi allora che facciano pure, tanto ormai l'intero mercato delle console da salotto è in inferiorità dal mercato PC-gaming, vorrà dire che il secondo continuerà a crescere, tanto meglio: meno gamepad = più tastiere = gameplay meno da bradipi ritardati sotto l'effetto si overdose d'assenzio.

La verita' e' che Intel,le sue carte con quell'architettura e con quell'approccio evolutivo se l'e' giocate tutte. Ora tiene botta a costi proibitivi con i nodi avanzati. Ma fino a quando? Non bastasse questo,il peso ed il ruolo centrale della CPU cosi' come e' stata concepita fino ad oggi e' destinato ad essere superato da sistemi sempre piu' specializzati. ARM e' pronta,Intel no.
Vedremo alla fine,dalla riva del fiume,quale cadavere passera'.

[Rafy93]

In ogni caso, IMHO un giorno questi "chippettini" sostituiranno la fascia bassa delle CPU x86, penso in particolare ai sistemi per casa e ufficio,del resto gestiscono già egregiamente documenti e navigazione web.

E perché mai? Che vantaggi offrono rispetto alle CPU x86? E Windows?
[...]

- Dimensioni delle piattaforme ridotte (sono grandi quanto delle schede telefoniche/carte di credito)
- Consumi ridicoli ( si alimentano con dei classici caricabatterie per smartphone, 5V/1.5A bastano)
- Prezzi più aggressivi ( questi prodotti basati su ARM hanno un costo che si aggira intorno ai 60$, aggiungici un supporto per la memoria SD/microSD, antennina se serve ed un "case" e non superi i 100$ per un sistema completo)
- Sistema totalmente fanless ( TDP di circa 2 Watt, cosa vuoi di più? certo alcuni sistemi fanless in casa intel già ci sono, ma con ARM basta un 4 alette di alluminio contate e stai fresco senza contare poi che il prezzo comunque non è paragonabile,penso ai core M)
Io da noob, ho notato questi punti, che ovviamente possono mutare nel tempo e possono anche essere sbagliati resta comunque il fatto che sono un paio di anni che mi chiedo se i chip ARM avessero "tozzato" un giorno la fascia bassa delle cpu x86 lato performance, ebbene una mezza risposta questo articolo l'ha data...

Da quello che ho capito, Windows vuole far sì che le applicazioni per Windows Desktop possano funzionare su Windows Mobile e viceversa senza problemi, quindi alla fine la distinzione tra i due SO la farà l'interfaccia grafica.

Questa cosa M$ la voleva già fare con W8, mi ricordo ancora il voler "unificare" tutte le piattaforme, e partì se non erro dai kernel (gli smartphone basati su WP7 infatti non furono aggiornati per questa rogna) e dall'interfaccia "metro", e voleva fare in modo che una stessa applicazione sul cell si trovasse anche su PC e tablet(e viceversa) con "poche settimane di lavoro" per il porting, con W10 questa cosa sembra essere tornata ancora più forte, unificando del tutto anche i sistemi basati su ARM e x86, anche se non so come, mi sembra alquanto difficile come cosa, ma sarebbe senza alcun dubbio interessante.
P.S. come sempre complimenti per l'articolo, interessante come sempre
P.P.S. ma quanto ne sapete voi di B&C? A volte trovo più contenuti nei vostri commenti che in interi articoli su altri portali
Benedetto sia il giorno in cui vi ho trovato

[Sasha]

faccio solo notare che per alimentare queste SBC serve un alimentatore e non un caricabatterie da smartphone... gli alimentatori erogano una corrente costante, i caricabatterie generalmente degli impulsi di varia durata e frequenza (tot al minuto) a seconda del livello di carica della batteria...

ci siam capiti in ogni caso, ma per chi legge i commenti di questa recensione per orientarsi sull'acquisto ed è un pò a digiuno sull'argomento, è bene far notare la differenza