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

[Pino90]

Originariamente inviato da Sp3cialFx

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.

Infatti non sono 12 anni che Apple produce chip compatibili ARM ad altissime prestazioni. Assolutamente.

Se poi vogliamo dirla tutta, l'ISA non è nemmeno ARM ma AARCH64. Apple ha creato un processore compatibile con ISA AARCH64 ma con un design completamente diverso dai reference di ARM e dalle customizzazioni di Qualcomm e Samsung.

Sono 12 anni che i loro processori vanno molto di più di tutti gli altri compatibili ARM, solo che adesso la gente come te si è svegliata e non ci crede perché non se ne è resa conto.

Per verificare quello che dico puoi tranquillamente leggerti i benchmark degli ultimi 12 anni di tutti i top di gamma Apple, sono sicuro che ce ne siano una marea.

[LMCH]

Originariamente inviato da Sp3cialFx

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.

Il programmatore o il compilatore/traduttore al massimo possono sequenziare le istruzioni dell'ISA in modo da dare più dritte che possono al decoder ed allo scheduler delle microOP riguardo cosa si può eseguire in parallelo.

Le microOp sono già ridotte ai minimi termini per quella particolare architettura e sarebbe praticamente inutile tentare di "ri-ottimizzarle"
(semmai meglio avere più buffer di riordino in modo da poter "tenere in sospeso" un maggior numero di istruzioni con interdipendenze da risolvere mentre magari si esegue codice che viene dopo di loro nella sequenza di decodifica ma che non ha dipendenze con le microOp "in attesa").

Riguardo istruzioni x86-64 ed istruzioni AArch64, la densità del codice ed il numero di microOp generate da una singola istruzione dell'ISA, da soli non sono un buon indicatore delle prestazioni.

Gli x86-64 hanno si istruzioni più "complesse" espandibili in un maggior numero di microOp, ma sono anche sequenze di microOp con interdipendenze che vanno riorganizzate a carico di decoder e scheduler invece che a più alto livello (ed in modo più efficiente) dal compilatore o dal programmatore.

Dall'altro lato, se si usano le istruzioni "semplici" degli x86-64, poi si scopre che servono più istruzioni "semplici" x86-64 per fare quello in cui magari basta una singola istruzione "semplice" di AArch64.

Ed infine c'e' il problema del numero di registri interi, x86-64 ha 16 registri interi a 64bit, quando arrivi ad usarli tutti si finisce con il dove accedere a variabili in memoria esterna, con istruzioni più lunghe e con aumento della pressione sulle unità di load/store.

Gli x86-64 più recenti hanno un sacco di ottimizzazioni interne per rendere più performante l'uso ripetuto della stessa variabile in memoria senza dover passare manco per la cache (per dirla in modo molto grossolano ed approssimativo, tengono il valore nel buffer di riordino e lo recuperano da li o dalla coda di scrittura verso la memoria se un istruzione successiva legge/scrive la stessa locazione), ma questo comunque forza ad usare istruzioni più lunghe (riducendo la densità del codice e riducendo il numero di altre istruzioni decodificabili nello stesso ciclo).

Invece un ARM Aarch64 o un Risc-V (a 32 o a 64 bit) quando un x86-64 deve cominciare a referenziare la memoria, hanno ancora altri 15 registri interi liberi che il programmatore/compilatore può utilizzare per tenere valori temporanei, puntatori, valori riutilizzabili in istruzioni successive, ecc. ed usando istruzioni "semplici" a tutto vantaggio della semplicità del decoder (quindi più facile da "allargare" per decodificare più istruzioni contemporaneamente) e del parallelismo interno in fase di esecuzione.

