Un chip RISC-V promette di demolire Apple M1. Ecco chi c'è dietro e di cosa si tratta

[Redazione di Hardware Upg]

Link alla notizia: https://www.hwupgrade.it/news/cpu/un...tta_93873.html

La californiana Micro Magic afferma di aver messo a punto un core basato su ISA RISC-V che non teme confronti, nemmeno l'interessantissimo Apple M1 su base ARM, grazie a frequenze intorno ai 5 GHz e consumi estremamente ridotti.

Click sul link per visualizzare la notizia.

[phmk]

..."Perciò, per aziende che necessitano di ridurre l'uso della batteria, ad esempio Tesla, possiamo raggiungere le prestazioni necessarie"...
Perciò fammi capire, guardano al consumo di qualche chip e "tralasciano" i motori ... su un'auto ???

[pipperon]

sono sempre esistiti processori molto performanti, poi, vuoi per il vecchiume microsoft, vuoi per i costi, vuoi perche' il resto del computer non gli stava dietro sono tutti affondati.

Apple non voleva pagare di piu' i chip power,
arm e' rimasta nel congelatore piu' di 10 anni rinascendo in strambi dispositivi (proma del boom del celli),
sparc era eccellente,
come del resto non ricordare alpha che e' morto per questioni politiche piu' che prestazionali,
ed infine il simpatico Z8000 che non si e' filato nessuno.

Ovviamente rifacendo da zero la isa pensandola per il mondo attuale e senza l'idea di essere un 6502 pompato come ARM o un vecchio rottame come l'8080 tirato alla spasmo permette rendimenti piu' alti.

Sara' da vedere se questo e' sufficiente per far ricompilare tutto per un nuovo processore, certo per android e' piu' semplice, alla fine linux e' stato compilato persino per oggetti incredibili, ma non e' detto.

Il mondo windows e' sempre stato arroccato sull'x86, spesso neppure compilato per i processori attuali, ma quelli di almeno 5 anni prima.

Il mondo apple sta ragionando su ARM e l'embedded ha tanta roba con 68000, Z80, arm, soprattutto arm.

e' difficile a dirsi se avra' successo, del resto quando AMD sverniciava i vari pentium e Cyrix era una valida alternativa manco in un piccolo stagno si riusci a salire di quote.

L'unica caratteristica che smuove le acque e' l'isa open... ma la domanda su compatibilita' fra diversi fornitori, e fra versioni, e' una bella domanda.
Ricordiamo Linux agli inizi che molti programmi per una distro per farli funziare su di un'altra era dura?
Non e' che ti fai tutto un progetto miliardario e poi il chip nuovo non e' compatibile.

Solo chi ha la palla di cristallo ha certezze

[pipperon]

Originariamente inviato da phmk

..."Perciò, per aziende che necessitano di ridurre l'uso della batteria, ad esempio Tesla, possiamo raggiungere le prestazioni necessarie"...
Perciò fammi capire, guardano al consumo di qualche chip e "tralasciano" i motori ... su un'auto ???

Bisogna parlare di auto elettriche: sarà un bagno di sangue e chi e' dentro, anche solo per sentito dire, e' ricco.

[Cfranco]

Originariamente inviato da pipperon

s
Ovviamente rifacendo da zero la isa pensandola per il mondo attuale e senza l'idea di essere un 6502 pompato come ARM o un vecchio rottame come l'8080 tirato alla spasmo permette rendimenti piu' alti.

Guarda che ormai da 20 anni in qua i processori e l'ISA sono praticamente separati
Non dico che puoi prendere qualsiasi processore, sostituirgli il decoder istruzioni con un' altra ISA e farlo andare uguale, ma non manca tanto ( oddio, nel caso di Transmeta l' ISA in teoria si poteva programmare al volo )
E oltretutto le prestazioni migliori le ottieni con le estensioni dedicate, che son tutta roba nuova.

[WarDuck]

Originariamente inviato da pipperon

sono sempre esistiti processori molto performanti, poi, vuoi per il vecchiume microsoft, vuoi per i costi, vuoi perche' il resto del computer non gli stava dietro sono tutti affondati.

