Link alla notizia: https://www.hwupgrade.it/news/cpu/cpu-cinesi-un-possibile-pericolo-per-intel-e-amd-in-3-5-anni-verita-o-affermazione-di-comodo_105649.html

Il massimo dirigente di Intel afferma che entro 3-5 anni le realtà locali cinesi che progettano CPU rappresenteranno un forte concorrente per l'azienda. La dichiarazione è stata rilasciata durante il Congresso nazionale del Partito Comunista Cinese.

Click sul link per visualizzare la notizia.

Vista la velocità di evoluzione di ARM nel mercato desktop/server, e il fatto che in verità qualsiasi architettura RISC può fare meglio di x86 con meno transistor, basta investirci sopra un sacco di soldi per coprire il gap prodotto in anni di monopolio, è chiaro che x86 tra un lustro non sarà più la regina indiscussa del mercato, né quello desktop né quello server, cioè gli unici due mercati dove ancora persiste.
Nei telefoni e in tutti gli altri apparecchi portatili x86 non c'è mai stata (e per ovvie ragioni, non compatibilità da mantenere e maggiori consumi per stesse prestazioni, con oltre tutta una serie di problemi per metterci roba custom accanto al core, tipo unità dedicate per lavori particolari).
In Cina non c'è lo zoccolo della retro compatibilità da superare, quindi qualsiasi architettura che emergerà va bene.
E infine, non dobbiamo pensare che la Cina debba sfornare qualcosa che vada più del 12900K o del 5950X per essere competitiva: le basta anche roba che come picco va la metà che per il mercato interno va più che bene (non ditemi che con un PC equivalente a 6 core x86 non potete essere produttivi, magari pure senza usare le applicazioni bloatware di MS).
Nel mercato HPC, al massimo mette più nodi con più CPU per colmare il gap.
Le memorie sono anni che se le fanno in casa in barba ai brevetti occidentali.

Direi che sì, tra 5 anni la Cina potrebbe diventare quasi indipendente dal mondo occidentale per quanto riguarda la tecnologia informatica.

tra il dire ed il fare ce sta sempre di mezzo.....

tra il dire ed il fare ce sta sempre di mezzo.....
..lo stretto di taiwan ?

basta investirci sopra un sacco di soldi per coprire il gap prodotto

Questo non è sempre vero, ci sono innumerevoli casi di aziende che hanno investito un sacco di soldi senza riuscire a colmare il gap. Basti pensare all'ultimo fiasco di MS nel mobile.

E comunque non sai dove saranno Intel e AMD tra 5 anni. Io credo che nasceranno delle architetture ibride vedi AMD con xilinx.

Pensare che gli stati uniti resteranno sempre il top del top nel mondo della tecnologia finché il genere umano esisterà, è da folli,altrimenti l'Europa,da dove è partita la moderna civilizzazione e sviluppo di tecnologie (si intente da 500 anni fa a questa parte) dovrebbe essere top on the Word!
La storia insegna che prima o poi arriva qualcuno più indietro di te e ti supera,come un giorno verrà superata la Cina e qualsiasi altro impero,idem per l'impero statunitense.

tra il dire ed il fare ce sta sempre di mezzo.....

Questo non è sempre vero, ci sono innumerevoli casi di aziende che hanno investito un sacco di soldi senza riuscire a colmare il gap. Basti pensare all'ultimo fiasco di MS nel mobile.

E comunque non sai dove saranno Intel e AMD tra 5 anni. Io credo che nasceranno delle architetture ibride vedi AMD con xilinx.

Attenzione che nessuno pretende che ci sia la SUPREMAZIA delle CPU cinesi.
Qui si parla do CONCORRENZA!

Cioè, non è che le cpu china debbano essere parimerito o superiori alle proposte intel o amd.. qui per fregarsi una quota di mercato basta e avanza che abbiano una gamma di CPU con performance buone e prezzi abbordabili.

Ce l'ha fatta apple, non vedo perche' non debbano farcela i cinesi.

Intanto il mio primo serverino era VIA C-7, perché sia AMD che Intel consumavano troppa corrente. Per quanto fosse la nicchia di una nicchia, persa non appena Intel è uscita con gli Atom, c'è già stata una supremazia ;)

