Round-up ARM board: sfida al Re x86

[Alessio89]

Mi chiedo in quanti la vorranno un'altra generazione di console

[gridracedriver]

Mi chiedo in quanti la vorranno un'altra generazione di console

magari tu sai qualcosa che io o altri non sappiamo, ma guardando i numeri di vendita dell'attuale generazione la PS4 ha venduto quasi il doppio rispetto alla PS3, mentre la One è in linea con la 360...
PS4 18.5 M ~1 anno
PS3 85 M ~8 anni, media annuale ~10.6 M
One 11 M ~1 anno
360 85 M ~9 anni, media annuale ~9.5 M

PS2 157 M ~12 anni, media annuale ~13.1 M aiutata dal fail xbox
Xbox 25 M ~6 anni, media annuale ~4.1 M

certo il lancio è il periodo d'oro di solito, non per PS3 , ma non sempre e durante il ciclo di vita ci sono alti e bassi di vendita

...poi oh, magari i numeri non vogliono dire nulla

[Alessio89]

Dati "segreti" non ne ho sulle console
Tuttavia le precedenti hanno venduto tanto perché sono state un'eccezione come durata. I dati sulla PS2 vanno presi con le pinze: in occidente è durata nettamente di meno, anche se è stata lo stesso nei negozi dopo il lancio della PS3, mentre nei paesi emergenti (sud america ed asia, ma anche est europa) ha continuato a vendere e continua a vendere tutt'ora. Mentre la XBOX in quei mercati non conta nulla.
Passare ad ARM sarà un calcio nel sedere per gli sviluppatori. Le CPU delle console attuali, seppure non recentissime e non potentissime, hanno un sacco di estensioni e funzionalità che su ARM te le scordi anche nei prossimi 10 anni. E si, su console vai ad utilizzare un sacco di funzioni intrinsics e pure assembly se il compilatore non fornisce il risultato migliore desiderato.

[Cesoia]

Personalmente non vedo l'ora di mettere le mani su qualche scheda dotata almeno di SoC quad o octa core Cortex-A57 o superiore. Considerato il salto accorso tra Cortex-A7 a Cortex-A9, in questo caso il boost prestazionale dovrebbe essere terrificante.

Sarà, ma il tipo di licenza di ARM e la sua ISA continuano a limitare le prestazioni di ARM.
La prima crea una miriade di implementazioni de-facto diverse tra loro. La seconda permutata con la prima obbliga spesso gli sviluppatori a sostituirsi al compilatore e a scrivere codice assembly di mano loro, codice che quando si va da un SoC ad un altro rischia di dover essere riscritto.

Vero ma questo pero' e' valido per l'ISA a 32 bit di ARM. Con L'ARM v8 pare che abbiano tirato una bella riga con il passato difatti ci dovrebbe essere una sola ABI quindi una sola interfaccia per tutti ed il set d'istruzioni a 64 bit, realizzato ex novo. Per quanto riguarda la licenza ARM e' vero che nel corso degli anni l'azienda inglese si e' letteralmente prostituita pur di accontentare tutti i clienti non privilegiando in alcun modo la coerenza. Parliamo comunque di un processore RISC nato come general purpose ed adattato successivamente ai piu' disparati usi: non credo che neppure il MIPS abbia mai avuto un trattamento del genere. La versatilita' alla fine l'han pagata cara.

Su x86 non è così: l'implementazione di fondo è sempre quella, le varie estensioni create da Intel ed AMD alla fine le ritrovi in tutte le architetture dopo un po' se queste si sono rilevate fondamentali. Questo fatto unito ad un ISA CISC permette di scrivere compilatori efficienti in quando quando si scrive dell'assembly si è sicuri che questo verrà tradotto in microcodice RISC nel migliore dei modi da parte del traduttore della CPU: nel caso l'idea sia giusta si ottiene del codice molto performante, altrimenti ci si tira la zappa sui piedi. Tutto questo fa si che raramente lo sviluppatore si sostituisce al compilatore e si metta a scrivere di pugno suo del codice assembly.