Apple non voleva pagare di piu' i chip power,
arm e' rimasta nel congelatore piu' di 10 anni rinascendo in strambi dispositivi (proma del boom del celli),
sparc era eccellente,
come del resto non ricordare alpha che e' morto per questioni politiche piu' che prestazionali,
ed infine il simpatico Z8000 che non si e' filato nessuno.

Ovviamente rifacendo da zero la isa pensandola per il mondo attuale e senza l'idea di essere un 6502 pompato come ARM o un vecchio rottame come l'8080 tirato alla spasmo permette rendimenti piu' alti.

Sara' da vedere se questo e' sufficiente per far ricompilare tutto per un nuovo processore, certo per android e' piu' semplice, alla fine linux e' stato compilato persino per oggetti incredibili, ma non e' detto.

Il mondo windows e' sempre stato arroccato sull'x86, spesso neppure compilato per i processori attuali, ma quelli di almeno 5 anni prima.

Il mondo apple sta ragionando su ARM e l'embedded ha tanta roba con 68000, Z80, arm, soprattutto arm.

e' difficile a dirsi se avra' successo, del resto quando AMD sverniciava i vari pentium e Cyrix era una valida alternativa manco in un piccolo stagno si riusci a salire di quote.

L'unica caratteristica che smuove le acque e' l'isa open... ma la domanda su compatibilita' fra diversi fornitori, e fra versioni, e' una bella domanda.
Ricordiamo Linux agli inizi che molti programmi per una distro per farli funziare su di un'altra era dura?
Non e' che ti fai tutto un progetto miliardario e poi il chip nuovo non e' compatibile.

Solo chi ha la palla di cristallo ha certezze

Windows NT e il kernel attuale di Windows possono tranquillamente supportare processori diversi da quello Intel.

Riguardo le ottimizzazioni non è come dici te. La maggior parte delle distribuzioni Linux oggi in circolazione è compilata per x86_64 con ottimizzazioni generiche. E anche per Windows è sostanzialmente la stessa solfa.

Anzi in alcuni casi Windows richiede istruzioni che non sono incluse nel set "generic" x86_64.

Gli Intel x86 32 bit non fanno molto testo ormai, ma anche in quel caso mi sembra di ricordare che Windows richieda almeno il supporto SSE2 (cosa già inclusa di default in x86_64).

Quindi, a meno di compilarsi a manina tutto (a la Gentoo per capirci), la maggior parte del codice (binario) esistente ha come target x86_64 generic.

Edit: aggiungo ancora, per quanto concerne i kernel dei SO importa relativamente come è compilato di base l'eseguibile, dato che viene distribuito con funzioni aventi diversi livelli di ottimizzazione, sulla base del tipo di architettura. In sostanza a run-time vengono fatti dei controlli e viene usato il codice più opportuno per l'architettura rilevata. Questo è vero anche per quei programmi che richiedono performance elevate (mi vengono in mente i programmi per il calcolo scientifico).

[White_Tree]

Qualcuno ha maggiori info sulla 2da generazione di tale processore?

https://arstechnica.com/science/2019/08/16-bit-risc-v-processor-made-with-carbon-nanutubes/

[Sp3cialFx]

Facciamo finta che siamo nel 2020 e non nel 1990.
Parlare di "ISA x86" come se fosse un vincolo non ha senso perché ormai è 25 anni che le cpu x86 usano il microcode; in altre parole l'ISA x86 non ha corrispondenza nel silicio. Gli x86 sono core RISC con una piccolissima fetta di silicio dedicata alla traduzione tra ISA x86 al microcode.

Ora, se l'M1 di turno EMULANDO VIA SW un x86 gira al 80/85% del nativo, darei per scontato che il traduttore hardware ISA x86 -> microcode che è integrato nelle CPU x86 possa andare anche oltre.

C'è un'ultima considerazione da fare. Il fatto di avere un traduttore HW consente di avere quindi un livello di astrazione in più rispetto alle altre CPU. Il microcode che hai scelto ti è stretto? Cambi microcode, basta adattare di conseguenza il traduttore.

Fatta tutta questa lunga premessa la mia domanda è:
con le risorse / esperienza di Intel e AMD, e con la possibilità che hanno gli x86 di avere sotto il cofano qualsiasi tipo di core piaccia loro, com'è che Apple tira fuori M1, questi tirano fuori un RISC-V, domani arriva Qualcomm con gli 865 e rimangono al palo?

