Intel rivoluziona le CPU? L'azienda pensa ai 'Super Core' definiti tramite software. Che cosa sono

Credo che il supporto dell'OS si riferisca al fatto che probabilmente lo scheduler deve essere modificato per far girare un determinato core in modalita' SDC. Cosi' a naso non credo sia una cosa impossibile da fare. Soprattutto visto che per lo OS scheduler problemi simili non sono affatto nuovi (e.g. si pensi alla gestione di Hyperthreading, Big-Little.. oppure a fare lo scheduling su architetture a chiplet dove 'muovere' un processo tra cores in uno stesso chiplet ha un costo diverso da muoverlo tra diversi chiplet).

Per i compilatori invece probabilmente si tratta di riconoscere sezioni di codice parallele. Ma in parte e' qualcosa che gia' fanno. Alcune ottimizzazioni a livello di compilazione sono fatte per pre-riordinare il flusso di istruzioni di modo che sia piu' facile per una cpu massimizzare l'occupazione delle pipelines.

Qui, da quello che ho capito, si tratta di fare uno step in piu' e indicare esplicitamente i flussi di istruzione da eseguire in parallelo nel binario generato. La vera domanda e' quanto bene i compilatori potrebbero farlo visto che questo introduce un 'vincolo' per il riordino delle istruzioni a run-time. E quindi in alcuni casi il rischio di diminuire anziche' aumentare l'IPC.

Doh, quante stronzate.
L'architettura ibrida è stata annunciata ed è diventata realtà.
E in single core funziona meglio della architettura non ibrida e con SMT della concorrenza.
Che il dopo Nova non sia più ibrida è una tua invenzione. Se non sbaglio lo avevi già detto di Nova. Ora è diventato il dopo Nova.
Tutto il resto sono vaneggiamenti giusto per gettare merda così.
Mi piacerebbe sapere cosa hai detto quanto AMD ha presentato la prima versione di Ryzen: sicuramente sarà stato qualcosa come "che cagata, questi qui che non sanno fare un core completo (Bulldozer docet) ora si inventano di fare core completi ad alte prestazioni su più die separati".

Questa tecnologia, nella sua idea fondamentale, è l'opposto dell'hyper threading. Con l'HT si tenta di sfruttare le parti inutilizzate di core enormi che non riescono a parallelizzare a sufficienza un thread per saturare le tante unità di elaborazione che stanno sotto il front-end. Front end che deve essere extra complicato per riuscire a estrarre istruzioni indipendenti nel flusso di istruzioni X86, set di istruzioni che è una merda assoluta da decodificare con lunghezze variabili, dimensioni di istruzioni enormi, non allineate, che rompe l'accesso pulito alle cache dove magari l'istruzione sta a cavallo delle linee, numero di registri limitato e che va via via sempre più complicandosi ogni nuova architettura che inserisce continuamente nuove estensioni.

Con questo approccio si semplifica notevolmente il front-end e si può snellire il complesso di unità di elaborazione in un singolo core, con tutto quello (positivo) che ne consegue, e si affida l'esecuzione di istruzioni indipendenti del flusso ad un secondo core per parallelizzare più istruzioni.
La complicazione della intercomunicazione tra i core può benissimo essere compensata dalla enorme semplificazione di core monothread meno superscalari di quanto non debbano essere ora come ad esempio sono i core ARM che godono di un set di istruzioni RISC che facilita notevolmente la decodifica e l'esecuzione OoO.
Sono trucchi per cercare di aumentare l'IPC di un set di istruzioni che andrebbe rivisto completamente dopo che hanno perso l'occasione di farlo quando hanno creato il set a 64 bit. IPC che con il metodo attuale richiede trilioni di transistor per essere migliorato di uno sputo.
Con le frequenze che non crescono più, l'aumento di velocità come le ottieni?
Mettendo mille (inutili) mega core in una CPU consumer?
Così migliori solo le barrette dei benchmark, ma le prestazioni degli applicativi veri rimangono la palo.