X86 da questo punto di vista e' anche peggio. Intel e' riuscita a realizzare l'impensabile: partire da un set d'istruzioni limitato ed incoerente (gia' all'epoca l'ISA 68k e vax erano molto meglio..) tenerlo in vita oltremodo (da un punto di vista ingegneristico e' un pugno nello stomaco) e caricarlo di centinaia di istruzioni un tanto al kilo spesso utilizzate qualche anno giusto il tempo di avere le successive mantendo in vita le precedenti (Viva la retrocompatibilita'!).Ma dimenticavo: limpensabile sta appunto nell' aver creato questa porcheria rimanendo nel solo segmento general purpose! Il che e' piuttosto grave. Devo tuttavia riconoscere che i tool di sviluppo Intel sono eccezionali a realizzare dei binari cosi prestanti.

La fortuna attuale di ARM è che la tecnologia relativa alla memoria primaria è la stessa da prima che io nascessi Se questa un giorno finalmente cambierà e si troncherà di netto la differenza prestazionale fra CPU e memoria primaria, allora l'elevato numero di registri di ARM (che ne ha il doppio rispetto ad x86 per le operazioni general purpose) smetterà di essere quell'arma prestazionale che ha consentito ad ARM di avvicinarsi ad x86 nel low power. Chissà quando intel lo capirà... Ovviamente parlo di tutto l'ambaradam ad essa collegata, non solo la tipologia di memoria. Pertanto no, HBM per quanto sia potenzialmente un bel salto rispetto alle DDR non è la soluzione, al massimo potrebbe esserne solo una parte, quella anche meno significativa.

La gerarchia di memoria ed in particolare la primaria (credo che tu intenda questo..) fa parte dell'informatica da decenni e chissa' se mai vedremo qualcosa di differente. Difatti l'approccio RISC (almeno quello di stanford aka MIPS) e' stata la risposta piu' sensata,valida ancora oggi, a quel genere di problematiche.
Tutte le architetture CISC nel corso degli anni '80 son diventate obsolete. Se volevi prestazioni e scalabilita' dovevi passare per la logica cablata. Nonostante cio',la fortuna e la capacita' realizzativa di Intel (vedi nucleo RISC con traduttori) e naturalmente l'economicita' del PC ha differito di oltre vent'anni l'obsolescenza di un'ISA ormai al limite (secondo me) dello sviluppo. Oggi la sfida e' l'efficienza ed in questo x86 proprio non c'e'. Fin'ora si e' salvata a suon di nodi avanzati. Ma quanto puo' durare?

[gridracedriver]

Dati "segreti" non ne ho sulle console
Tuttavia le precedenti hanno venduto tanto perché sono state un'eccezione come durata. I dati sulla PS2 vanno presi con le pinze: in occidente è durata nettamente di meno, anche se è stata lo stesso nei negozi dopo il lancio della PS3, mentre nei paesi emergenti (sud america ed asia, ma anche est europa) ha continuato a vendere e continua a vendere tutt'ora. Mentre la XBOX in quei mercati non conta nulla.
Passare ad ARM sarà un calcio nel sedere per gli sviluppatori. Le CPU delle console attuali, seppure non recentissime e non potentissime, hanno un sacco di estensioni e funzionalità che su ARM te le scordi anche nei prossimi 10 anni. E si, su console vai ad utilizzare un sacco di funzioni intrinsics e pure assembly se il compilatore non fornisce il risultato migliore desiderato.

posso accettare questo discorso sul piano tecnico, ma a credere che nessuno vorrà un altra generazione di console, mi sembra, ecco come dire, un attimino azzardato
vedi dal punto di vista tecnico, da mero ignorante quale sono in materia, credo anch'io che opteranno per ARM, nel 2020 circa vuoi che per quella necessità di calcolo non si sia livellato il divario?
tra l'altro ARM è pure nel consorzio HSA se non sbaglio, qualcosa vorrà dire...

[Alessio89]

Vero ma questo pero' e' valido per l'ISA a 32 bit di ARM. Con L'ARM v8 pare che abbiano tirato una bella riga con il passato difatti ci dovrebbe essere una sola ABI quindi una sola interfaccia per tutti ed il set d'istruzioni a 64 bit, realizzato ex novo. Per quanto riguarda la licenza ARM e' vero che nel corso degli anni l'azienda inglese si e' letteralmente prostituita pur di accontentare tutti i clienti non privilegiando in alcun modo la coerenza. Parliamo comunque di un processore RISC nato come general purpose ed adattato successivamente ai piu' disparati usi: non credo che neppure il MIPS abbia mai avuto un trattamento del genere. La versatilita' alla fine l'han pagata cara.

Con ARM-64 hai il doppio dei registri ed il supporto obbligatorio a NEON, né più ne meno. ARM NEON è imparagonabile alle diverse estensioni di X86. 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.

X86 da questo punto di vista e' anche peggio. Intel e' riuscita a realizzare l'impensabile: partire da un set d'istruzioni limitato ed incoerente (gia' all'epoca l'ISA 68k e vax erano molto meglio..) tenerlo in vita oltremodo (da un punto di vista ingegneristico e' un pugno nello stomaco) e caricarlo di centinaia di istruzioni un tanto al kilo spesso utilizzate qualche anno giusto il tempo di avere le successive mantendo in vita le precedenti (Viva la retrocompatibilita'!).Ma dimenticavo: limpensabile sta appunto nell' aver creato questa porcheria rimanendo nel solo segmento general purpose! Il che e' piuttosto grave. Devo tuttavia riconoscere che i tool di sviluppo Intel sono eccezionali a realizzare dei binari cosi prestanti.

C'è un po' di confusione: l'ISA di x86 è CISC, ma le CPU sono implementate come RISC, ed è così dall'era 486 e compatibili, anzi sono molto più RISC le CPU x86 (molto simili a dei MIPS internamente) che le stesse CPU ARM. 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.
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).

La gerarchia di memoria ed in particolare la primaria (credo che tu intenda questo..) fa parte dell'informatica da decenni e chissa' se mai vedremo qualcosa di differente. Difatti l'approccio RISC (almeno quello di stanford aka MIPS) e' stata la risposta piu' sensata,valida ancora oggi, a quel genere di problematiche.
Tutte le architetture CISC nel corso degli anni '80 son diventate obsolete. Se volevi prestazioni e scalabilita' dovevi passare per la logica cablata. Nonostante cio',la fortuna e la capacita' realizzativa di Intel (vedi nucleo RISC con traduttori) e naturalmente l'economicita' del PC ha differito di oltre vent'anni l'obsolescenza di un'ISA ormai al limite (secondo me) dello sviluppo. Oggi la sfida e' l'efficienza ed in questo x86 proprio non c'e'. Fin'ora si e' salvata a suon di nodi avanzati. Ma quanto puo' durare?

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) è 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.
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. 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).
Se ti interessa la velocità di esecuzione del programma allora ti interessa che la memoria venga gestita al meglio in termini di performance.
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. 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.