Disclaimer: gradirei risposte TECNICHE per capire qual è il tassello che mi manca, di chiacchiera da bar ne ho già letta a sufficienza quindi i pipponi su innovazione / ISA x86 / memoria unificata e bla bla anche no grazie

[Cfranco]

Originariamente inviato da Sp3cialFx

Ora, se l'M1 di turno EMULANDO VIA SW un x86 gira al 80/85% del nativo, darei per scontato che il traduttore hardware ISA x86 -> microcode che è integrato nelle CPU x86 possa andare anche oltre.

96-97%

Originariamente inviato da Sp3cialFx

Fatta tutta questa lunga premessa la mia domanda è:
con le risorse / esperienza di Intel e AMD, e con la possibilità che hanno gli x86 di avere sotto il cofano qualsiasi tipo di core piaccia loro, com'è che Apple tira fuori M1, questi tirano fuori un RISC-V, domani arriva Qualcomm con gli 865 e rimangono al palo?

Intanto parliamo di CoreMark, un test sintetico che ha poco a che vedere con la realtà
Oltretutto se si parla di punteggio per W ovviamente le cpu a bassissimo consumo hanno un enorme vantaggio rispetto alle cpu ad alta potenza, per cui il discorso che fa questo tizio è ovviamente del tutto irrilevante, la sua cpu ha un punteggio altissimo perché non consuma una mazza, mica perché va forte.
Quando cerchi le prestazioni i Watt aumentano esponenzialmente, e quindi il punteggio cala inevitabilmente.
Sul fatto che Apple M1 batta le cpu low power di Intel la spiegazione è brutalmente semplice: 5nm TMSC contro 14nm Intel è una lotta impari.

[umanoz]

Una risposta tecnica non te la so dare, ma credo sia una questione economica, che senso ha al momento per AMD e Intel competere in quei mercati, profitti e volumi probabilmente non sono ancora al livello per cui valga la pena investire.
Amd non mi pare sia stata proprio ferma al palo, non vedo l'ora che escano i nuovi Epyc

[pabloski]

Originariamente inviato da Sp3cialFx

Ora, se l'M1 di turno EMULANDO VIA SW un x86 gira al 80/85% del nativo, darei per scontato che il traduttore hardware ISA x86 -> microcode che è integrato nelle CPU x86 possa andare anche oltre.

Non è scontato. Rosetta non è un emulatore, ma un traduttore di codice binario. Funziona come le vm jit di .NET e Java. Il codice viene tradotto quando necessario, cercando un buon tradeoff tra latenze e throughput, e poi viene messo in cache il codice nativo. Non sia mai fosse stata seguita la via dell'emulazione o dell'intepretazione...sarebbero nei guai.

Il microcodice invece è un ammasso di routine programmate manualmente ( non vale per tutte le istruzioni dell'ISA "emulata" ) nel linguaggio macchina dell'ISA sottostante. In questo senso è più prestante, in quanto non traduce nulla. E' come chiamare una funzione in C, tranne che il chiamante e il chiamato non sono codificati nello stesso linguaggio macchina. Per le istruzioni più usate, le microoperazioni vengono direttamente generate da un instruction decoder hardware. Cioè non c'è manco una subroutine in rom che viene letta.

Talune istruzioni necessitano però di utilizzare una complessa sequenziazione delle microoperazioni ( gli automi a stati finiti sono la soluzione comune ) ed è qui che s'insinua il dubbio che esprimevo all'inizio. Perchè ovviamente il microsequenziatore non ha a disposizione la ram. Non può scialacquare in 16-32 GB di memoria e cachare tutto il cachabile.

E c'è la questione di quanta incide il legacy. Cioè tu hai transistor che sono presenti solo perchè ci sono funzionalità legacy da mantenere. Questi transistor sono attivi, consumano corrente. Ciò può limitare la quantità di corrente che puoi dare ad altre subunità ( i processori sono oggetti fisici, attraversati da quantità di elettricità notevoli, che vanno dissipate...e la gestione dell'energia implementata nei moderni processori fa i salti mortali, aumentando/diminuendo tensioni e frequenze dinamicamente nelle varie zone del chip ) e quindi le relative prestazioni.