Attenzione che nessuno pretende che ci sia la SUPREMAZIA delle CPU cinesi.
Qui si parla do CONCORRENZA!

Cioè, non è che le cpu china debbano essere parimerito o superiori alle proposte intel o amd.. qui per fregarsi una quota di mercato basta e avanza che abbiano una gamma di CPU con performance buone e prezzi abbordabili.

Performances buone e prezzi abbordabili, sante parole!

E magari S.O. di base, snelli, efficienti ed user friendly che facciono solo quel che deve fare un S.O. (distro Linux addomesticate, perchè no!).

Basta con questi macigni che usano la maggior parte delle risorse per gestire se stessi ed il proprio bloatware.

Ben venga tutto ciò, made in USA o China o anywere che sia.

Questo non è sempre vero, ci sono innumerevoli casi di aziende che hanno investito un sacco di soldi senza riuscire a colmare il gap. Basti pensare all'ultimo fiasco di MS nel mobile.
Qui si parla di sviluppo di tecnologia in un mercato che non ha alcuno zoccolo duro per l'adozione. Non si parla di costi e problemi di adozione di una tecnologia già sviluppata.
Sono 2 cose differenti.
Io parlo di rendere le architetture (qualsiasi esse siano) capaci di elaborare una grande quantità di dati e con tutti i crismi delle CPU moderne (supporto alla virtualizzazione e tutti i tricche tracche che sono stati sviluppati per rendere un core consumer un core capace di lavorare in coordinazione con centinaia d'altri in un sistema con TB di memoria e con isolamento completo del processo).
Basta mettere abbastanza soldi e tra 5 anni anche MIPS o RISC-V può sfornare una CPU capace di entrare in un HPC.
Per lo sviluppo SW, si parte da zero comunque, per cui uno vale l'altro.


E comunque non sai dove saranno Intel e AMD tra 5 anni. Io credo che nasceranno delle architetture ibride vedi AMD con xilinx.
E che te ne fai di queste architetture ibride? Intel sono già 5 anni che le produce e non mi sembra che siano il non plus ultra se non in mercati di super nicchia dove la FPGA (che ha un costo e non indifferente pure nei consumi) svolge un ruolo particolare solo per quel tipo di applicazione e basta.
Con ARM se davvero hai bisogno di quella particolare elaborazione, fai prima a metterci una unità apposita nel die della CPU: costa un po' di più in costi fissi, ma consuma sicuramente meno, rende di più e in grandi volumi può non essere poi così troppo costosa rispetto ad una FPGA aggiunta a ogni CPU.

La Cina potrebbe sponsorizzare una bella Apple di stato, così se ne uscirebbe con un bel M1C. :D

@CrapaDiLegno

Ti sbagli alla grande, è dai tempi dei primi Pentium II e Pentium Pro che intel adotta la tecnologia RISC e idem fece AMD con i suoi primi processori K6

La compatibilità con il codice X86 è garantita da specifiche unità nel die del processore che si occupano di convertire il codice X86 (con istruzioni di lunghezza variabile) nel codice RISC (con istruzioni di lunghezza fissa); queste unità di codifica dal codice X86 al codice RISC vero e proprio, si occupano anche di analizzare il flusso di elaborazione del codice stesso e riordinare le istruzioni in una sequenza più efficiente, consentendo per esempio di prevedere i salti e disporre il processore alle esecuzioni speculari e parallele ...

@CrapaDiLegno

Ti sbagli alla grande, è dai tempi dei primi Pentium II e Pentium Pro che intel adotta la tecnologia RISC e idem fece AMD con i suoi primi processori K6

La compatibilità con il codice X86 è garantita da specifiche unità nel die del processore che si occupano di convertire il codice X86 (con istruzioni di lunghezza variabile) nel codice RISC (con istruzioni di lunghezza fissa); queste unità di codifica dal codice X86 al codice RISC vero e proprio, si occupano anche di analizzare il flusso di elaborazione del codice stesso e riordinare le istruzioni in una sequenza più efficiente, consentendo per esempio di prevedere i salti e disporre il processore alle esecuzioni speculari e parallele ...

No, non mi sbaglio per niente.
La conversione di istruzioni x86 in micro istruzioni RISC non cambia nulla riguardo alla povertà dell'ISA disponibile al programmatore, così come non risolve per nulla i problemi relativi alla gestione di un HW più complesso.
La conversione serve solo per evitare che la complessità del core raggiungesse quella di un supercomputer su unico die per riuscire a decodificare, riordinare e ottimizzare quella robaccia di ISA.
Ma da lì a raggiungere quello che una ISA RISC riesce a fare se ben progettata ce ne corre eccome.

Hai mai dato un'occhiata ad una ISA RISC per capire le differenze con una CISC? Giusto per darti una idea, in una architettura RISC un operando non è mai in memoria di sistema ma sempre in un registro interno.
E non parliamo del fatto che non sai quanto è lunga una istruzione e neanche se è tutta presente in quel momento nella cache L1I o ti tocca aspettare che si carichi la linea seguente per poter finire la decodifica.

Al di la del fatto che ad Intel/AMD possa bruciare il sederino :ciapet: visto che nel peggiore dei casi perderebbero quote importanti di fatturato, e li finché un azienda privata viene scalzata da un altra azienda privata ci può anche stare.

La vera domanda è: come la prenderebbero gli USA, che alla fine fa il bello e cattivo tempo in quest'ambito con un competitor come la Cina che ha sia How Know (che gli avranno insegnato gli Europei/Usa :asd:) che le capacità industriali per mettere in atto la produzione di questa tipologia di prodotti?

Vuoi vedere che il fatto che intel voglia espandersi in europa non è altro che un tentativo degli usa per tenere ancorato a doppio filo il vecchio continente sulle loro tecnologie?

Chi lo sa....

Al di la del fatto che ad Intel/AMD possa bruciare il sederino :ciapet: visto che nel peggiore dei casi perderebbero quote importanti di fatturato, e li finché un azienda privata viene scalzata da un altra azienda privata ci può anche stare.

La vera domanda è: come la prenderebbero gli USA, che alla fine fa il bello e cattivo tempo in quest'ambito con un competitor come la Cina che ha sia How Know (che gli avranno insegnato gli Europei/Usa :asd:) che le capacità industriali per mettere in atto la produzione di questa tipologia di prodotti?

Vuoi vedere che il fatto che intel voglia espandersi in europa non è altro che un tentativo degli usa per tenere ancorato a doppio filo il vecchio continente sulle loro tecnologie?

Chi lo sa....

Finché non esportano credo che gli USA ingoieranno il rospo.
Ma di sicuro non permetteranno alla Cina di esportare roba tecnologica basata su qualsiasi tipo di brevetto non pagato.
Già la vedo male per la semplice DRAM che la Cina produce avendosela fatta in casa senza pagare il dovuto e che per ora non esporta, mi immagino con chip più complessi la cui ingegnerizzazione e produzione passa dallo sfruttamento di migliaia di brevetti depositati in USA. :banned:

Alla fine però realizzano sempre processori con ISA X86 o ARM su licenza. Della serie, basterebbe revocargliela e sarebbero punto e a capo.

Vista la velocità di evoluzione di ARM nel mercato desktop/server, e il fatto che in verità qualsiasi architettura RISC può fare meglio di x86 con meno transistor, basta investirci sopra un sacco di soldi per coprire il gap prodotto in anni di monopolio, è chiaro che x86 tra un lustro non sarà più la regina indiscussa del mercato, né quello desktop né quello server, cioè gli unici due mercati dove ancora persiste.

ok ho letto fino a qui e poi mi sono fermato

M1 "liscio" 16 milioni di transistor
Max 57 miliardi
Ultra 114 miliardi
i9 11900 6 miliardi

sipario

"eh ma è un soc ci sono dentro anche altre cose", un singolo core performance di un M1 è circa 300 milioni di transistor, di un i9 è circa 230. Ma senza contare la (grossa) cache nel caso dell'M1

dai cmq la tua previsione l'hai fatta, ci ritroviamo tra cinque anni

ormai è 30 anni che "vedrai che tra qualche anno [gli x86 / windows] sarà un ricordo". Sono tipo le barzellette sul sesso, le senti da una vita, le sai a memoria ma sorridi comunque ogni volta :D

E non parliamo del fatto che non sai quanto è lunga una istruzione e neanche se è tutta presente in quel momento nella cache L1I o ti tocca aspettare che si carichi la linea seguente per poter finire la decodifica.

quindi non ho capito la tua tesi. In ogni caso l'isa che hai sotto serve per eseguire cose a più alto livello quindi le differenze tra linguaggio ad alto livello -> compilatore -> isa risc vs linguaggio ad alto livello -> compilatore -> isa cisc -> decodifica cisc risc le hai solo in funzione della capacità di compilatori / unità di decodifica cisc risc

tra l'altro avere un'unità di quel tipo di mezzo in realtà ha un vantaggio perché hai un layer di astrazione che ti permette di cambiare l'isa del processore come ti è più comoda. poi si circola da eoni la storiella che l'unità di decodifica consuma un sacco ma quella è un po' come quella che gli x86 sono ormai da rottamare :ciapet:

come la Cina che ha sia How Know
Ma, ma.......sei sardo? :rotfl:

il Loongson 3 serie 5000 è di poco più potente del mio AMD FX-6300.
tenendo conto che il Loongson è 4 cores; l'FX-6300 è 3 cores fisici ( 6 virtuali ). è evidente che la prestazione single core è scarsa. però io non ho problemi di reattività in nessun ambito, anzi ho declockato per evitare il throttlare nei giochi online.

il desktop cinese è una realtà.

Veramente si parlava di GPU cinesi... che fine hanno fatto?

quindi non ho capito la tua tesi. In ogni caso l'isa che hai sotto serve per eseguire cose a più alto livello quindi le differenze tra linguaggio ad alto livello -> compilatore -> isa risc vs linguaggio ad alto livello -> compilatore -> isa cisc -> decodifica cisc risc le hai solo in funzione della capacità di compilatori / unità di decodifica cisc risc

tra l'altro avere un'unità di quel tipo di mezzo in realtà ha un vantaggio perché hai un layer di astrazione che ti permette di cambiare l'isa del processore come ti è più comoda. poi si circola da eoni la storiella che l'unità di decodifica consuma un sacco ma quella è un po' come quella che gli x86 sono ormai da rottamare :ciapet:
Il set d'istruzioni "visibili al compilatore" non influenza solo la complessità del decoder, ma anche quanti hint si possono passare alla cpu su come eseguire in modo ottimale le operazioni e che interdipendenze hanno.
Il set d'istruzioni "non conta" solo se puoi permetterti di usare molti più gate per realizzare unita di elaborazione più complesse e magari un processo produttivo più avanzato.
Per questo ad esempio gli ARM attualmente hanno i core Cortex-M che usano un set d'istruzioni più ristretto rispetto ai Cortex-A.

Veramente si parlava di GPU cinesi... che fine hanno fatto?
la butto lì:
1)da quello che ricordo le deve sempre produrre TSMC quindi non che aiutino a risolvere lo "sciortagé"
2)il mercato interno cinese è in forte espansione e ne fagociterà il 99,9999%
3) La cortina di ferro i poteri forti non vogliono che lo sapessimo

