|
|
|
|
Strumenti |
06-12-2020, 13:00 | #41 | |
Senior Member
Iscritto dal: Aug 2019
Messaggi: 2690
|
Quote:
|
|
06-12-2020, 13:28 | #42 | |
Senior Member
Iscritto dal: Jan 2008
Messaggi: 8406
|
Quote:
Considera però che il M1 va negli Air, per cui se non sarà 15W, sicuramente più di 20-25W non supera. |
|
06-12-2020, 15:12 | #43 | |
Senior Member
Iscritto dal: Aug 2008
Città: Firenze
Messaggi: 10217
|
Quote:
In totale il consumo del SoC M1, nella versione più veloce usata nel Mac Mini e secondo le prove empiriche di Anandtech, raggiunge un picco di potenza attiva di 26.8W in multithread su tutti gli 8 core. La GPU ha raggiunto una potenza di 17.3W. In un utilizzo reale, dove GPU e/o acceleratori intervengono al posto della CPU o ne sgravano di parecchio il carico di calcolo, M1 non dovrebbe superare i 38W di picco. I dati della potenza assorbita sono stati rilevati direttamente da Anandtech " alla presa " di corrente, con un idle di 4.2W.
__________________
Mac Mini M2 Pro; Apple Studio Display; Logitech MX Keys for Mac; iPod Touch 1st Gen. 8 Gb; iPhone 14 Pro; iPad Air 2020 WiFi 64 Gb, Apple Watch 8... |
|
13-12-2020, 09:17 | #44 | ||||||||||||||||||||||||||||||||||
Senior Member
Iscritto dal: Jan 2002
Città: Germania
Messaggi: 26107
|
Quote:
Quote:
In generale non puoi avere una micro-architettura completamente slegata dall'ISA. Se t'interessano le prestazioni, ovviamente. Quote:
Infatti ci sono benchmark in cui le scelte troppo semplicistiche di RISC-V hanno mostrato il fianco. Un esempio è la presenza di una sola modalità d'indirizzamento verso la memoria (Registro base + piccolo offset), che pone non pochi problemi da questo punto di vista. Problemi che a cui hanno cercato in parte di rimediare introducendo il merging di due istruzioni compatte, e dunque richiedendo sia l'estensione C/Compatta sia la modifica del frontend del processore per intercettare questi pattern e generare un'apposita istruzione interna che fa il lavoro (e quindi una modifica anche del backend). Questo succede quando si fanno scelte miopi, andando a cercare la "purezza" a livello accademico, e dimenticandosi di come vadano le cose nel mondo reale... Quote:
Il fatto che internamente ci sia un backend RISC è soltanto un dettaglio implementativo, e in ogni caso tale backend è legato all'ISA, per l'appunto. E non potrebbe essere altrimenti, se l'obiettivo è di avere prestazioni elevate. Quote:
Rosetta emula soltanto lo user-mode di x86/x64, e nemmeno tutto (e no: non mi riferisco soltanto alle istruzioni mancanti. Vedi sotto). Un processore x86/x64 deve implementare & eseguire invece TUTTO: dall'hypervisor fino agli "anelli di protezione" (ring mode), passando per la segmentazione e la paginazione. Se Rosetta dovesse emulare TUTTO ciò che è specificato nell'ISA x86/x64 andrebbe a manovella. Provate a realizzare un emulatore x86/x64 pienamente compatibile con tutte le specifiche dell'ISA, e lo vedrete voi stessi come andranno poi le prestazioni, anche girando sui futuri M10 di Apple... Comunque non è quello lo scopo di Rosetta, e per quello che fa va benissimo così. Quote:
Quote:
Quote:
Quando lavoravo alla Intel ho avuto la possibilità di visionare dei webinar interni che analizzavano proprio queste cose, e la percentuale sia di silicio sia di consumi relativi strettamente al legacy erano basse. Non posso dire altro perché è tutta roba riservata. Comunque ci si può arrivare lo stesso induttivamente. I complessi decoder x86/x64 sono cresciuti relativamente poco dai tempi del PentiumPro, e idem la parte legacy del backend (vecchie istruzioni, FPU x87, segmentazione, registri controllo/debug/machine, ecc.). Oggi abbiamo chip con decine di miliardi transistor: quanto pensi che possa incidere ancora quella roba sia in termini di transistor/silicio sia in termini di consumi? Queste valutazioni le avevo già fatte in un mio vecchio articolo su Appunti Digitali, che rimane ancora attualissimo. In sintesi: più è piccolo un core x86/x64, e più incide il legacy. E' qui, in questo contesto, che i processori basati su questa vecchia ISA perdono. Quote:
Quanto a x86/x64, essendo CISC ha, invece, minori interdipendenze rispetto ai RISC, visto che consente alla maggior parte delle istruzioni di operare direttamente con la memoria. Anche per questo richiede meno registri, e tempo fa ho postato uno studio in cui un x64 con 12 registri aveva quasi le stesse prestazioni della versione normale con 16 registri (a fronte di una maggior pressione verso la memoria, ovviamente, ma non era nemmeno tanto). Infine x86/x64 ha diverse modalità d'indirizzamento verso la memoria, e anche queste aiutano. Certamente avere istruzioni a lunghezza variabile, ma soprattutto facenti uso dei famigerati prefissi (è questo il vero problema), richiede decoder di gran lunga più complessi rispetto a ARM, specialmente se il processore implementa esclusivamente l'ISA AArch64. Ecco perché Apple riesce a decodificare ben 8 istruzioni per ciclo di clock contro 4 (non 5. Nel diagramma di Skylake sono riportate 5uop: non 5 istruzioni) di Intel/AMD. Quote:
Quote:
Ma anche avendo dei vincoli importanti si possono realizzare delle ISA "migliori" / più efficienti. Un esempio è proprio l'8086, che era quasi al 100% compatibile a livello di sorgente con l'8085 (traducendo meccanicamente i sorgenti assembly di quest'ultimo in quelli 8086), ma la nuova ISA era a 16 bit e molto migliorata. Quote:
RISC-V si porta anch'essa dei problemi / errori di progettazione, e non da poco. Quote:
Quote:
Le due acquisizioni di cui parli saranno state pure piccole, ma estremamente importanti. PaSemi era costituita da eccellenze, per l'appunto, e aveva sviluppato processori PowerPC a uso embedded / militare con un'elevata efficienza energetica. Intrinsity (se non ricordo male il nome) era specializzata nell'ottimizzazione di circuiti integrati per migliorare le prestazioni (inclusi i consumi). Dire un'eccellente combinazione, soprattutto funzionale agli scopi di Apple. Quote:
Quote:
Quote:
Quote:
Quote:
A riguardo c'è uno studio proprio di uno dei creatori di RISC-V, che afferma che un processore con codice del 25% più denso può usare una cache istruzioni dimezzata (sì, hai letto bene) ottenendo le stesse prestazioni (della cache). Quindi, come vedi, è MOLTO importante. E non è un caso che praticamente i produttori di processori abbiano cercato di migliorare la densità di codice, proponendo estensioni alle loro ISA, o anche ISA realizzate ad hoc. Sul numero di micro-op generate, invece, non si può dire niente, perché dipende tutto dall'ISA e dal "lavoro utile" che fanno. E questo difficilmente si può quantizzare (magari si dovrebbe vedere il totale delle micro-op eseguite da una precisa applicazione con un preciso set di dati). Quote:
Quote:
Quote:
Parimenti è ridotto anche il numero di istruzioni da codificare, proprio perché x86/x64 ne decodifica una, mentre un RISC per fare lo stesso ne decodificare ALMENO due. Qui il vantaggio di un CISC come x86/x64 è nettissimo rispetto ai RISC. Non c'è proprio storia. Quote:
Non parliamo poi delle istruzioni in cui il risultato dell'operazione è in memoria, dove il vantaggio diventa ancora più grande, visto che in questo caso i RISC necessitano di Load + Op + Store, mentre x86/x64 fa tutto con UNA sola istruzione. Infine, e non meno importante, ci sono istruzioni x86/x64 il cui la destinazione è la memoria e la sorgente è un valore immediato. Qui il vantaggio rispetto ai RISC si fa addirittura imbarazzante, visto che x86/x64 non spreca un solo registro e fa tutto con una sola istruzione, mentre un RISC richiede più registri (anche più di 2) e MOLTE più istruzioni (specialmente se l'immediato non è piccolo). Non è che x86/x64 sia arrivato a prestazioni elevatissime per puro caso, eh! E l'ISA CISC ha aiutato, e parecchio. Quote:
Quote:
Quote:
I soliti accademici idealisti che non tengono conto della realtà... Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Se vuoi testare/confrontare la sola CPU/ISA/microarchitettura ti devi rivolgere ad altri benchmark. P.S. Scusate ma ho perso un sacco di tempo a scrivere, e non ho nessuna voglia di leggere e correggere eventuali errori. Spero che sia tutto chiaro.
__________________
Per iniziare a programmare c'è solo Python con questo o quest'altro (più avanzato) libro @LinkedIn Non parlo in alcun modo a nome dell'azienda per la quale lavoro Ho poco tempo per frequentare il forum; eventualmente, contattatemi in PVT o nel mio sito. Fanboys |
||||||||||||||||||||||||||||||||||
13-12-2020, 12:02 | #45 | |
Senior Member
Iscritto dal: Aug 2019
Messaggi: 2690
|
Quote:
|
|
15-12-2020, 00:32 | #46 | ||||||||||||||
Senior Member
Iscritto dal: Jan 2007
Messaggi: 5264
|
Quote:
Quote:
Allo stesso modo averne 32 è stato considerato uno sweet spot già con le tecnologie di implementazione e compilazione disponibili negli anni '90 (più di 20 anni fa), non è un caso se sia Alpha che MIPS e PowerPC siano partiti da subito con 32 registri interi e che poi anche ARM con Aarch64 abbia scelto di avere 32 registri interi a 64bit. Se ARM a più di un decennio di distanza ha privilegiato i 32 registri rispetto ad avere da 1 a 3bit extra da usare ad esempio per ulteriori modalità di indirizzamento ed operandi letti/scritti dalla memoria mi sa che qualche motivo serio ci sia stato. Quote:
Quote:
Inoltre non è una cosa "vera in assoluto", dipende molto dalle latenze negli accessi a registri, cache e memoria e dalla banda di I/O, nel senso che sono cose da valutare caso per caso e con il cambiare delle opzioni implementative. Quote:
E' un vantaggio non da poco visto che agli x86 sono state aggiunte istruzioni di prefetch proprio per poter fare la stessa cosa (annullando il "vantaggio" teorico che hanno referenziando direttamente la memoria ... per avere un vantaggio concreto). Quote:
M1: 8 istruzioni e giù fino a ... diciamo almeno 4 istruzioni se si usa un compilatore con attivati loop unrolling ed auto-inlining. Quote:
Quote:
Quote:
Quote:
Mentre con un RISC con il doppio dei registri, in una sequenza "calda" tipo un loop poni meno pressione sulle unità load/store e vai via molto più veloce. Quote:
si è aperta per AMD la finestra di opportunità in cui proporre con successo x86-64. Ed una delle innovazione fondamentali di x86-64 è stata estendere il numero di registri interi, non lo dimenticare, altrimenti sai che bello avere le istruzioni CISC con uno dei due operandi in memoria. E poi diciamolo, x86-64 è arrivato dove è arrivato anche perchè Intel ha spinto l'acceleratore sui processi produttivi, infatti ora che Apple ha fatto la stessa cosa ne è con l'M1 che può permettersi cache più grandi ed un parallelismo interno maggiore grazie al processo produttivo più avanzato (ed al set d'istruzioni Aarch64 che permette di avere un miglior rapporto costi/benefici dall'avere un maggior numero di unità di esecuzione e di buffer di riordino). Quote:
Quote:
E' ancora in evoluzione ed ha ancora un sacco di margini di crescita, inoltre come i due set "base" RV32 e RV64 sono simili ma non compatibili tra loro, nulla vieta di introdurre una nuova sottofamiglia se necessario. L'unica cosa che creerebbe veri problemi sarebbero breaking changes agli attuali set d'istruzioni "base" (RV32I, RV32E, RV64I e RV128I, di cui RV32E e RV128I non sono stati ancora definiti) Quote:
|
||||||||||||||
18-12-2020, 23:25 | #47 | |||||||||||||||||||||||||
Senior Member
Iscritto dal: Jan 2002
Città: Germania
Messaggi: 26107
|
Quote:
M1 ha oggettivamente una montagna di risorse, a prescindere da qualunque altro chip con cui venga confrontato, inclusi quelli di casa ARM. Quote:
Poi ti posso dire che personalmente se ci fossero anche più di 16 registri farebbero comodo in alcuni ambiti, ma oggettivamente un CISC (come x86 e, soprattutto, 68K) in genere ne necessita molti di meno per avere comunque buone prestazioni, paragonato a un RISC, per le motivazioni che ho già esposto. Quote:
Quote:
Per le modalità d'indirizzamento parliamo esclusivamente di istruzioni di load / store, e non dell'intero insieme di istruzioni. Per questo tipo di istruzioni nessuno t'impedisce di mettere a disposizione più modalità d'indirizzamento, pur preservando tutto il resto dell'ISA, inclusi l'utilizzo di 32 registri. Difatti uno dei grossi vantaggi di ARM rispetto a tanti altri RISC è stato quello di avere modalità d'indirizzamento molto complicate, persino più complicate di x86 (mi riferisco a quelle di pre-post de/incremento), con innegabili benefici a livello di densità del codice E prestazionali. Già soltanto per questo ARM vince a mani basse su RISC-V, che una delle ISA più povere e semplici in assoluto, da questo punto di vista (e infatti paga pegno). Quote:
Fortunatamente c'è Agner Fog che si passa il tempo a studiare micro-architetture x86/x64, e a fornire i risultati di tali studi. Nello specifico, per Skylake: "There are four decoders, which can handle four instructions (five or six with fusion) generating up to four µops per clock cycle". Quindi più di quattro istruzioni possono essere decodificate soltanto in presenza di macro-op fusion. Normalmente il massimo rimane quattro. Quote:
Quote:
Quote:
Quote:
Quote:
Le singole istruzioni "general purpose" non fanno uso e non hanno bisogno (in genere) di istruzioni di prefetch. Altrimenti il codice sarebbe letteralmente farcito di queste istruzioni (con notevole crollo prestazionale, visto che la logica di prefetch può "seguire" un numero limitato di stream). Quote:
Peraltro se il frontend è organizzato per decodificare un'istruzione complessa e 3 più semplici, è perché si è visto che nel codice reale le istruzioni complesse sono ben più rare di quelle più semplici, e intervallate. Per cui Intel ha organizzato così il frontend. Quote:
https://www.appuntidigitali.it/18192...so-la-memoria/ Guarda pure le tabelle che ho riportato sia per x86 sia per x64, e vedi un po' quante sono le istruzioni che referenziano la memoria. Poi confrontali con questi numeri: https://www.appuntidigitali.it/18054...di-istruzioni/ Sono state analizzate circa 1,75 milioni di istruzioni (1.746.569 per la precisione) per PS32, e circa 1,74 milioni (1.737.331) per PS64 Quote:
Cosa che succede spesso su x86, coi suoi soli 8 registri (nemmeno tutti liberi: uno è lo stack pointer), ma di gran lunga meno con x64 e i suoi 16 registri. Quote:
Altri CISC possono fare, e fanno, di gran lunga meglio, con un leggero costo da sostenere per consentire alle istruzioni di referenziare la memoria. Quote:
Quote:
Quote:
Intanto la sequenza di uOP è ottimale (poi se la smazza il backend). Poi le unità di load/store hanno, invece, pressione minima, perché devono soltanto leggere una volta dalla memoria (il primo operando sorgente; il secondo ce l'hanno già, perché è il valore immediato), e parimenti scrivere (sulla stessa locazione!) una sola volta nella memoria. Immagina cosa dev'essere costretto a fare un RISC per fare la stessa cosa: o impiega più registri e/o istruzioni già soltanto per costruirsi la costante necessaria, o deve eseguire almeno una load per caricarla dalla memoria. Se ci aggiungiamo anche una modalità d'indirizzamento della memoria più complessa, allora servono altre istruzioni già soltanto per calcolare l'indirizzo desiderato. Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Son tutte cose che puoi vedere tu stesso se riesci a recuperare le varie versioni / revisioni del documento delle specifiche dell'ISA. Quote:
Si sono accorti (troppo tardi) che le operazioni di load/store dei registri FP sono molto più rare e incidono meno rispetto ad altre istruzioni. Per salvare capra (retrocompatibilità) e cavoli (riutilizzo degli opcode) stanno cercando di porvi rimedio con una nuova estensione compressa. Formalmente la retrocompatibilità è salva, perché quei processori non useranno l'estensione compressa standard, ma quella nuova. Di fatto è una presa in giro, perché stanno riutilizzando gli stessi opcode per cose completamente diverse, e quindi si tratta di una modifica non retrocompatibilità. Immagina il lavoro che dovranno fare i disassemblatori per questo giochetto...
__________________
Per iniziare a programmare c'è solo Python con questo o quest'altro (più avanzato) libro @LinkedIn Non parlo in alcun modo a nome dell'azienda per la quale lavoro Ho poco tempo per frequentare il forum; eventualmente, contattatemi in PVT o nel mio sito. Fanboys |
|||||||||||||||||||||||||
22-12-2020, 02:50 | #48 | ||||||||||||||||||
Senior Member
Iscritto dal: Jan 2007
Messaggi: 5264
|
Quote:
https://www.semanticscholar.org/pape...f17059220c2ba4 Nota bene cosa hanno usato per i vari benchmark: " In this paper, we conducted all the experiments on a Dell Precision Work- station 370 MiniTower containing a 3.8 GHz Intel Pentium 4 processor." Un maggior numero di registri "visibili" torna utile al crescere del parallelismo interno, ti credo che con un Pentium 4 passare da 12 a 16 non c'era lo stesso miglioramento che passando da 8 a 12, senza contare che l'ABI prevedeva solo registri caller-saved (mentre di solito quando si hanno molti registri interni le ABI sensate prevedono solo una parte di registri caller-saved ed il resto sono callee-saved proprio per evitare il problema descritto nella pubblicazione). Quote:
Quote:
Così hai i Cortex-M0 (con set d'istruzioni Thumb-2 e varianti successive) che quanto a costo di produzione sono concorrenziali pure con le vecchie cpu ad 8bit, poi i Cortex-M3 e successivi pensati come microcontroller più potenti ma sempre per applicazioni embedded, per salire poi ai Cortex-R (che implementano il set "base" completo di istruzioni ARM a 32bit, hanno varianti dual lockstep, ecc. ) per poi arrivare ai Cortex-A a 32bit e poi a 64bit pensati più per far girare codice applicativo su un S.O. che per roba embedded di fascia bassa). Guardacaso le cpu con solo Thumb-2 hanno modalità di indirizzamento più "semplici" seppur siano state introdote molti anni dopo le istruzioni ARM a 32bit originali. Mentre invece le cpu Aarch64 essendo pensate per roba più grossa implementano modalità più complesse (perchè si parte dal presupposto di avere molte più risorse in termini di area e gate per implementare tali cpu). Con Risc-V invece sono partiti definendo inizialmente il nucleo di istruzioni più semplici e solo ora sta cominciando a venir ratificata la roba più sofisticata. Non è un caso se la maggior parte delle cpu Risc-V disponibili sul mercato attualmente siano degli RV32IMAC che mirano a scontrarsi al massimo con gli ARM Cortex-M3. Quote:
Ma ho il forte sospetto che per ora non sarà così, per un motivo molto semplice, ovvero che implementa già le modalità di indirizzamento più utilizzate. Mi riferisco ad esempio a quanto riportato in questa analisi: http://www.cs.unc.edu/~porter/pubs/i...p-systor19.pdf Nota che è codice x86-64 e che le modalità di indirizzamento indexed e scaled (che Risc-V non ha) sono usate rispettivamente nel 0.85% e nel 0,44% dei casi ( contro un 7,28% del register-indirect ed un 32,5% del base+offset). Quote:
https://www.agner.org/optimize/blog/read.php?i=583 Quote:
Se non sbaglio è il decoder che "comanda" la micro-op cache, in un certo senso è una forma ottimizzata di decodifica. Quote:
Mediamente un istruzione x86-64 occupa 4 byte, inoltre lo stesso codice richiede molte più istruzioni move rispetto ad ARMv8, questo significa che i vantaggi legati alle istruzioni più "compatte" degli x86-64 vengono vanificati dalla minor espressività delle istruzioni "più corte" che possono accedere a meno registri e non hanno un move "gratis" come le istruzioni a 3 operandi di ARMv8. Ovviamente il codice x86 (a 32bit) è più compatto di x86-64, ma seguendo lo stesso ragionamento il codice a 32bit degli ARM lo è ancora di più (istruzioni ARM "classiche" + istruzioni Thumb-2 a 16bit utilizzabili nello stesso codice applicativo). Quote:
Inoltre lo stesso giochino di caricamento dei valori in memoria lo possono fare anche i RISC facendo molto più semplicemente ed efficientemente il renaming dei registri interni rispetto ad un CISC. Quote:
Ma resta il fatto che se vuoi ottimizzare l'uso di istruzioni x86-64 con operandi in memoria, a livello di compilatore ti servono le istruzioni di prefetch per limitare i problemi causati dal minor numero di registri visibili al programmatore/compilatore. Quote:
Quote:
Quote:
Altrimenti quelli di ARM avrebbero implementato Aarch64 come un CISC "riscritto da zero e moderno" mentre invece hanno considerata molto più vantaggiosa un architettura "simil-RISC". Quote:
Quote:
Quote:
Quote:
A spingere MIPS sui server era SGI, che pure essa è passata ad Itanium e poi ha fatto la fine che ha fatto. MIPS è sopravvissuto nel settore embedded ma ormai è usato principalmente in roba legacy visto che ARM ha confinato MIPS e PowerPC a nicchie ridotte di mercato. I produttori di cpu/microcontroller embedded per roba nuova a 32bit e 64bit propongono principalmente ARM. PowerPC resiste come architettura legacy specialmente nell'automotive ma al massimo si vedono degli shrink dei core, niente roba davvero nuova. Quote:
Quote:
|
||||||||||||||||||
22-12-2020, 11:48 | #49 |
Senior Member
Iscritto dal: Aug 2001
Città: Novara (NO)
Messaggi: 19637
|
wall of text versus wall of text
lol
__________________
ASUS N76VZ +crucial m500 Dell Latitude E5430 iPad 2017 Huawei nova 5t con Very samsung tv 55m5500 ps4,wiiu exVODA 82/18-78/16-77/13-90/11 exWIND 95/14-95/19-85/19-81/22 fritzbox 7490 su Tiscali 936/288 |
23-12-2020, 11:23 | #50 | |||||||||||||||||||||||||||
Senior Member
Iscritto dal: Jan 2002
Città: Germania
Messaggi: 26107
|
@amd-novello Ah, bene. Allora divertiti con quest'altro, visto che ti piacciono tanto.
Quote:
Ciò che era importante evidenziare è che il passaggio da 12 a 16 registri sostanzialmente non abbia inciso a livello prestazionale. Quote:
Quote:
Quote:
In particolare Thumb e Thumb-2 sono l'esempio del pastrocchio che ARM ha realizzato quando ha definito la prima, mentre avrebbe potuto semplicemente prendere gli allora opcode ARM, rimuovere i 4 bit per l'esecuzione condizionale, lasciare la sola "condizione" (sempre vera) per l'esecuzione tout-court delle istruzioni, e riutilizzare le altre 15 configurazioni per definire in maniera pulita e semplice le istruzioni compatte a 16-bit. Invece è partita abbozzando malamente la prima, per poi metterci una pezza dopo con la seconda. Quote:
Quote:
La grossa mancanza riguarda le estensioni vettoriali, perché sono anni che gli accademici sbattono le corna alla ricerca di qualcosa di utilizzabile concretamente nella realtà, e che non li faccia soffrire troppo nello scardinare i loro ideali di "bellezza" dell'ISA che s'erano costruiti (i famigerati soli 3 formati di opcode sono un lontano ricordo, infatti: rimangono un proclama di pura propaganda). E meno male che a questo comitato si sono uniti diversi ingegneri provenienti da aziende, che hanno i piedi ben piantati per terra, altrimenti sarebbero state ratificate delle colossali stupidaggini, come la definizione dinamica, a runtime, del tipo di dati utilizzato dai registri vettoriali (come da originale proposta, di diversi anni fa), che avrebbe fatto piangere lacrime amare a chi avrebbe dovuto implementarle... Quote:
Anzi, quella M e A erano e sono anche di troppo (su quella C mi sono già espresso), ed è proprio il motivo per cui sono poi nate delle loro versioni castrate, aumentando di fatto la frammentazione (visto che M ed A erano già state ratificate, e non si poteva più tornare indietro). Quote:
Come puoi vedere già il titolo è tutto un programma, e il contenuto non si smentisce. Quote:
Quote:
E' il motivo per cui, ad esempio, trovi un così elevato numero di istruzioni ADD, come puoi vedere anche dal loro sito che consente di consultare il database con le informazioni raccolte. Infatti la ADD è così inflazionata perché si tratta dell'istruzione avente 0x00 come uno dei suoi opcode: dato estremamente comune negli eseguibili, come certamente sai. Altri paper mostrano risultati abbastanza diversi: https://www.strchr.com/x86_machine_code_statistics http://citeseerx.ist.psu.edu/viewdoc...=rep1&type=pdf http://people.umass.edu/cmutigwe/res...s%20Design.pdf e soprattutto il paper degli autori di RISC-V che ti ho già passato che, sebbene sia ovviamente (fortemente) "biased", mostra dei dati grezzi che sono molti utili di per sé, oltre al fatto che riporta esclusivamente istruzioni reali, e soprattutto le statistiche sono di quelle dinamiche (quindi tutte e soltanto quelle eseguite realmente in quelle applicazioni) e non statiche (quelle del paper che hai postato). Tra l'altro anche il bouquet di applicazioni che ho usato per le mie statistiche (anche statiche, sia chiaro) mostra un quadro diverso da quello del tuo paper, e più in linea con gli altri paper. Inoltre non ho disassemblato roba a caso, ma sono partito dall'entry point dell'eseguibile, e ho disassemblato tutto ciò che era possibile, tracciando le istruzioni di salto. Quindi niente spazzatura/dati grezzi disassemblati come istruzioni. Le statistiche le trovi nella mia ultima serie di articoli su Appunti Digitali, dove puoi vedere i dati della beta pubblica di Photoshop CS6, sia a 32 sia a 64-bit. Ciò precisato, t'invito a leggere il paper che ho postato, e così vedrai che, sebbene la modalità d'indirizzamento indicizzata non sia così diffusa, è molto usata (dinamicamente) in alcune applicazioni ed è il motivo per cui RISC-V ha un crollo a livello prestazionale, di cui gli autori propongo una soluzione (macro-op fusion) per alleviare il problema. Che il paper sia biased lo si capisce anche dal fatto che si lamentano della scarsa qualità del codice generato per RISC-V (che ci può stare. Anche se loro hanno attivato soltanto per RISC-V un'opzione di GCC per disabilitare la generazione di routine di prologo/epilogo, che altrimenti avrebbero prodotto PIU' istruzioni e micro-op eseguite), ma analizzando il disassemblato x86-x64 in alcuni casi si può vedere come vengano generate istruzioni non necessarie, che ovviamente penalizzano quest'ISA sia a livello prestazionale sia di densità di codice. Dai pattern che ho rilevato (dagli esempi nel paper) mi sembra evidente che GCC non sia capace di riconoscere quando può evitare di omettere la generazione di istruzioni di confronto quando la precedente istruzione ha già impostato correttamente i flag, che quindi possono essere immediatamente "consultabili" (con un salto condizionale). E qui parliamo di roba da manuale, eh! Perché per me è OVVIO che l'ottimizzatore del backend x86/x86-64 avrebbe dovuto tenere conto di questi casi molto comuni. Non capisco come sia potuto sfuggire agli sviluppatori di GCC. Questo per dirti che non è soltanto RISC-V che può lamentare che non sia stato generato codice adeguato, ma persino ISA rodate come x86/x86-64. Altra cosa non meno importante, i paper in genere fanno soltanto uso di GCC come compilatore, mentre nelle applicazioni reali si usano, e sono pure molto comuni, anche altri compilatori, come quello di Intel e, soprattutto, di Microsoft in Windows. Questi compilatori ottimizzano molto meglio il codice rispetto a GCC, sia a livello di istruzioni generate sia a livello di densità di codice. Infatti da ciò che ho visto finora GCC predilige la generazione di codice più "RISC-like", anche quando deve farlo per x86/x86-64. E lo fa a danno soprattutto della densità di codice, che è di gran lunga più scarsa rispetto agli compilatori. Giusto per rendere l'idea, la lunghezza media delle istruzioni x86 è di 3,42 byte per l'intero bouquet di applicazioni che ho usato (31, delle più svariate: da arm-none-eabi-gdb.exe a WinUAE.exe, passando per ffmpeg_32.exe, Neverwinter.exe, Skype.exe, sublime_text_32.exe, ecc.). Se di queste seleziono soltanto quelle compilate con GCC (sono 6: arm-none-eabi-gdb.exe, cc1.exe, cc1plus.exe, ffmpeg_32.exe, Kodi.exe, lto1.exe), la lunghezza media è di ben 3,93 byte. Per x86-64, invece, la lunghezza media è di 4,05 byte (su 25 applicazioni), mentre prendendo le sole due applicazioni GCC (soltanto 2: ffmpeg_64.exe, mame64.exe) diventa di ben 5,18 byte (colpa di MAME, che ha lunghezza media molto alta: ben 5,52 byte). Posto che quelle GCC sono troppo poche, il trend rimane comunque superiore a quello delle applicazioni non compilate con GCC. E ti posso dire che se dovessi tenere conto soltanto di GCC come benchmark da usare per la densità di codice, potrei andare a stappare subito una bottiglia di buon Dom Pérignon, visto che la mia architettura attualmente mostra una lunghezza media nettamente migliore rispetto a GCC (3,25 byte: -17,28% per x86. 3,76 byte: -27,35% su x86-64) che rispetto a tutti i compilatori (incluso GCC. 3,12 byte: -8,72% per x86. 3,26 byte: -19,35% su x86-64). Questa lunga digressione per chiarire meglio diversi concetti, che poi vengono ripresi anche in altre parti di questa discussione, così si può usare questa parte come comodo punto di riferimento generale. Quote:
C'è qualche altro commento che riporta delle informazioni interessanti. Non riporto tutto il messaggio, ma soltanto la parte iniziale, che è anche la più importante in questo contesto: Haswell register renaming / unfused limitsCome vedi usare immediati porta dei vantaggi, perché NON si usano registri, e quindi non si applica il limite del register renamer. Quote:
Quote:
Se di ottimizzazioni possiamo parlare è che questa micro-op cache funge sostanzialmente da cache L0, e quindi i decoder non sono sempre attivi. Anzi, mi pare che vengano spenti l'80% del tempo, se non ricordo male le dichiarazioni di Intel di diversi anni fa (probabilmente la situazione è ancora migliorata adesso). Quote:
Paper che però è viziato, visto che per RISC-V GC hanno "casualmente" messo soltanto il numero di micro-op "fused", e non il numero di istruzioni vere e proprie. Però per il resto i dati sono affidabili. ARMv8 fa molto bene, e persino meglio di RISC-V GC "micro-op fused", ma a livello di numero di istruzioni eseguite rimane comunque sotto a x86-64. Ciò che sorprende di questo paper è il dato relativo al "Dynamic Instruction Bytes", ossia il numero di byte di tutte le istruzioni eseguite. A parte il fatto che, al solito, il paper è biased, avendo "stranamente" gli autori rimosso tale informazione per x86 (il che non sorprende: anche dalle mie statistiche, che ho riportato sopra, la lunghezza media delle istruzioni è nettamente migliore di x86-64, assestandosi sui 3,42 byte col mio bouquet, contro i 4,05 di x86-64), è il dato relativo a x86-64 che risulta decisamente lusinghiero (cosa che francamente non avrei mai detto, visto che fa decisamente peggio di x86), superando tutte le altre architetture riportate nella tabella (sì: persino ARMv7), fatta eccezione per RISC-V GC che offre i migliori risultati. ARMv8 si difende, ma c'è un netto distacco da x86-64 (e, soprattutto, da RISC-V GC). C'è da dire che non è affatto chiaro se per ARMv7 sia stata utilizzata anche Thumb-2, visto che non v'è traccia né menzione alcuna nel paper. Potrebbe essere anche questo frutto del bias del paper (che non mi sorprenderebbe affatto): tagliare fuori Thumb-2, che è rinomata per fare molto bene a livello di densità di codice. Preciso, però, che non puoi eseguire contemporaneamente istruzioni Thumb-2 assieme a quelle ARM normali: o esegui le une o le altre, e non puoi mischiarle. Puoi soltanto passare dalla modalità ARM a Thumb-2 (che non è soltanto a 16-bit. Anzi, la maggior parte delle istruzioni sono a 32-bit) e viceversa facendo uso di apposite istruzioni, questo sì. In sintesi: nonostante x86-64 sia una brutta architettura per quanto riguarda la struttura degli opcode e il forzato usato di prefissi (specialmente rispetto a x86), non ne esce affatto male confrontata con architetture nuove di pacca, che non hanno dovuto portarsi dietro alcun legacy. Quote:
Per il resto quello che prospetti è uno scenario ideale, dove avresti tante istruzioni da eseguire linearmente/sequenzialmente, e quindi potresti permetterti il lusso di piazzarle distanziando le load da quelle che poi ne useranno i valori. Poi vai a prendere il codice reale, e vedi che queste gigantesche liste di istruzioni sequenziali sono alquanto rare, perché i casi comuni sono di piccoli gruppi di istruzioni intervallate/farcite di salti e da tante chiamate a subroutine. Per cui spesso capita che, invece, le load siano vicinissime o addirittura attaccate alle istruzioni che ne useranno il risultato, come puoi vedere anche negli spezzoni di codice che sono stati riportati nel paper che ho fornito. Quote:
Quote:
Quote:
Ciò nonostante riesce a generare istruzioni facenti uso delle famigerate modalità d'indirizzamento indicizzate/scalate, come puoi vedere anche dal paper che ho riportato, e che fanno la differenza, specialmente rispetto a RISC-V. Quote:
Quote:
AArch64 è l'antitesi di RISC-V. E se consideri che ARM abbia progettato da zero quest'architettura, lascia pensare molto su quale macrofamiglia, fra RISC e CISC, abbia avuto la meglio nelle loro decisioni. Quote:
Ma riguardo all'uso dei registri non ci sono privilegi: vengono usati tutti e 16. Te ne accorgi subito disassemblando un qualunque binario x86-64. Quote:
Se l'obiettivo è quello di chip ridotti all'osso, allora c'è da alzare le mani: RISC-V vince a mani basse. Perfino AArch64 non potrebbe assolutamente competere, visto che si tratta di un'ISA enorme e complessa, seconda soltanto a x86-64, per l'appunto. Quote:
Sul precaricamento vedi sopra. Quote:
Quote:
Quote:
I processori che hanno già implementato le estensioni attualmente standardizzate continueranno a funzionare regolarmente, ma non potranno usare le future estensioni che rimapperanno alcuni opcode. Viceversa, quelli che useranno le future estensioni non potranno far girare i binari attuali, perché dovranno usarne di compilati appositamente per le nuove estensioni. Quote:
C'è e ci sarà frammentazione, insomma: l'esatto opposto di quello che avevano sbandierato anni fa vantandosi del loro modello con le estensioni definite, e che adesso cercano malamente di nascondere sotto il tappeto ridefinendo a loro consumo il concetto di estensione, e creando una miriade di sotto-estensioni.
__________________
Per iniziare a programmare c'è solo Python con questo o quest'altro (più avanzato) libro @LinkedIn Non parlo in alcun modo a nome dell'azienda per la quale lavoro Ho poco tempo per frequentare il forum; eventualmente, contattatemi in PVT o nel mio sito. Fanboys |
|||||||||||||||||||||||||||
26-12-2020, 08:38 | #51 |
Senior Member
Iscritto dal: Jan 2002
Città: Germania
Messaggi: 26107
|
Da da arm-none-eabi-gdb.exe (x86):
Codice:
0x0072652f (7) c7042458059200 MOV DWORD [ESP], 0x920558 0x00726536 (5) e8b5fbffff CALL 0x7260f0 0x0072653b (1) 90 NOP 0x0072653c (1) 90 NOP 0x0072653d (1) 90 NOP 0x0072653e (1) 90 NOP 0x0072653f (1) 90 NOP Codice:
0x0000000140d554cb (8) 48c745b000000000 MOV QWORD [RBP-0x50], 0x0 0x0000000140d554d3 (5) e898faffff CALL 0x140d54f70 0x0000000140d554d8 (1) 90 NOP 0x0000000140d554d9 (1) 90 NOP 0x0000000140d554da (1) 90 NOP 0x0000000140d554db (1) 90 NOP 0x0000000140d554dc (1) 90 NOP 0x0000000140d554dd (1) 90 NOP 0x0000000140d554de (1) 90 NOP 0x0000000140d554df (1) 90 NOP Questa schifezza fa aumentare in maniera consistente (perché il codice è PIENO di padding come quello, visto che i salti vengono allineati ai 16 byte) il numero di istruzioni/uop sia totali sia dinamicamente eseguite: ovvio che RISC-V guadagni su questo fronte...
__________________
Per iniziare a programmare c'è solo Python con questo o quest'altro (più avanzato) libro @LinkedIn Non parlo in alcun modo a nome dell'azienda per la quale lavoro Ho poco tempo per frequentare il forum; eventualmente, contattatemi in PVT o nel mio sito. Fanboys |
29-12-2020, 01:52 | #52 |
Senior Member
Iscritto dal: Jan 2007
Messaggi: 5264
|
|
29-12-2020, 02:22 | #53 |
Senior Member
Iscritto dal: Oct 2002
Messaggi: 4982
|
ma si potrebbe avere un riassuntino degli ultimi 9 o 10 post?
tipo due righe, strette strette
__________________
____€UROPA: comunità di -PAGLIACCI €SP€RI€NTI SOLO del "B€N VIV€R€" come fosse COMANDAM€NTO nel loro PROGR€SSISMO di SCIMMI€ S€MPR€ PIU' TOTALI____Uno, Nessuno, Centomila Buchi... del mentore Pirandello, tutorialista a vuoto nonchè psico-teatralizzante nichilista e senza esiti se non il palcoscenico |
29-12-2020, 03:15 | #54 | |||||||||||
Senior Member
Iscritto dal: Jan 2007
Messaggi: 5264
|
Quote:
Quote:
Quote:
Semplicemente potendo ripartire quasi da zero con il set d'istruzioni a 64bit ha potuto fare scelte che Intel ed AMD non si possono manco sognare ed ha potuto basare molte decisioni sui risultati concreti ottenuti dalle diverse implementazioni RISC e CISC realizzate fino a quel punto. Quote:
Inoltre proprio per la natura aperta di Risc V alla fine ci sarà una selezione naturale sul campo come è avvenuto con i S.O. open source dove quello attualmente più diffuso (Linux) decisamente non è il più "accademicamente puro". Quote:
E guardacaso .... Quote:
Quote:
Quote:
Leggendo quella paper sostanzialmente parlano di soluzioni implementative per architetture "ad alte prestazioni" che permettono di far girare lo stesso codice anche su architetture più semplici/spartane. Quote:
Quote:
Quote:
Risc V di suo è ben lontano dall'essere perfetto, anzi, basta che sia "abbastanza buono" in settori dove gli x86 e gli x86-64 sono improponibili e dove l'ARM comporta costi aggiuntivi a livello di IP o limitazioni su cosa si può fare senza che ti saltino addosso gli avvocati di ARM Ltd. |
|||||||||||
29-12-2020, 03:26 | #55 | |
Senior Member
Iscritto dal: Jan 2007
Messaggi: 5264
|
Quote:
Chiedo questo perchè mi sembra che versioni relativamente recenti di GCC ottimizzino in modo decisamente migliore di quel che si vede sopra, usando anche solo -O2 o -O3 (a meno che non vengano forzati alignment balordi con le -falign-XXXX). |
|
29-12-2020, 10:23 | #56 | ||||||||||||||
Senior Member
Iscritto dal: Jan 2002
Città: Germania
Messaggi: 26107
|
Quote:
Quote:
https://www.anandtech.com/show/1611/6 Ben 5 porte dedicate alle sole istruzioni intere/scalari, di cui due porte/ALU con throughput doppio (praticamente è come se fossero due porte ciascuna). Quote:
Quote:
Lo scheduling di load & op è certamente utile, e anzi necessario, per i RISC con micro-architettura in-order. Quote:
Il tutto con innegabili benefici su tutti i fronti: dal minor numero di transistor utilizzati, ai consumi più ridotti, e infine alle prestazioni nettamente migliori. In buon sostanza (!) con x86-64 avrebbe potuto fare sostanzialmente quello che ARM ha fatto con AArch64/ARMv8 (ma con risultati nettamente migliori). Solo che AMD ha preferito mettere una semplice e veloce pezza su x86, per non perdere tempo a riprogettare una soluzione migliore. Quote:
Il punto è proprio questo. Quote:
Quote:
Questa è un'intrinseca caratteristica dei CISC, che prescinde dal numero di registri. Infatti la mia architettura ne ha ben 32 GP, e consente ugualmente di specificare valori immediati (estendendone anche di molto l'utilizzo rispetto a x86/x86-64). Quote:
Nel paper hanno messo soltanto le uop fused, perché sono di numero minore rispetto al numero di istruzioni, proprio perché sono fused: ossia derivano da due istruzioni che sono state fuse. Ed è, appunto, il motivo per cui hanno messo soltanto il dato delle uop fused, anziché il numero di istruzioni, come hanno fatto con tutte le altre architetture. E' un'omissione volontaria, insomma, per nascondere un dato scomodo. Quote:
Quote:
Quote:
Quote:
Codice:
0x0000000140e7ce18 (7) 488d0de1a08802 LEA RCX, [RIP+0x288a0e1] 0x0000000140e7ce1f (5) e89cfaffff CALL 0x140e7c8c0 0x0000000140e7ce24 (1) 90 NOP 0x0000000140e7ce25 (1) 90 NOP 0x0000000140e7ce26 (1) 90 NOP 0x0000000140e7ce27 (1) 90 NOP 0x0000000140e7ce28 (1) 90 NOP 0x0000000140e7ce29 (1) 90 NOP 0x0000000140e7ce2a (1) 90 NOP 0x0000000140e7ce2b (1) 90 NOP 0x0000000140e7ce2c (1) 90 NOP 0x0000000140e7ce2d (1) 90 NOP 0x0000000140e7ce2e (1) 90 NOP 0x0000000140e7ce2f (1) 90 NOP Quote:
configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libdav1d --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libsrt --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvmaf --enable-libvorbis --enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex --enable-libxvid --enable-libaom --enable-libmfx --enable-ffnvcodec --enable-cuda-llvm --enable-cuvid --enable-d3d11va --enable-nvenc --enable-nvdec --enable-dxva2 --enable-avisynth --enable-libopenmpt --enable-amf Trattandosi di FFMPEG mi aspetto che sia compilato almeno con -O2.
__________________
Per iniziare a programmare c'è solo Python con questo o quest'altro (più avanzato) libro @LinkedIn Non parlo in alcun modo a nome dell'azienda per la quale lavoro Ho poco tempo per frequentare il forum; eventualmente, contattatemi in PVT o nel mio sito. Fanboys |
||||||||||||||
29-12-2020, 13:16 | #57 |
Senior Member
Iscritto dal: Aug 2001
Città: Novara (NO)
Messaggi: 19637
|
mission impossible
__________________
ASUS N76VZ +crucial m500 Dell Latitude E5430 iPad 2017 Huawei nova 5t con Very samsung tv 55m5500 ps4,wiiu exVODA 82/18-78/16-77/13-90/11 exWIND 95/14-95/19-85/19-81/22 fritzbox 7490 su Tiscali 936/288 |
06-01-2021, 06:39 | #58 | |||||||||
Senior Member
Iscritto dal: Jan 2007
Messaggi: 5264
|
Innanzitutto chiedo scusa per non aver risposto prima, avevo perso di vista questa discussione.
Quote:
(16bit nelle prime versioni dei Pentium 4 che supportavano solo le istruzioni x86, 32bit nelle versioni con supporto delle x86-64) e non è che potessero processare due istruzioni per ciclo. Quote:
Quote:
Quote:
Quote:
Il compromesso migliore è quello che ha scelto (anche cosiderando cosa si poteva implementare con i processi produttivi disponibili in quel periodo). ARM invece fino a quel momento con AArch32 da almeno più di un decennio aveva privilegiato i bassi consumi rispetto alle prestazioni e quindi era decisamente molto meno problematico avere un set di istruzioni a 64bit "tutto nuovo" e con buone prestazioni nella modalità a 32bit (ma anche li si è rivelato necessario mantenere alcune similitudini a livello di modalità di indirizzamento e "mappatura" sulle unità di esecuzione) Quote:
Di solito se c'e' di mezzo un loop, a parte l'indicizzazione iniziale all'inizializzazione del ciclo, le indicizzazioni ripetute si possono rifattorizzare in incrementi/decrementi di puntatori ottenendo codice che gira più efficientemente anche sugli x86 ed x86-64. Inoltre se l'indicizzazione non è per elementi che sono potenze di due, si finisce con l'usare l'indirizzamento indiretto o base+offset dopo aver fatto i calcoli di indicizzazione con somme/shift/moltiplicazioni. Se ne può fare a meno se si vuole un set d'istruzioni "base" che sia il più spartano possibile in termini di rapporto costo/prestazioni. Infatti sebbene ARM implementi modalità di indirizzamento "complesse" per le load/store, nelle estensioni thumb queste si riducono a base+offset (dove offset può essere una costante oppure un registro) e push/pop per lo stack pointer. Quote:
Inoltre per come sono codificate le istruzioni Risc V la cosa rimane meno complicata della decodifica delle istruzioni x86-64 ... e questo considerando pure che le attuali istruzioni Risc V sono a 16bit oppure 32bit "senza fusione" ma che le specifiche prevedono già istruzioni lunghe 48, 64, .. 176 bit (più un prefisso per ulteriori istruzioni a 192bit o superiori). Quote:
Quote:
possono essere attivate con i valori di default oppure si può optare per un tuning ad hoc per ridurre la generazione di un numero eccessivo di NOP di allineamento. Ad esempio: Codice:
-falign-labels -falign-labels=n -falign-labels=n:m -falign-labels=n:m:n2 -falign-labels=n:m:n2:m2 m è il "limite di sfrido primario", ovverosia si generano NOP di allineamento ad n byte solo se si generano meno di m NOP. n2 "allineamento secondario" è il numero di byte a cui allineare le destinazioni dei branch se l'allineamento primario fallisce a causa di sfrido superiore ad m. m2 è il "limite di sfrido secondario", ovverosia si generano NOP di allineamento ad n2 byte solo se si generano meno di m2 NOP. Es: Codice:
-falign-labels=32:5:16:3 oppure allineali a 16 byte se questo richiede al massimo 2 NOP oppure non tentare di allineare in tutti gli altri casi |
|||||||||
06-01-2021, 10:10 | #59 | |||||||||||||
Senior Member
Iscritto dal: Jan 2002
Città: Germania
Messaggi: 26107
|
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Il problema grosso ce l'avevano quelle in-order, come avevo già datto. E lì effettivamente con pochi registri hai difficoltà. Ma è anche vero che, in questo caso, un'ISA CISC consente di evitare l'uso di registri addizionali (con annesse dipendenze), e inoltre avendo calcolo dell'indirizzo già integrato in uno (o più, per quelli più complicati) stage della pipeline il processore può immediatamente procedere con la lettura (e meglio ancora per la scrittura) del dato mentre in parallelo procede con la lettura degli altri registri, e quando il dato è pronto (in genere la cache L1 dati nei vecchi processori in-order è di 2-3 cicli, essendo di dimensioni ridotte) può calcolare il tutto. Non è certo un caso che i CISC in-order abbiano avuto prestazioni migliori rispetto a equivalenti RISC, come abbiamo già visto. Quote:
Idem con x86-64 che consente di far girare le vecchie applicazioni x86 assieme a quelle native. Ovviamente entrambe le ISA a 64 bit sono incompatibili con le precedenti a 32-bit della stessa famiglia, e richiedono ricompilazioni delle applicazioni, nonché adattamenti nel caso di integrazione di assembly nel codice. Come vedi non c'è proprio alcuna differenza. E' soltanto AMD che ha avuto fretta di tirare fuori un'ISA a 64 bit, mettendo una mala pezza su x86. Quote:
Infatti è proprio il motivo per cui, non a caso, RISC-V perde molto in quel benchmark. Quote:
There's no free lunch... Quote:
Quote:
Come lo sanno molto bene anche i progettisti di RISC-V, che però nei loro talk di pura propaganda che fanno alle conferenze mettono nelle slide che x86/x64 sia un'ISA a lunghezza variabile (sacrilegio!) e la cui lunghezza delle istruzioni arrivi a ben 15 byte (quasi un'intera linea di fetch!!). Squallidi ipocriti... Quote:
Quote:
Il codice che ho riportato prima dimostra che il compilatore ha ottimizzato per l'allineamento dopo i salti, aggiungendo le necessarie istruzioni di padding. Ed è una cosa giustissima, che ci aspetta proprio per questo. Il problema è che il padding che emette è a dir poco orribile e, ammazza le prestazioni visto che c'è una valanga di NOP, che anche se non fanno niente... devono essere eseguite (nonché conteggiate)! La soluzione a questo problema esiste da eoni, ed è molto semplice: in base al numero di byte di padding (che va da 1 a 15), è sufficiente utilizzare UNA apposita istruzione di NOP della lunghezza richiesta. Come fanno gli altri compilatori. Sì, perché x86/x64 hanno NOP di dimensione diversa. In questo modo il padding viene aggiunto correttamente, e a livello di esecuzione il processore esegue UNA sola istruzione NOP. E vissero tutti felici e contenti... E il tutto senza richiedere strane e oscure ulteriori opzioni di compilazione.
__________________
Per iniziare a programmare c'è solo Python con questo o quest'altro (più avanzato) libro @LinkedIn Non parlo in alcun modo a nome dell'azienda per la quale lavoro Ho poco tempo per frequentare il forum; eventualmente, contattatemi in PVT o nel mio sito. Fanboys Ultima modifica di cdimauro : 06-01-2021 alle 10:13. |
|||||||||||||
08-01-2021, 02:31 | #60 | ||||||||||||
Senior Member
Iscritto dal: Jan 2007
Messaggi: 5264
|
Perchè anche se le ALU dei Pentium 4 giravano al doppio del clock, ricevevano una singola microistruzione per ciclo di clock che agiva su un singolo registro.
Se ricordo bene, il vantaggio che davano era in termini di area e di riduzione del clock skew nell'ALU. Quote:
Quote:
Basta pensare che ad esempio è possibile implementare delle stack machine con esecuzione out-of-order in teoria fantastiche come compattezza del codice, ma che poi stressano parecchio le unità di load/store. Quote:
Quote:
Quote:
Quote:
ARM A32 non aveva vincoli di retrocompatibilità quando è nato e come formato delle istruzioni era semplice e regolare, mentre l' 80386 doveva essere retrocompatibile con l' 80286 che a sua volta doveva essere retrocompatibile con l'8086 che a sua volta fu pensato per facilitare il porting di applicazioni scritte in assembly per l'8080 se ricordo bene. Quote:
Aveva provato a farlo con gli iAPX 432 per poi abbandonarlo e concentrarsi sull'80386. Poi ci ha riprovato con i "suoi" RISC i80960 (principalmente per roba embedded) ed i80860 (che tentò di piazzare come RISC per workstation e server). Ed infine c'e' stato l'Itanium che questa volta "per retrocompatibilità" nella prima versione aveva in hardware l'equivalente in prestazioni ad un i80486. Ma prima che Intel ritornasse sui suoi passi e mettesse la sua pezza, quella volta fu AMD a farlo e non è che abbia fatto un lavoro peggiore di Intel a riguardo. Quote:
Quote:
RV32I o RV64I sono la "versione spartana" per quando ti serve una cpu senza tante pretese, poi a colpi di estensioni diventa qualcosa che si adatta a casi d'uso di ogni tipo. Non è "perfetta", basta che sia sufficientemente versatile e con meno vincoli di quelli che si avrebbero utilizzando ARM o x86. Quote:
Stai ancora guardando alle origini di Risc V mentre ora di fatto è diventato altro. Quote:
Non è solo questione di avere un core open source, tutto l'ecosistema che si sta costruendo attorno nasce da esigenze reali a livello accademico e di R&D che stanno piano piano aprendosi la strada in altri ambiti. Poi se avrà successo così oppure se ci sarà un Risc VI o se la cosa finirà in un ecosistema frammentato è ancora tutto da vedere, ma a livello di microcontroller e core "di servizio" mi sembra che stia facendosi strada cominciando dalla fascia bassa. Quote:
Nell'esempio su godbolt.org che ho linkato sopra, ho forzato "-falign-labels=32" in modo da rendere evidente l'inserimento di NOP "lunghi"; ma in generale a partire dal livello generico -O1 vengono attivate tutte le -falign-XXXX su valori di default che fanno scattare la generazione dei NOP (lunghi e corti a seconda delle esigenze) solo se non si genera troppo sfrido. |
||||||||||||
Strumenti | |
|
|
Tutti gli orari sono GMT +1. Ora sono le: 15:00.