Ma diventa rapidamente un discorso statistico, tant'è che Intel cosa dice del TDP? Che è la media del calore prodotto durante l'esecuzione di certi workload campione, che nei casi reali hanno certe probabilità di essere eseguiti.

Magari un'altra architettura, in quei workload campione, riesce a mantenere i consumi e quindi il calore a livelli più bassi, in modo da poter dare un maggior boost alle unità funzionali, ottenendo un throughput maggiore.

E' quello che è hanno fatto pure gli ingegneri Apple col M1.

In soldoni, meglio bagaglio legacy ti dà (1) più libertà nella progettazione delle unità funzionali ( e se sei bravo le rendi più efficienti ), (2) meno zavorra elettronica da portarsi dietro solo per mantenere cose come la segmentazione ( che non è usata manco per sbaglio in modalità long, cioè quella x86_64 ).

Sia chiaro però che questo ragionamento vale sempre per quei workload tipici. Cioè se impili i lego in un certo ordine, avrai una macchina molto veloce a svolgere il task A, ma magari lentissima nello svolgere il task B. Se li impili in un altro ordine, la situazione cambierà. Ma se B è un task che compare nello 0.001% dei casi reali ( che poi può anche significare che nel corso di una sessione di lavoro il task B occupa lo 0.001% del tempo di computing del macrotask di cui fa parte ), allora la prima soluzione può essere migliore della seconda.

[LMCH]

Originariamente inviato da Cfranco

Guarda che ormai da 20 anni in qua i processori e l'ISA sono praticamente separati
Non dico che puoi prendere qualsiasi processore, sostituirgli il decoder istruzioni con un' altra ISA e farlo andare uguale, ma non manca tanto ( oddio, nel caso di Transmeta l' ISA in teoria si poteva programmare al volo )
E oltretutto le prestazioni migliori le ottieni con le estensioni dedicate, che son tutta roba nuova.

Il set d'istruzioni e l'architettura che lo esegue sono separati ... ma si influenzano reciprocamente in un sacco di modi che uno non si aspetta.

Ad esempio il decoder da istruzioni visibili al programmatore a microOp/macroOp eseguite internamente diventa un problema se crea dei colli di bottiglia riguardo il numero di istruzioni riordinabili e/o eseguibili in parallelo.

E non è che l'M1 abbia un decoder da 8 istruzioni per ciclo contro le 4..5 degli x86-64 più recenti perchè è implementato a 5nm TSMC contro i 7nm TSMC dei Ryzen di AMD ed i 10nm Intel.

I core Arm usati da Apple avevano già un decoder da 6 istruzioni per ciclo nel 2013 (core Cyclone, 28nm), salito a 7 nel 2017 (core Monsoon, 10nm) e poi ad 8 nel 2019 (core Lightning, 7nm).

Il motivo per cui i core Apple sono così è che il rapporto costo/benefici è a favore di decoder più ampi perchè si riesce ad estrarre un maggior numero di istruzioni senza troppe interdipendenze rispetto allo stesso codice compilato per x86-64 (i 16 registri interi in più e le istruzioni più semplici da decodificare velocemente aiutano parecchio) e questo poi ha conseguenze anche sul numero di buffer di riordino ed altre cose a valle del decoder.

[Sp3cialFx]

Originariamente inviato da pabloski

...

O tiri fuori numeri / fonti a suffragio delle tue tesi, o non vieni a dire né che il traduttore implementato in HW è meno performante di un traduttore implementato in SW come Rosetta. Fa la stessa cosa in tempo reale. Se fosse meno performante ovviamente lo implementeresti lato SW. Le CPU x86 hanno visto un sacco di modalità in cui potevano esser messe, potresti fare la modalità "native microcode". Il microcode lo generi a livello di OS con l'equivalente di Rosetta fatto direttamente da Intel / AMD.

Cmq Cfranco dice che l'efficienza è 96/97%. Uno dei due ha torto.