Comunque sinceramente dubito che davvero nel giro di pochi anni usciranno processori 100% cinesi con caratteristiche tecniche cosi rilevanti, cioè quello che si è visto finora costava come un i7 è aveva le prestazioni di un atom oltre che essere basato su PP obsoleti... D'accordo che hanno i soldi, ma ci vuole tempo fare fare gli stabilimenti ci vuole tempo per fare le architetture (e poi di quale parliamo? x64, ARM o RiscV?) vedremo ma io sono scettico...

Il set d'istruzioni "visibili al compilatore" non influenza solo la complessità del decoder, ma anche quanti hint si possono passare alla cpu su come eseguire in modo ottimale le operazioni e che interdipendenze hanno.
Il set d'istruzioni "non conta" solo se puoi permetterti di usare molti più gate per realizzare unita di elaborazione più complesse e magari un processo produttivo più avanzato.
Per questo ad esempio gli ARM attualmente hanno i core Cortex-M che usano un set d'istruzioni più ristretto rispetto ai Cortex-A.

tutto dipende, cosa che non so, se fai predictor è prima o dopo il decoder. A logica lo metti dopo, e in quel caso cambia niente

cmq il problema di fondo nel dibattito è che:
a) si basa solamente su aspetti teorici
b) su concetti obsoleti (ovvero: si parla di CISC che non esistono più CISC "in hardware", si parla di RISC dando per scontato che rispetti le caratteristiche originali del RISC e non è più vero manco questo, ad es. nelle ISA ARM v8 e v9 ci sono istruzioni che occupano più cicli di clock)
c) e soprattutto: SENZA NESSUN RILEVAMENTO OGGETTIVO