Non sono un espertone di micro architetture, ma qualcosa la so. Provo a ragionare a voce alta.
Nei core X86 una bella fetta del front-end serve a decodificare le istruzioni x86 e trasformarle in micro operazioni che sono a loro volta riordinate per essere eseguite al meglio dalla parte computazionale che comprende anche 20 unità di elaborazione che possono andare in parallelo.
Per ogni istruzione x86 viene valutata l'indipendenza rispetto alle altre, cioè quando ha necessità di essere sincronizzata, quali risorse usa, quale accesso di memoria richiede e vengono applicate un sacco di trasformazioni interne oltre alle le u-ops necessarie per eseguire l'istruzione (rinomina di registri, creazione di istruzioni di accesso alla memoria, istruzioni di fence e sincronismo) che poi finiscono nella pipeline di esecuzione e quindi alle unità di calcolo parallele.
Altri passaggi sono lo storing delle u-ops in cache per migliorare l'efficienza dei cicli e la branch prection.
E in alcune architetture i front end sono addirittura 2 che lavorano in parallelo anche se il core è mono-thread.
Quindi c'è già un sacco di lavoro nel front-end per individuare la migliore l'istruzione da eseguire al ciclo successivo e cercare di saturare al meglio le unità di elaborazione.

La tecnica che vuole usare Intel in parte semplifica il front-end perché per esempio sarebbe possibile eseguire a full speed le due parti, anche molto lunghe, di un branch condizionato in maniera parallela e gettare il risultati del ramo errato. Per assurdo potrebbe essere esteso all'esecuzione completa in ulteriori core anche dei sotto-rami di questo primo bivio (una sorta di extreme speculative execution).
Già questo semplificherebbe notevolmente la gestione della branch prediction che è una delle cose più complesse che prende parecchio spazio perché oggi ogni branch miss è un disastro di cicli per resettare tutto il lavoro già fatto e ricominciare da zero ed è quello che impedisce di sfruttare pipeline lunghe un chilometro ma con frequenze altissime (Netburst docet).
Inoltre aumenterebbe notevolmente l'IPC per i motivi sopra detti: non dover dipendere da una condizione ritardataria per sapere se eseguire una strada piuttosto che un'altra è stata la cosa che ha maggiormente aumentato l'IPC al punto da dedicare una grandissima fetta del budget di transistor per continuamente migliorare la branch prediction unit.

Ripeto, non dico che questa sia la strada giusta o quella definitiva per migliorare l'IPC del set di istruzioni X86, ma è una alternativa che può essere valida al continuare a fare front-end enormi con back end che tengano il passo dell'eventuale alto numero di istruzioni eseguite in parallelo. E quando l'eventuale non c'è, rassegnarsi al numero di transistor inutilizzati che sono stati inseriti nella CPU.

Ok. Ma, da totale ignorante, l'esecuzione speculativa (eseguire tutti e due i branch di un if statement alla volta e buttare via il risultato sbagliato quando la condizione del jump e' disponibile) non e' qualcosa che viene gia' fatto dalle CPU attuali ? Poi d'accordo al 100% con te che questa tecnica potrebbe semplificare core diventati 'oversize'. E questo probabilmente ha un impatto positivo in termini di latenza, IPC, consumo e complessita' (assumendo che il costo dei canali di comunicazione non sia troppo elevato).

Comunque dall'articolo sembra che ci sia bisogno di un supporto esplicito dei compilatori per sfruttare la tecnica. Quindi, assumendo che questo sia vero, dovrebbero esserci anche delle istruzioni in piu' per fare lo scheduling esplicito di un determinato flusso di istruzioni no?

Sarebbe qualcosa di clamoroso, ma ho paura che NON sarà come lo immaginiamo noi.

Sarà un software con qualche AI che ripartizionerà i carichi in modo adeguato sui vari cores tenendo conto del tipo di cores e distinguendo fra logico e fisico e nient'altro.

