|
|
|
|
Strumenti |
02-12-2020, 13:08 | #21 | |
Senior Member
Iscritto dal: Jan 2015
Città: Euskal Herria
Messaggi: 3665
|
Quote:
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. |
|
02-12-2020, 13:09 | #22 | |
Senior Member
Iscritto dal: Jan 2007
Messaggi: 5440
|
Quote:
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. |
|
02-12-2020, 13:59 | #23 |
Senior Member
Iscritto dal: Jul 2008
Città: Falconara Marittima
Messaggi: 26853
|
No, ha solo una palla di cristallo
__________________
|
02-12-2020, 14:02 | #24 | |
Senior Member
Iscritto dal: Jan 2007
Messaggi: 5440
|
Quote:
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. |
|
02-12-2020, 16:25 | #25 |
Senior Member
Iscritto dal: Jan 2008
Messaggi: 8406
|
|
02-12-2020, 16:30 | #26 | |
Senior Member
Iscritto dal: Jan 2008
Messaggi: 8406
|
Quote:
Qualcuno noterà la somiglianza col modello di sviluppo di OpenGL. E con OpenGL le cose hanno funzionato alla grande. |
|
03-12-2020, 19:50 | #27 |
Bannato
Iscritto dal: Nov 2017
Messaggi: 805
|
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 |
03-12-2020, 20:41 | #28 | |
Senior Member
Iscritto dal: Apr 2002
Città: VR-PD
Messaggi: 11125
|
Quote:
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.
__________________
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn |
|
04-12-2020, 08:16 | #29 | |
Senior Member
Iscritto dal: Jan 2015
Città: Euskal Herria
Messaggi: 3665
|
Quote:
|
|
04-12-2020, 09:48 | #30 | ||
Senior Member
Iscritto dal: Jan 2008
Messaggi: 8406
|
Quote:
Pino90: un conto è andare più degli altri ARM, un conto è andare più di un x86 Quote:
E quali impatto può avere tutto ciò sulla fase di fetching e sul caching ? 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. |
||
04-12-2020, 09:49 | #31 | |
Senior Member
Iscritto dal: Mar 2004
Città: Ancona
Messaggi: 2382
|
Quote:
quindi non è tanto confrontabile il numero totale di transitor |
|
04-12-2020, 09:50 | #32 | |
Senior Member
Iscritto dal: Jan 2008
Messaggi: 8406
|
Quote:
|
|
05-12-2020, 23:53 | #33 | |
Senior Member
Iscritto dal: Oct 2003
Città: Milano
Messaggi: 4073
|
Quote:
__________________
spesso, è solo quando sai che non ti resta molto tempo che ne apprezzi il reale valore quote: "some users are a classic example of the inverse ratio between the size of the mouth and the size of the brain" * se non vi rispondo è perché siete (200+) nella mia ignore list * mi chiedo perché chi è nella ignore list è spesso sospeso e, prima o poi, viene bannato * |
|
06-12-2020, 09:03 | #34 | |
Senior Member
Iscritto dal: Aug 2008
Città: Firenze
Messaggi: 10742
|
Quote:
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.
__________________
Mac Mini M2 Pro; Apple Studio Display; Logitech MX Keys for Mac; MBA 13" M3; iPod Touch 1st Gen. 8 Gb; iPhone 14 Pro; iPad Air 2020 WiFi 64 Gb, Apple Watch 8... |
|
06-12-2020, 09:29 | #35 | |
Senior Member
Iscritto dal: Aug 2008
Città: Firenze
Messaggi: 10742
|
Quote:
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.
__________________
Mac Mini M2 Pro; Apple Studio Display; Logitech MX Keys for Mac; MBA 13" M3; iPod Touch 1st Gen. 8 Gb; iPhone 14 Pro; iPad Air 2020 WiFi 64 Gb, Apple Watch 8... |
|
06-12-2020, 10:31 | #36 | |
Senior Member
Iscritto dal: Aug 2019
Messaggi: 2686
|
Quote:
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. Ultima modifica di 386DX40 : 06-12-2020 alle 10:38. |
|
06-12-2020, 10:36 | #37 | |
Senior Member
Iscritto dal: Aug 2019
Messaggi: 2686
|
Quote:
|
|
06-12-2020, 10:47 | #38 | |
Senior Member
Iscritto dal: Aug 2019
Messaggi: 2686
|
Quote:
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+). Ultima modifica di 386DX40 : 06-12-2020 alle 10:50. |
|
06-12-2020, 10:52 | #39 | |
Senior Member
Iscritto dal: Jan 2008
Messaggi: 8406
|
Quote:
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. |
|
06-12-2020, 10:55 | #40 |
Senior Member
Iscritto dal: Jan 2008
Messaggi: 8406
|
15W. Ed è questo il bello. Si tratta del SoC col miglior rapporto mips/watt.
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. |
Strumenti | |
|
|
Tutti gli orari sono GMT +1. Ora sono le: 16:44.