personalmente starei molto cauto a fare qualsiasi tipo di affermazione perché può benissimo essere tutto e il contrario di tutto - anche perché sappiamo perfettamente che non conta la teoria ma la pratica. Nel momento in cui dovessero uscire DATI che "certificano" che una soluzione è più o meno prestante allora avremo una risposta, sennò è l'equivalente high tech della chiacchiera da bar - tant'è che qual è la tesi che circola? Una che abbraccia la complessità della questione e fa una valutazione esaustiva o una riduttiva e assoluta tipo "i RISC sono meglio"? Ecco.

Quando ci sono risposte straordinariamente chiare e semplici a temi straordinariamente complessi significa che è chiacchiera da bar. E tra pandemie e guerre sono un po' saturo di ipersemplificazioni :D (ovviamente non ce l'ho con te, tu hai posto una questione corretta)

quello che mi aspetto è che non ci sia una risposta chiara e definitiva, ma un "dipende", può dipendere da contesto, applicazione, eccetera. Non a caso facendo paragoni tra CPU RISC e x86 di simile complessità non c'è una che supera palesemente l'altra (poi si, dipende dalla microarchitettura, ma quello che vedo è che dipende più dalla microarchitettura che dalla ISA, dentro RISC e CISC la situazione è molto eterogenea)