Il chè sarebbe comunque niente male "se funzionasse correttamente".


AMD ci provò a fare una cosa del genere via hardware durante il concept della famiglia FX che poi sappiamo come è finita, dietro front totale con parte delle componenti rimaste condivise e strada spianata verso il più grande e mai visto EPIC FAIL della storia delle CPU X86.

No, i core di oggi non eseguono entrambi i rami della condizione, altrimenti non ci sarebbe bisogno di unità di branch prediction così complesse. Oggi i core eseguono quello che è il ramo più probabile, cioè quello che viene scelto dal branch predictor secondo una serie di criteri molto complessi che si rifanno alla storia dei branch precedenti.
Alla fine se quel ramo risulta corretto, hai fatto il giro giusto e hai zero penalità, ma se hai sbagliato allora ti ritocca ripartire dall'istruzione corretta dopo il salto condizionale e rifare tutto con perdite di cicli enormi e una drastica diminuzione dell'IPC.
Problema enorme che aveva ad esempio Netburst di Intel con pipeline lunghissime che in caso di predizione sbagliata doveva pulire una quantità enorme di istruzioni già inutilmente eseguite per tornare un sacco di istruzioni indietro.


L'approccio di AMD era diverso.
AMD aveva un solo front-end per core. Significa una sola area di cache, un solo decoder (anche se era a più vie) e una sola unità di dispatch.
Le due pipeline di esecuzione sparate potevano essere usate solo da due thread separati, una su una pipeline, l'altro sull'altra. Nel caso di esecuzione di un solo thread, una delle due pipeline rimaneva inusata.
Era un tentativo di ottimizzare l'uso dell'hyper threading, non di eseguire più velocemente in singolo thread. La cosa peggiore era che avevano in comune una sola pipeline floating point, che significa che due thread che lavoravano su dei dati floating point, ovvero i carichi multithread più comuni che elaborano dati, andavano in concorrenza e praticamente i due mezzi core ottenevano il throughput di un core single thread.
Secondo problema era la dipendenza della creazione di programmi multithread che ai tempi non era ancora matura a sufficienza.
Oggi il problema non si pone con la gestione di applicativi multi-thread che si risolve mettendo semplicemente quanti più core possibili (mono o SMT), ma il problema rimane per l'esecuzione dei single thread che non possono essere accelerati da un parallelismo esplicito (altra mancanza del set di istruzioni X86).

L'approccio di Intel è simile solo per il fatto di avere a disposizione due pipeline in un core SDC, ma avrebbe 2 decoder, il doppio delle unità INT/FP/AGU e due back-end in grado di scrivere i risultati in cache in maniera indipendente per i due flussi, teoricamente raddoppiando l'IPC se si potesse avere una istruzione indipendente ogni 2.
Il tutto si potrebbe fare anche in un singolo core mega super duper con le stesse tecniche usate oggi, ma il costo dei transistor non avrebbe alcun senso nel momento in cui tale parallelismo non esistesse. Spazio gettato e sappiamo quanto lo spazio sia importante soprattutto quando di vogliono integrare decine di core e non solo una manciata come al tempo di Bulldozer.
Due core snelli che possono eventualmente diventare uno solo anche solo per una frazione di tempo, permetterebbe di avere quanti più transistor attivi possibili senza penalizzare il multithread con aree del die inutilizzate quando invece potrebbero essere dei core funzionanti.

