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

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

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.

di pubblicata il , alle 12:21 nel canale Processori
 

Un decennio fa, presso la University of California di Berkeley, nasceva l'ISA (istruction set architecture) RISC-V, un set di istruzioni open source, senza licenza, aperto a chiunque desiderasse adottarlo. A oggi sono diverse le aziende che hanno scelto RISC-V per i loro progetti, e sembra che l'ISA sia ora pronta a fare il grande salto.

Recentemente la statunitense Micro Magic, che opera nel campo dell'Electronic Design Automation (EDA), ha annunciato quello che ha definito "il core RISC-V a 64 bit più veloce al mondo", una soluzione che a suo dire è in grado di battere chip come l'Apple M1 e le soluzioni basate su ARM Cortex-A9. L'azienda ha dimostrato una prototipo capace di operare a 5 GHz con una tensione di 1,1V, e in grado di raggiungere 13.000 punti nel test CoreMark.

Con una tensione di 0,8V e una frequenza di 4,25 GHz, il core di Micro Magic è in grado di arrivare a 11.000 punti in CoreMark, con un consumo di appena 200mV. Andy Huang, consulente di Micro Magic e creatore del simulatore di circuiti FineSim di Synopsys, ha mostrato al sito EE Times una demo del core in funzione su una board Odroid, dove ha raggiunto 4,327 GHz a 0,8V e 5,19 GHz a 1,1 V.

Micro Magic, fondata nel 1995, fu venduta a Juniper Networks per 260 milioni di dollari per poi rinascere nel 2004 con lo stesso nome per mano dei fondatori, Mark Santoro e Lee Tavrow, entrambi coinvolti in Sun Microsystems nello sviluppo nel microprocessore SPARC a 300 MHz. Nella sua carriera Santoro ha lavorato anche in Apple, sotto la supervisione di Steve Jobs.

Huang ha spiegato che usando i test dell'EEMBC, Embedded Microprocessor Benchmark Consortium, il core di Micro Magic è capace di raggiungere 55.000 CoreMark per Watt, mentre il chip M1 di Apple si ferma a circa 10.000 punti. "Se dividete questo dato per gli otto core e 15W per core, avete meno di 100 CoreMark per Watt", ha spiegato Huang. "Il processore ARM più veloce nei test EEMBC è il Cortex-A9 (quad-core), con un valore di 22.343 CoreMark. Divedendo per quattro e 5W per core, ottenete 1112 CoreMark per Watt".

Il dato di 200mW, secondo Huang, è quello più importante in quanto "in un tipico dispositivo da 5W, possiamo implementare 25 core. Chi può offrire 25 core nell'industria degli smartphone? Molti si limitano a quattro od otto core. Perciò, per aziende che necessitano di ridurre l'uso della batteria, ad esempio Tesla, possiamo raggiungere le prestazioni necessarie". Micro Magic intende offrire il suo core RISC-V in licenza. "L'architettura è completamente scalabile per l'industria mobile, i PC, l'automotive e i datacenter. Siamo completamente autofinanziati, quindi non stiamo cercando finanziamenti".

Qual è il segreto del progetto di Micro Magic? In un'altra intervista con ZDNet, Huang ha parlato del "modo in cui la CPU e la memoria interagiscono". I due fondatori dell'azienda brevettarono nei primi anni '90 una SRAM che era la più veloce mai inventata. Il prototipo RISC-V elimina un collo di bottiglia che emerge quando si ha una memoria veloce e chip più lenti. "Se la memoria opera a cinque gigahertz e la logica lavora a un gigahertz, qual è il collo di bottiglia?", ha spiegato Huang senza ovviamente non entrare nei particolari.

Proclami a parte, sarà interessante seguire i progressi e le evoluzioni del progetto di Micro Magic, che tra l'altro è già stata avvicinata da alcuni colossi hi-tech non meglio specificati, dei pezzi grossi interessati a saperne di più sul core RISC-V e il suo funzionamento.

71 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
phmk01 Dicembre 2020, 12:50 #1
..."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 ???
pipperon01 Dicembre 2020, 12:56 #2
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
pipperon01 Dicembre 2020, 12:58 #3
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.
Cfranco01 Dicembre 2020, 13:10 #4
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.
WarDuck01 Dicembre 2020, 13:45 #5
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_Tree01 Dicembre 2020, 15:02 #6

RISC-V nanotubo al carbonio

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

https://arstechnica.com/science/201...rbon-nanutubes/
Sp3cialFx01 Dicembre 2020, 15:50 #7
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
Cfranco01 Dicembre 2020, 16:24 #8
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.
umanoz01 Dicembre 2020, 16:28 #9
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
pabloski01 Dicembre 2020, 17:06 #10
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.

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^