tutto dipende, cosa che non so, se fai predictor è prima o dopo il decoder. A logica lo metti dopo, e in quel caso cambia niente

Un predictor si mangia un bel mucchietto di gate, come dicevo, dipende dal numero massimo di gate e/o di area sul chip che hai a disposizione.
Se ad esempio devi realizzare una cpu embedded con il consumo più basso possibile ed usando il minor numero di gate, puoi fare ciao ciao al predictor.

Non a caso uno dei vantaggi del set di istruzioni ARM "originale" era che senza un predictor riusciva comunque a fornire prestazioni spettacolari (anche) grazieal fatto di avere la maggior parte delle istruzioni con esecuzione condizionale esplicita.

Quando poi ARM Ltd ha progettato ARMv8, visto che tali cpu sarebbero state realizzate con un budget di gate ed area su chip sufficientemente elevato, hanno puntato su un set di istruzioni pensato ipotizzando di disporre di branch predictor e di esecuzione condizionale implicita, facendo a meno della maggior parte delle istruzioni ad esecuzione condizionale esplicita.

Se il set di istruzioni non fosse stato sufficientemente rilevante, avrebbero potuto tenere le istruzioni ARM a 32bit ed estenderle a 64bit, ma si sono guardati bene dal farlo.


cmq il problema di fondo nel dibattito è che:
a) si basa solamente su aspetti teorici
b) su concetti obsoleti (ovvero: si parla di CISC che non esistono più CISC "in hardware", si parla di RISC dando per scontato che rispetti le caratteristiche originali del RISC e non è più vero manco questo, ad es. nelle ISA ARM v8 e v9 ci sono istruzioni che occupano più cicli di clock)
c) e soprattutto: SENZA NESSUN RILEVAMENTO OGGETTIVO


In realtà di rilevamente oggettivi ne sono stati fatti a bizzeffe.
Chiediti ad esempio come mai le cpu con architettura a stack machine (zero operand) sono usate solo nei casi in cui ti serve qualcosa di super-compatto dove le prestazioni sono un aspetto secondario o meno.
Guardacaso è possibile realizzare processori con set di istruzioni "a stack machine" che possono parallelizzare l'esecuzione tramite espansione in microop riordinabili come avviene con gli x86, solo che per avere un livello di prestazioni equivalenti ad un architettura "a registri" si devono dedicare molte più risorse (gate, area, consumi).