L'approccio di Intel richiede che l'OS decida quando accorpare i due core e dove l'unione avviene:
nel metodo più diretto dovrebbe rimanere fuori dal controllo dell'SDC l'accesso alla seconda cache sia in input che output visto che i dati/istruzioni/TLB e conversioni di indirizzi logici/fisici sono già nel primo core e l'unione sia proprio attivare uno switch su un bus di comunicazione tra i due front-end che passi i dati dal core 1 al 2 e sul back-end per ritornare i risultati dal core 2 all'1, con il front-end del core 1 in grado di decidere quali istruzioni inviare al core 2 e quali invece tenere in locale.
Una seconda possibilità è che si aggiunga una sorta di mini thread director a monte dei due (o più core in modo che il front end del core1 non sia diverso da quello del core 2/3/4 e non si faccia carico di alcuna decisione di dove eseguire le istruzioni. Più complicato ma più flessibile, e lascia i core omogenei tra di loro.
Questi dovrebbero essere i metodi più compatibili e trasparenti possibile al codice già esistente, mentre se la decisione su quali istruzioni vanno eseguite su quali core è a livello SW allora c'è la possibilità che non funzioni perfettamente se non c'è un aiuto da parte del compilatore/virtual machine e che sia applicato solo se l'applicativo è compilato nella giusta maniera (quindi solo con applicativi nuovi e non quelli vecchi).
Ma sono solo tutte ipotesi. Ho il dubbio che se mai verrà implementato sarà dopo il 2030 e per quel periodo magari i compilatori già sforneranno applicativi compatibili con questa approccio.

FX non è dietro front all'ultimo momento come detto in precedenza.
Le peculiarità di FX erano frutto dell'approccio precedente e che non potevano essere riprogettate e quindi l'architettura che ha debuttato era di fatto un riadattato di quello che doveva essere il progetto iniziale.

Che poi anche l'appoccio orginario di FX fosse comunque differente lo sò.

FX come è stato fatto uscire era di fatto un aborto non solo in senso figurato ma anche letterale, ed AMD non ha avuto le palle di riproporre un die shrink tirato in frequenza del Phenom II X6, per poi tirare fuori successivamente una versione octa core con alcuni dei miglioramenti architetturali proposti su FX.

Grazie delle informazioni

Ci deve essere stata qualche incomprensione.
Primo non ho detto che FX (FX è il core consumer dell'architetture Bulldozer, come ora chiamiamo Ryzen quei core dell'architettura Zen) fosse un dietro front di niente. Io ho parlato di front-end e back-end che sono parti fisiche costituenti i core delle CPU.
Poi Bulldozer non era frutto di nessun approccio precedente di AMD visto che AMD aveva appena archiviato l'ottima architettura Phenom e a detta loro Bulldozer era un tentativo di aumentare il numero di core (o di unità di esecuzione se di core completi non si vuole parlare) senza far esplodere il numero di transistor che non potevano permettersi, economicamente parlando.

L'architettura Bulldozer è nata come un architettura che doveva proporre l'inverso del SMT di Intel, per poi fare marcia indietro quando era già in fase avanzata dello sviluppo, quindi quello che è sbucato fuori è di fatto un ibrido frutto di un riadattamento ad un approccio opposto.


FX 8150 ha 1,200 million di transistors
Phenom X6 ha 904 million di transistors

In poche parole FX8150 ha il 30% di transistors in più del Phenom X6, perfettamente compatibile con un teorico passaggio da 6 a 8 cores da parte del Phenom II, in pratica non han risparmiato proprio nulla.

L'FX è stato un fail su ogni linea.
Un Phenom II X8 con frequenze leggermente più alte del 1100T sarebbe stato sicuramente molto migliore.

Non so cosa tu intenda per "inverso di SMT di Intel".
Bulldozer era stata pensata e poi realizzata come architettura per raddoppiare i thread gestiti senza raddoppiare il numeri dei mega core. E infatti come architettura andava bene se gli si davano in pasto 8 thread che processavano INT. Il problema è che per realizzare quei due semi core hanno limitato molto l'IPC e la gestione degli applicativi che non usavano thread gemelli (cioè con le stesse istruzioni ma su dati diversi) è stato un flop clamoroso.
Non so cosa avesse potuto avere di diverso da quella che tu ritieni essere stata la prima bozza dell'architettura visto che il problema già al giorno uno del suo design era la quantità di transistor e il costo finale e il tutto è stato pensato per contenere quei valori.