Cfranco: in realtà oltre al nodo produttivo (che poi Intel è al palo ma AMD è comunque ai 7nm) c'è un altro aspetto che nessuno rileva: il numero di transistor. Paradossalmente il gigante tra i "grossi" x86 e il "leggero e agile" M1 è quest'ultimo. Poi si, non sono tutti dedicati alla CPU ma comunque da quello che sembra tra un quarto e un terzo del totale si... comunque un numero molto elevato.

LMCH: scusa ma perché non riordinano le microop al posto del codice x86? Su un M1 con Rosetta il riordino avviene ovviamente dopo aver tradotto il linguaggio macchina x86 in linguaggio macchina ARM. Immagino sarebbe anche più facile... probabilmente non dà gli stessi risultati, anche perché 5 istruzioni x86 non sono 5 istruzioni ARM.

[TheAlchemyst]

Scusate la domanda da non programmatore, ma se si ha una architettura diversa (x86, arm, questa nuova), il problema per avere dei programmi che vi girano non sta soprattutto nel supporto da parte del compilatore? Cioè, se io ho il sorgente di un programma, il porting su un architettura diversa non dipende solamente dal fatto che uso un compilatore che sa tradurre in linguaggio macchina specifico per quell'architettura? Ovviamente se il programma necessità di set di istruzioni che non sono presenti in quella specifica CPU il discorso cambia, bisogno modificare il sorgente. O sbaglio?

[Cfranco]

Originariamente inviato da Sp3cialFx

Cmq Cfranco dice che l'efficienza è 96/97%. Uno dei due ha torto.

Questa era la situazione nel 1998 ( Pentium II )
The microcode engines on current CPUs are about 95% as fast as direct execution
https://archive.arstechnica.com/cpu/...html#Microcode

Presumo che in 20 anni siano riusciti a migliorare ancora qualcosina

[LMCH]

Originariamente inviato da White_Tree

Qualcuno ha maggiori info sulla 2da generazione di tale processore?

https://arstechnica.com/science/2019...bon-nanutubes/

L' RV16X-NANO non era un "vero" Risc-V (nel senso che rispettava le specifiche delle cpu Risc-V). Era una cpu con ISA "derivata" da RV32I in cui registri ed indirizzi venivano ridotti a 16bit.
Serviva solo per dimostrare che era possibile implementare con i nanotubi anche delle cpu "moderne".

[pabloski]

Originariamente inviato da Sp3cialFx

O tiri fuori numeri / fonti a suffragio delle tue tesi, o non vieni a dire né che il traduttore implementato in HW è meno performante di un traduttore implementato in SW come Rosetta.

E dalle...no, non ho numeri da mostrare. Ma già stai sbagliando, perchè nelle CPU non c'è nessun traduttore hardware che traduce al volo dall'ISA esterna a quella interna della CPU. Ripeto che si tratta di (1) un decoder che implementa tanti circuiti, ognuno attivato da un certa istruzione/un certo set d'istruzioni dell'ISA esterna, (2) una rom con dentro delle subroutine scritte nel linguaggio macchina della CPU sottostante per alcune istruzioni dell'ISA esterna. E' totalmente diversa da come funziona un traduttore binario software.

E ribadisco che non c'è una cache, in cui mettere il codice nativo tradotto per poter riutilizzare.

Originariamente inviato da Sp3cialFx

Fa la stessa cosa in tempo reale.

Definisci tempo reale in questo contesto.

Originariamente inviato da Sp3cialFx

Se fosse meno performante ovviamente lo implementeresti lato SW.

Implementi il microcodice via software? Dando via i segreti industriali nascosti nel tuo design hardware? Geniale!

Originariamente inviato da Sp3cialFx

Le CPU x86 hanno visto un sacco di modalità in cui potevano esser messe, potresti fare la modalità "native microcode".

Come se il bloating non mancasse nel mondo x86. Please...

Originariamente inviato da Sp3cialFx

Il microcode lo generi a livello di OS con l'equivalente di Rosetta fatto direttamente da Intel / AMD.

Tutto disaccoppiato dalla CPU e portato su ogni singolo OS da supportare....e gli altri OS fanno la birra? Semplicemente non possono usare la CPU?

Originariamente inviato da Sp3cialFx