personalmente starei molto cauto a fare qualsiasi tipo di affermazione perché può benissimo essere tutto e il contrario di tutto - anche perché sappiamo perfettamente che non conta la teoria ma la pratica. Nel momento in cui dovessero uscire DATI che "certificano" che una soluzione è più o meno prestante allora avremo una risposta, sennò è l'equivalente high tech della chiacchiera da bar - tant'è che qual è la tesi che circola? Una che abbraccia la complessità della questione e fa una valutazione esaustiva o una riduttiva e assoluta tipo "i RISC sono meglio"? Ecco.

Quando ci sono risposte straordinariamente chiare e semplici a temi straordinariamente complessi significa che è chiacchiera da bar. E tra pandemie e guerre sono un po' saturo di ipersemplificazioni :D (ovviamente non ce l'ho con te, tu hai posto una questione corretta)

quello che mi aspetto è che non ci sia una risposta chiara e definitiva, ma un "dipende", può dipendere da contesto, applicazione, eccetera. Non a caso facendo paragoni tra CPU RISC e x86 di simile complessità non c'è una che supera palesemente l'altra (poi si, dipende dalla microarchitettura, ma quello che vedo è che dipende più dalla microarchitettura che dalla ISA, dentro RISC e CISC la situazione è molto eterogenea)

Infatti! ;) Non ho dato alcuna risposta "semplice" o "complessa" che sia, ma che ho semplicemente affermato che il "peso" del set di istruzioni non è così irrilevante come spesso si sente dire. :read:

Non ho parlato minimamente di RISC vs. CISC, ma di set di istruzioni a prescindere da quanti cicli richiedono per essere eseguite, dimensione delle istruzioni ecc. ecc. e di come il set di istruzione abbia una sua influenza in base ai target di progetto ed alle risorse utilizzabili.

Per farti un esempio estremo, esiste un core bit-seriale con set d'istruzioni RISC-V RV32I (SERV (https://riscv.org/wp-content/uploads/2019/06/12.15-SERV-Zurich-Copy.pdf)) che è quanto di più "anti-RISC" si possa immaginare come implementazione (più di 32 cicli di clock per istruzione :cry: ), ma ha il vantaggio di essere ultra-spartano in termini di link di I/O e gate (al punto che puoi implementare 6000 core SERV in una FPGA Xilinx Virtex UltraScale+ VU37P HBM). :sofico:

In pratica un set di istruzioni "RISC-like" per un architettura "unRISC" dove si pone l'accento sul numero di core e sul minor numero di link di interconnessione a parità di core implementati: una cpu "ornitorinco" (animale a sangue caldo, simil-castoro con becco d'anatra, dotato di senso di elettrolocazione, oviparo ma poi allatta i piccoli dopo la schiusa, pelliccia bioluminescente alla luce UV, i maschi hanno speroni velenosi nelle zampe posteriori, ecc. ecc.). :D

Un predictor si mangia un bel mucchietto di gate, come dicevo, dipende dal numero massimo di gate e/o di area sul chip che hai a disposizione.

ok ma quello che dicevo era un'altra cosa

se il predictor lavora prima del decoder, ovvero sull'ISA x86, ovviamente si trova a fare un lavoro complesso;
se il predictor interviene invece DOPO il decoder, ovvero sull'ISA interna RISC, allora non cambia molto rispetto all'avere una ISA nativa RISC

precisavo però che non ho idea di dove intervenga il predictor negli x86 moderni, se prima o dopo (a logica dovrebbe stare dopo ma in questi casi c'è sempre la fregatura che ti fa preferire l'opposto di cosa diresti guardando la cosa superficialmente dall'esterno)

In realtà di rilevamente oggettivi ne sono stati fatti a bizzeffe.

hai riferimenti? dati / numeri mi interessano

In pratica un set di istruzioni "RISC-like" per un architettura "unRISC" dove si pone l'accento sul numero di core e sul minor numero di link di interconnessione a parità di core implementati: una cpu "ornitorinco" (animale a sangue caldo, simil-castoro con becco d'anatra, dotato di senso di elettrolocazione, oviparo ma poi allatta i piccoli dopo la schiusa, pelliccia bioluminescente alla luce UV, i maschi hanno speroni velenosi nelle zampe posteriori, ecc. ecc.). :D