Ripeto, non è un caso se gli Arm di Apple già a 28nm decodificavano 6 istruzioni per ciclo, mentre gli x86-64 non vanno oltre le 4..6 istruzioni neanche ora che sono implementati a 10nm .. 7nm
(es: lo Zen3 in condizioni ottimali decodifica fino a 4 istruzioni x86-64 "semplici" per ciclo e fino ad 8 microOP per ciclo già predecodificate nella uOp Cache, ma invia in esecuzione allo scheduler solo 6 micro-op per ciclo tra i potenzialmente 12 candidati all'esecuzione, da cui la stima di "4..5 istruzioni x86 per ciclo" in condizioni ottimali).

Notare anche che, al momento solo Apple si è spinta a simili livelli di ampiezza del decoder istruzioni, i core di ARM Ltd. non sono così spinti perchè li si è scelto di privilegiare lo sviluppo delle istruzioni SVE2 in modo da rendere più semplice ai produttori su licenza la possibilità di "regolare il livello di prestazioni" cambiando l'ampiezza delle unità SVE.

[cronos1990]

Originariamente inviato da pipperon

Solo chi ha la palla di cristallo ha certezze

No, ha solo una palla di cristallo

[LMCH]

Originariamente inviato da pipperon

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

Per ora il rischio frammentazione non c'e', le specifiche sono molto chiare e la RISC-V International Association si sta attrezzando per limitare ulteriormente i rischi di frammentazione.

Le specifiche Risc-V prevedono pure un blocco di opcode "standard" da utilizzare per estensioni custom, in questo modo i vari produttori possono aggiungere loro estensioni speciali/sperimentali senza andare ad interferire con lo standard e le sue future estensioni.

A parte questo, sarei curioso di capire cosa hanno DAVVERO realizzato quelli di Micro Magic.
Non basta dire "Risc-V a 64bit che funziona a 5GHz", perchè c'e' molta roba differente che corrisponde ad una descrizione simile.

Questo perchè "Risc-V" è una famiglia di set di istruzioni, mica solo uno, senza contare tutte le differenti implementazioni architetturali che già esistono.

Ad esempio, se hanno implementato un RV64I (la versione "minima" di un Risc-V a 64bit) con un architettura scalare inorder con pipeline lunghissima non è che sia così impressionante, mentre invece se si parla di un RV64GC superscalare la cosa è decisamente più interessante.

In linea generale i Risc-V sono molto promettenti, hanno le loro particolarità ma sono pensati bene e sopratutto sono estendibili in modo retrocompatibile senza dover fare salti mortali assurdi, ma per ora quelli "già pronti" sono gli RV32IMAC .. RV32IMAFC ... RV32GC da usare nella fascia embedded attualmente dominata dagli ARM Cortex M3/M4.

[pabloski]

Originariamente inviato da amd-novello

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

Si, i PowerPC erano versioni castrate dei Power di IBM. P.A. Semi implementava SoC embedded basati sulle architetture Power.

[pabloski]

Originariamente inviato da pipperon

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.

E' un problema noto e l'hanno affrontato. E la soluzione è questa https://www.cnx-software.com/2019/08...ons-explained/

Qualcuno noterà la somiglianza col modello di sviluppo di OpenGL. E con OpenGL le cose hanno funzionato alla grande.

[Sp3cialFx]

pabloski: apprezzo l'entusiasmo ma ho passato già quella fase e ora mi limito a interessarmi ai fatti comprovabili. Perdonami ma non hai scritto mezza ceretzza, solo tante belle ipotesi di cui personalmente me ne faccio poco

Pino90: un conto è andare più degli altri ARM, un conto è andare più di un x86

LMCH: il senso della mia provocazione è: ma se un M1 + Rosetta 2 va meglio di un x86 e consuma pure meno, perché al posto che usare soluzioni che vengono presunte come incasinate e poco performanti come il decoder ISA x86 -> microOp HW non si fa dei core come diavolo si preferisce (l'importante dopotutto è solo che vada tanto e consumi poco) che tanto poi ci pensa l'equivalente di Rosetta 2 a occuparsi di mantenere la compatibilità con l'ISA x86?

Poi non ho capito la questione 16 registri x86 / 16 registri ARM, se mi fai esempi con qualche istruzione assembler credo mi sia più chiaro.

Così come non ho capito quando parli delle ottimizzazioni, sembra quasi che siano uno svantaggio perché si allungano le istruzioni, ovviamente avranno verificato che un vantaggio c'è, non credo si divertano a complicare le cose per peggiorare i risultati

[Cfranco]

Originariamente inviato da Sp3cialFx

LMCH: il senso della mia provocazione è: ma se un M1 + Rosetta 2 va meglio di un x86 e consuma pure meno, perché al posto che usare soluzioni che vengono presunte come incasinate e poco performanti come il decoder ISA x86 -> microOp HW non si fa dei core come diavolo si preferisce (l'importante dopotutto è solo che vada tanto e consumi poco) che tanto poi ci pensa l'equivalente di Rosetta 2 a occuparsi di mantenere la compatibilità con l'ISA x86?

M1 12 miliardi di transistor a 5 nm
Ice lake-Y 7 miliardi di transistor a 10 nm

M1 è enormemente più grosso, complesso e incasinato di un i7, forse qualcuno pensa che essendo un ARM sia più semplice di un X86, ma l'epoca dei RISC "snelli" contro i CISC "ciccioni" è finita più di 20 anni fa, adesso la gara è tra pesi massimi, le cpu snelle vanno giusto bene per processori embedded a bassissimo consumo, ma quando esci dai tre bench sintetici dove sembrano dei fenomeni e cominci a lavorarci sopra sul serio cominciano ad arrancare di brutto.

[Pino90]

Originariamente inviato da Cfranco

M1 12 miliardi di transistor a 5 nm
Ice lake-Y 7 miliardi di transistor a 10 nm

M1 è enormemente più grosso, complesso e incasinato di un i7, forse qualcuno pensa che essendo un ARM sia più semplice di un X86, ma l'epoca dei RISC "snelli" contro i CISC "ciccioni" è finita più di 20 anni fa, adesso la gara è tra pesi massimi, le cpu snelle vanno giusto bene per processori embedded a bassissimo consumo, ma quando esci dai tre bench sintetici dove sembrano dei fenomeni e cominci a lavorarci sopra sul serio cominciano ad arrancare di brutto.

Conoscendo la smania di Apple per la bellezza e l'ordine sicuramente sará il processore meno incasinato della storia di sempre!

[pabloski]

Originariamente inviato da Sp3cialFx

pabloski: apprezzo l'entusiasmo ma ho passato già quella fase e ora mi limito a interessarmi ai fatti comprovabili. Perdonami ma non hai scritto mezza ceretzza, solo tante belle ipotesi di cui personalmente me ne faccio poco

No, ti ho detto cosa la teoria ci porta a concludere. Per i dettagli implementativi, sono noti solo alle aziende coinvolte e sono protetti dal segreto industriale.

Pino90: un conto è andare più degli altri ARM, un conto è andare più di un x86

Originariamente inviato da Sp3cialFx

ma se un M1 + Rosetta 2 va meglio di un x86 e consuma pure meno, perché al posto che usare soluzioni che vengono presunte come incasinate e poco performanti come il decoder ISA x86 -> microOp HW non si fa dei core come diavolo si preferisce (l'importante dopotutto è solo che vada tanto e consumi poco) che tanto poi ci pensa l'equivalente di Rosetta 2 a occuparsi di mantenere la compatibilità con l'ISA x86?

Faccio pure io una provocazione, anzi una domanda. Secondo te, è più facile la vita di un decoder che si occupa di decodificare le istruzioni di un'ISA a lunghezza fissa o di uno che si occupa di un'ISA le cui istruzioni sono a lunghezza variabile?

E quali impatto può avere tutto ciò sulla fase di fetching e sul caching ?

Originariamente inviato da Sp3cialFx

Poi non ho capito la questione 16 registri x86 / 16 registri ARM, se mi fai esempi con qualche istruzione assembler credo mi sia più chiaro.

I registri sono spazio di memorizzazione. Più registri = più roba che si può tenere vicino al processore = meno accessi in memoria/cache. Non è un caso se un'architettura creata per le prestazioni ( Power ) abbia una marea di registri.

[The_misterious]

Originariamente inviato da Cfranco

M1 12 miliardi di transistor a 5 nm
Ice lake-Y 7 miliardi di transistor a 10 nm

M1 è enormemente più grosso, complesso e incasinato di un i7, forse qualcuno pensa che essendo un ARM sia più semplice di un X86, ma l'epoca dei RISC "snelli" contro i CISC "ciccioni" è finita più di 20 anni fa, adesso la gara è tra pesi massimi, le cpu snelle vanno giusto bene per processori embedded a bassissimo consumo, ma quando esci dai tre bench sintetici dove sembrano dei fenomeni e cominci a lavorarci sopra sul serio cominciano ad arrancare di brutto.

Sono un niubbo in queste cose, ma da quello che ho capito in M1 è integrata la GPU, l'SSD, la RAM ecc...
quindi non è tanto confrontabile il numero totale di transitor

[pabloski]

Originariamente inviato da Cfranco

M1 12 miliardi di transistor a 5 nm
Ice lake-Y 7 miliardi di transistor a 10 nm

M1 è enormemente più grosso, complesso e incasinato di un i7, forse qualcuno pensa che essendo un ARM sia più semplice di un X86, ma l'epoca dei RISC "snelli" contro i CISC "ciccioni" è finita più di 20 anni fa, adesso la gara è tra pesi massimi, le cpu snelle vanno giusto bene per processori embedded a bassissimo consumo, ma quando esci dai tre bench sintetici dove sembrano dei fenomeni e cominci a lavorarci sopra sul serio cominciano ad arrancare di brutto.

Il concetto di CISC e RISC è riferito all'ISA, non al design hardware. Poi, il numero di transistor non implica maggiore complessità dell'unità di controllo. Il M1 ha dentro un sacco di acceleratori hardware, tra cui uno appositamente creato per accelerare le reti neurali. E quello è fatto di transistor.

[digieffe]

Originariamente inviato da pabloski

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.

la cache L0 di 4k mops di Zen3 o l'equivalente del prox intel (11xxx) di 2.25k non servono proprio a contenere le sequenze di microistruzioni già decodificate?

[AlexSwitch]

Originariamente inviato da The_misterious

Sono un niubbo in queste cose, ma da quello che ho capito in M1 è integrata la GPU, l'SSD, la RAM ecc...
quindi non è tanto confrontabile il numero totale di transitor

In M1 le Ram LPDDR4X sono esterne al SoC anche se montate sullo stesso package; i chip dell'unità SSD sono saldati sulla scheda madre così come la circuiteria per l'I/O e il wireless.
Nel die monolitico del SoC sono comprese CPU, GPU, Neural Processing Unit di nuova generazione, l'Image Signal Processor per il video e il Secure Enclave, alias T2 chip, per le funzioni di sicurezza e di controller per l'SSD.

[AlexSwitch]

Originariamente inviato da Cfranco

M1 12 miliardi di transistor a 5 nm
Ice lake-Y 7 miliardi di transistor a 10 nm

M1 è enormemente più grosso, complesso e incasinato di un i7, forse qualcuno pensa che essendo un ARM sia più semplice di un X86, ma l'epoca dei RISC "snelli" contro i CISC "ciccioni" è finita più di 20 anni fa, adesso la gara è tra pesi massimi, le cpu snelle vanno giusto bene per processori embedded a bassissimo consumo, ma quando esci dai tre bench sintetici dove sembrano dei fenomeni e cominci a lavorarci sopra sul serio cominciano ad arrancare di brutto.

Ti ricordo che M1 è un SoC e non una semplice CPU... I core CPU di M1 sono in configurazione 4+4 ed ogni cluster, chiamiamolo così, ha il suo corredo di cache che per i core Firestorm ad alta potenza di calcolo raggiunge il ragguardevole valore di 12 Mb per la L2.
A tutto ciò andrebbe aggiunta la SLC, System Level Cache, sfruttata anche dai cores della CPU.
Ecco spiegati così tanti transistor per la componente CPU di M1.

[386DX40]

Originariamente inviato da WarDuck

...
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).
...

Credo che da un certo momento in poi (forse Win 8.x) sia richiesto qualcosa di piu' del "solo" SSE2. Provai poco tempo fa a installare Win 8.1 x86 su un Northwood P4 a 3,2Ghz (ultima cpu x86 con SSE2 e HT credo) e 2GB di ram l'installazione falliva in fase di inizio nemmeno arrivava alla schermata di installazione con un messaggio di errore complesso ma che pareva molto una incompatibilità dovuta proprio alla cpu. Comunque purtroppo l' i386 anche su linux stà vedendo i suoi ultimi momenti, si aggiornano i vecchi kernel ma non ne escono di nuovi nuovi.
Ovviamente e' inevitabile il rimpianto e' solo per passione di retrocomputing, ormai giusto il P4 sudetto era l'ultima cpu nativa x86 32bit commerciale che poteva dire la sua in moderni pesanti sistemi operativi. Ma da miei test ancora del tutto soddisfacente per una macchina generica da casa.

[386DX40]

Originariamente inviato da Cfranco

M1 12 miliardi di transistor a 5 nm
Ice lake-Y 7 miliardi di transistor a 10 nm

M1 è enormemente più grosso, complesso e incasinato di un i7, forse qualcuno pensa che essendo un ARM sia più semplice di un X86, ma l'epoca dei RISC "snelli" contro i CISC "ciccioni" è finita più di 20 anni fa, adesso la gara è tra pesi massimi, le cpu snelle vanno giusto bene per processori embedded a bassissimo consumo, ma quando esci dai tre bench sintetici dove sembrano dei fenomeni e cominci a lavorarci sopra sul serio cominciano ad arrancare di brutto.

Ma per curiosità, questo M1 quanti watt consuma? Perche' in proporzione tra watt, processo produttivo e benchmark sintetici si dovrebbe avere una idea di massima se ci sia stato un sorpasso ormai "concettuale" in tutti gli ambiti o no.

[386DX40]

Originariamente inviato da pipperon

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.

Ma si intende nel periodo Athlon e Pentium III? Perchè se si intende negli anni prima, sverniciare e' forse un po' ottimistico se prendiamo come riferimento i vari core 386/486/K5/K6/K6-II..
Certamente valide alternative sul piano economico (il K6-2 per esempio fu un ottima cpu da desktop, molto meno nelle applicazioni intensive come nel 3D imho per la non eccessiva adozione del 3DNow! che avrebbe potuto compensare molto, senza parlare della mancanza della cache esterna fino al K6-III/ II+/III+).

[pabloski]

Originariamente inviato da digieffe

la cache L0 di 4k mops di Zen3 o l'equivalente del prox intel (11xxx) di 2.25k non servono proprio a contenere le sequenze di microistruzioni già decodificate?

Dipende a cosa ti riferisci. Questo termine gira da un decennio con vari significati. Ho dato uno sguardo ai manuali Intel giusto per sicurezza, ma nemmeno viene nominato una cache L0.

Altre fonti ne parlano come di un'ulteriore cache prima della L1, con lo scopo di ridurre i consumi.

Altre ancora usano questo termine per riferirsi al register file. Che però contiene i registri generali e ( in alcune famiglie di CPU ) il program counter e lo status register ( i flag ). Ma non mi risulta che l'instruction register sia contenuto nel file.

E comunque è una tecnica diffusa pure nel mondo ARM e in altre famiglie di CPU moderne. Non è un'esclusiva x86.

[pabloski]

Originariamente inviato da 386DX40

Ma per curiosità, questo M1 quanti watt consuma?

15W. Ed è questo il bello. Si tratta del SoC col miglior rapporto mips/watt.

Originariamente inviato da 386DX40

Perche' in proporzione tra watt, processo produttivo e benchmark sintetici si dovrebbe avere una idea di massima se ci sia stato un sorpasso ormai "concettuale" in tutti gli ambiti o no.

Personalmente preferisco i numeri delle prestazioni rilevate nell'uso con programmi reali. I bench sintetici non sono in grado di offrire una misura onnicomprensiva. Cioè, un Chrome che ti spara le pagine a manetta, renderizza come un matto, esegue codice JS alla velocità della luce, è molto più utile di un bench sintetico.