Cmq Cfranco dice che l'efficienza è 96/97%. Uno dei due ha torto.

Pure l'efficienza di un traduttore binario software si attesta su quei livelli. Parliamo comunque di un 80% e più nel caso medio. Poi ci sono i benchmark sintetici, dove puoi sfruttare il caching a manetta e arrivi vicinissmo al 100%.

E poi c'è tutto il discorso sulla parte hardware, che ho fatto sopra, che ti fa capire perchè ha senso usare qualcos'altro ( magari realizzato ex novo ) rispetto a x86 o anche ARM, che pure ha il suo legacy.

Si parlava di RISC-V e di come potrebbe fare le scarpe pure ad ARM. Ed è possibilissimo. E non è semplicemente una questione di microdice, ma di quanti transistor puoi liberare, non dovendo supportare funzionalità legacy.

Esempio banale: se ritornassimo indietro, levassimo il microcodice, e progammassimo direttamente nel linguaggio macchina della CPU, avremmo un miglioramento? Si, perchè avremmo meno transistor/li potrebbe usare per implementare ulteriori unità funzionali, utili a scopi pratici.

[Sp3cialFx]

paboloski, te l'ho detto nell'ultimo post in modo un po' aggressivo con la speranza di farti capire che non mi interessano le opinioni o la visione personale secondo quanto si ha capito;
se hai riferimenti da leggere benissimo, altrimenti delle chiacchiere faccio poco.

Il punto di fondo è: Intel e AMD sono nel settore da 40 anni. ARM da poco meno. Arriva Apple che ha un botto di know how ma non nelle CPU (ha fatto due acquisizioni di aziende che definirei piccole) e fa l'M1 (*). Ora arriva pinco pallino e dice che la sua CPU va n volte di più dell'M1.

C'è qualcosa che non torna, e di chiacchiere a riguardo ne ho lette già abbastanza, vorrei qualche argomento consistente ma soprattutto verificabile / comprovabile.

(*) ricordo che M1 è un ARM ma va il doppio degli altri ARM. E l'ultima volta che ho controllato gli altri ARM non usano una ISA x86 ma usano un'ISA ARM :P

Il fatto che l'M1 sia avanti di un nodo nel processo produttivo sicuramente aiuta ma non è sufficiente a chiudere la questione.

[pabloski]

Originariamente inviato da Sp3cialFx

C'è qualcosa che non torna, e di chiacchiere a riguardo ne ho lette già abbastanza, vorrei qualche argomento consistente ma soprattutto verificabile / comprovabile.

L'unica possibilità allora è andarti a studiare l'architettura proposta da quest'azienda. Solo così potrai vedere se e dove hanno eliminato colli di bottiglia e come. E capire in quali casi ( perchè ripeto che un design può essere più performante su certi task e meno su altri rispetto ad un concorrente, per cui non esiste il migliore in assoluto ) riesce a rendere.

Originariamente inviato da Sp3cialFx

(*) ricordo che M1 è un ARM ma va il doppio degli altri ARM.

Ecco. Questo è uno dei punti da chiarire. M1 e tutti i SoC Apple NON SONO ARM!! Implementano l'ISA ARM, ma i design hardware sono totalmente diversi e molto probabilmente ( e ripeto, si può solo supporre, perchè è roba protetta da segreto industriale ) si tratta di chip Power o Power-like, dato che gli ingegneri della PA Semi lavorano su chip Power.

Originariamente inviato da Sp3cialFx

Il fatto che l'M1 sia avanti di un nodo nel processo produttivo sicuramente aiuta ma non è sufficiente a chiudere la questione.

No, non lo è. Per esempio, stamattina leggevo alcune speculazioni sul fatto che la traduzione binaria non sarebbe realizzata solo in software da Rosetta, ma avrebbe il supporto di un'unità hardware specializzata nel SoC.

Quello che si sa per certo, è che i SoC Apple hanno delle pipeline estremamente ampie e sono aggressivamente superscalari, cosa strana per il mondo ARM tradizionale. E potrebbe essere dei design clockless, dato che proprio ARM ci aveva lavorato in passato per tentate di abbattere i consumi elettrici.

[amd-novello]

quando dici chip power intendi che hanno a che fare con i power-pc?