credo che sia l'esempio più strano e argomentato che mi sia capitato di leggere nella mia vita :rotfl: cmq hai reso perfettamente l'idea :D

ok ma quello che dicevo era un'altra cosa

se il predictor lavora prima del decoder, ovvero sull'ISA x86, ovviamente si trova a fare un lavoro complesso;
se il predictor interviene invece DOPO il decoder, ovvero sull'ISA interna RISC, allora non cambia molto rispetto all'avere una ISA nativa RISC

precisavo però che non ho idea di dove intervenga il predictor negli x86 moderni, se prima o dopo (a logica dovrebbe stare dopo ma in questi casi c'è sempre la fregatura che ti fa preferire l'opposto di cosa diresti guardando la cosa superficialmente dall'esterno)

Che io ricordi nei core recenti il predictor lavora sempre dopo il decoder, ma per la branch prediction si usa anche una specie di cache per taggare gli indirizzi dove iniziano le istruzioni x86 corrispondenti nel caso il core sia costretto a ricaricarle e ripassarle sul decoder.



hai riferimenti? dati / numeri mi interessano

Ci sono un sacco di pubblicazioni in ordine sparso ed articoli/interviste, senza contare le discussioni sui vecchi newsgroup tra progettisti di cpu e simili.

Una delle cose da ricordare è che spesso si parla di altri aspetti ritenuti più importanti, quindi se si fa la classica ricerca con Google o altri motori di ricerca sembra che non ci sia niente.

Ad esempio:
https://www.usenix.org/legacy/events%2Fvee05%2Ffull_papers/p153-yunhe.pdf
Nel documento linkato sopra si fa un confronto tra VM stack based e register based ma le conclusioni si possono estendere anche al numero di registri dei vari set d'istruzioni
(mostrano come più registri visibili al programmatore ed istruzioni a 2..3 operandi richiedano meno istruzioni da eseguire rispetto ad una stack machine, ma con un maggior utilizzo di memoria che in parte riduce il vantaggio apparente delle VM register based).
Questo significa che avere più registri è più vantaggioso, ma in generale porta ad usare maggior memoria per il codice (cosa che influisce negativamente su quante istruzioni riesci a far stare in cache e quanta banda di I/O ti serve per non strozzare il core, quindi in base ai vincoli di implementazione oltre un certo numero N di registri non ci sono vantaggi rispetto ad architetture con meno registri.
Considerazioni analoghe si possono fare per i set d'istruzioni in base a quanto sono "espressivi", quanto costano in termini di memoria e complessità di implementazione le varie istruzioni ecc. ecc.

Per quel che riguarda il set di istruzioni, influisce comunque, ad esempio un maggior numero di registri aiuta il compilatore a "sbrogliare" parte del lavoro di ottimizzazione dell'ordine di esecuzione in modo da sgravare di lavoro (e complessità) il riordino delle microop e la prediction a livello di microarchitettura.

Poi c'e' un altro aspetto legato alle letture e scritture di dati nei registri e sulla memoria; nel forum di Agner Fog viene fatto un esempio concreto:
https://www.agner.org/optimize/blog/read.php?i=415#852
In poche parole, un core Intel Skylake per ciclo di clock può eseguire fino a 10 letture di registri interni per ciclo, 3..4 scritture di registri interni, 2 load dalla cache L1 ed 1 store sempre sulla cache L1.
Questo significa che le operazioni su registri sono molto più semplici ed efficienti da parallelizzare anche su un architettura x86-64, senza contare che le load/store verso la memoria sono molto più costose in termini di consumo.

Sempre riguardo il numero di registri, c'è questa vecchia discussione che è molto illuminante:
https://groups.google.com/g/comp.arch/c/BClo97LG3mo/m/DhEfQXKaRM4J