[Alessio89]

posso accettare questo discorso sul piano tecnico, ma a credere che nessuno vorrà un altra generazione di console, mi sembra, ecco come dire, un attimino azzardato
vedi dal punto di vista tecnico, da mero ignorante quale sono in materia, credo anch'io che opteranno per ARM, nel 2020 circa vuoi che per quella necessità di calcolo non si sia livellato il divario?
tra l'altro ARM è pure nel consorzio HSA se non sbaglio, qualcosa vorrà dire...

Dopo 3-4 anni, aver speso suon di 70-80€ a gioco e abbonamento online mesile, il dover cambiar console mi sentirei preso per il culo. Soprattutto quando vedo che i giochi PC difficilmente costano oltre 49-59€, e spesso anche molto meno. Se poi le prossime API grafiche faranno il loro sporco lavoro, mi sentirei ancora più preso per il culo.
ARM nel 2020 sarà sicuramente molto avanti, ma dubito fortemente che nel 2020 x86 rimarrà ferma a guardare. Ma poi, voi veramente avete tutta sta voglia di mandare a fanculo un ISA che mi fa girare tutto il software che ho senza problemi o quasi? Semmai dovete sperare che Intel si debba di nuovo a mettersi in competizione con un'altro produttore. Senza contare che ARM sarebbe un'incubo per la compatibilità e la resa del suo stesso software fra macchine differenti.

[dobermann77]

Per i server ARM non sono più così sicuro

Ecco il consueto allineamento alla posizione di Dobermann.
Io ho spalato merda sui server ARM da quando hanno accostato la parola server alla parola ARM

[Alessio89]

I server ARM sarebbero anche interessanti. Ma il mercato si sta dividendo in cloud e dedicati ad alte prestazioni. i dedicati di fascia bassa vanno bene giusto per usi poco più che casalinghi o in piccole aziende.
A me il cloud non piace proprio come concetto, ha dei vantaggi come i backup automatici di cui non devi curartene ma non mi piace affatto non avere il controllo del software e delle macchine che uso, tantomeno non possederli (soprattutto il software). Ma questi sono i miei gusti personali.
Se ARM Holding farà grandi investimenti nel cloud, sicuramente avranno ottime chance di entrare ricavarsi una bella nicchia nei server (cloud/virtuali) a basse prestazioni, il rapporto consumi/performance/prezzo sarebbe dalla loro parte. Le attuali offerte ARM per server fanno uso di tecnologie proprietarie, Intel (e pure la scomparsa dal settore AMD) hanno estensioni più omogenee (per non chiamarle standard).

[tennents]

articolo molto interessante
se trovate altre board/minipc verranno integrati?
avrei sempre voluto provare qualcosa come la Cubieboard 4 (con l'A80 dovrebbe essere un piccolo mostro, 4A15 + A7 e la PowerVR G6230)
oppure OdroiD XU3 (con Exynos5422 4A15 + 4A7 e Mali-T628 MP6)
o il mini pc Ugoos UT3 (con RK3288 4A17 e Mali-T764)