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

[Redazione di Hardware Upg]

Link alla notizia: https://www.hwupgrade.it/news/cpu/in...no_142752.html

Intel ha depositato il brevetto EP4579444A1 per i Software Defined Super Cores (SDC), una tecnologia che consente di fondere più core in un unico "Super Core" virtuale per migliorare le prestazioni single-thread. Il progetto promette più efficienza senza frequenze più alte, ma presenta complessità tecniche significative.

Click sul link per visualizzare la notizia.

[boboviz]

Sniff, sniff
Non so perchè ma mi puzza di una combinazione di fuffa+mossa della disperazione

[coschizza]

Originariamente inviato da boboviz

Sniff, sniff
Non so perchè ma mi puzza di una combinazione di fuffa+mossa della disperazione

della serei se lo faceva chiunque altro era una figata, ma è intel quindi...

[boboviz]

Originariamente inviato da coschizza

della serei se lo faceva chiunque altro era una figata, ma è intel quindi...

No, no, era una cagata anche se lo faceva chiunque altro.
Hai una vaga idea di cosa voglia dire, a livello di chiamate di sistema, timing, ecc, affidare al software la gestione di più core "come fossero uno"?

[unnilennium]

Mi pare qualcosa di simile al thread director quando hanno presentato per la prima volta la piattaforma ibrida p-core e-core, sicuramente molto più complesso... Certo è che pure col thread director alcuni software non hanno goduto di buone prestazioni, nonostante gli annunci trionfalistici, e quindi immagino come sarà questa soluzione.... Per quanto buono sarà, ci sarà un prezzo da pagare... Sarà comunque interessante vedere cosa si inventano

[CrapaDiLegno]

Originariamente inviato da boboviz

No, no, era una cagata anche se lo faceva chiunque altro.
Hai una vaga idea di cosa voglia dire, a livello di chiamate di sistema, timing, ecc, affidare al software la gestione di più core "come fossero uno"?

In Intel lo sanno molto bene, sicuramente meglio di te e di me, e sanno anche quali sono i limiti e le sfide per aumentare le prestazioni in futuro.
Non so se ti sei accorto ma negli ultimi anni l'aumento di prestazioni single core avanza di pochi punti percentuali a ogni nuova architettura. Architetture che arrivano una volta ogni due anni. Sempre legato all'aumento di frequenza, aumento di consumi e soprattutto all'allocazione di budget di transistor enormi per qualche sputacchio di prestazioni in più qui o lì.

Quindi o continui a costruire core sempre più mastodontici oppure cerchi una soluzione alternativa. Non è detto che questa sia la soluzione finale ultima possibile, la più conveniente o che proprio funzioni. Ma l'evoluzione tecnologica deve guardare oltre all'aumento del numero di risorse (transisitors, cache, W) dedicate ad un singolo core che è ormai in crescita logaritmica e non più sostenibile.

I core già godono di bus di comunicazione ad alta velocità verso memorie e di interconnessione. Investire su questi aspetti potrebbe portare migliori prestazioni rispetto a dover continuamente raddoppiare cache (la cui latenza dipende dalla loro dimensione ed è quindi una sfida non indifferente anche renderle più veloci e più grandi), aumentare frequenze, aumentare gli stadi delle pipeline, aumentare le capacità dei front-end e della superscalarità e quindi aumentare anche il back-end.

Anche qualche anno fa era impensabile riuscire a far scalare due chip in maniera quasi lineare (pensa allo SLI/Crossfire) e quindi si puntava a fare sistemi monolitici sempre più complessi.
Poi sono arrivati i bus di comunicazione veloci su interposer e AMD ha fatto la sua architettura su chiplet. Questi bus sono evoluti così tanto che ora pure le GPU sono a chiplet (e non è una cosa banale mettere insieme chiplet che richiedono TB/s di banda per non avere colli di bottiglia). Blackwell sono praticamente due chip in SLI.
Abbattuto il problema dell'interconnessione nessuno impedisce di pensare a sistemi con 2,3,4,8 chiplet. Infatti AMD già lo fa. Vero che questi chiplet alla fine sono meno efficienti di un monolitico, ma un monolitico con quelle prestazioni non è possible.
Siamo quindi andati oltre al concetto di monolitico sempre più grande per avere prestazioni migliori.

L'idea di Intel è di scendere in livello ancora più in basso per cercare di aumentare le prestazioni.
La disperazione ce l'avrà chi non avendo pensato ad una soluzione alternativa si troverà a dover progettare nuovi core con miliardi di transistor in più per aumentare l'IPC del 5%.

[Kirov HC]

mi puzza

[Max Power]

Originariamente inviato da coschizza

della serei se lo faceva chiunque altro era una figata, ma è intel quindi...

Ma guardacaso, combinazione, l'ha fatto Intel

[alegallo]

[OT mode on] Quando leggo queste notizie rimpiango i tempi in cui erano "Intel ha presentato una nuova CPU che raddoppia il clock: da 66 a 133 MHz!".
Chissà se li rimpiangono anche i loro ingegneri! [OT mode off]

[paolo.oliva2]

Originariamente inviato da CrapaDiLegno

In Intel lo sanno molto bene, sicuramente meglio di te e di me, e sanno anche quali sono i limiti e le sfide per aumentare le prestazioni in futuro.
Non so se ti sei accorto ma negli ultimi anni l'aumento di prestazioni single core avanza di pochi punti percentuali a ogni nuova architettura. Architetture che arrivano una volta ogni due anni. Sempre legato all'aumento di frequenza, aumento di consumi e soprattutto all'allocazione di budget di transistor enormi per qualche sputacchio di prestazioni in più qui o lì.

Quindi o continui a costruire core sempre più mastodontici oppure cerchi una soluzione alternativa. Non è detto che questa sia la soluzione finale ultima possibile, la più conveniente o che proprio funzioni. Ma l'evoluzione tecnologica deve guardare oltre all'aumento del numero di risorse (transisitors, cache, W) dedicate ad un singolo core che è ormai in crescita logaritmica e non più sostenibile.

I core già godono di bus di comunicazione ad alta velocità verso memorie e di interconnessione. Investire su questi aspetti potrebbe portare migliori prestazioni rispetto a dover continuamente raddoppiare cache (la cui latenza dipende dalla loro dimensione ed è quindi una sfida non indifferente anche renderle più veloci e più grandi), aumentare frequenze, aumentare gli stadi delle pipeline, aumentare le capacità dei front-end e della superscalarità e quindi aumentare anche il back-end.

Anche qualche anno fa era impensabile riuscire a far scalare due chip in maniera quasi lineare (pensa allo SLI/Crossfire) e quindi si puntava a fare sistemi monolitici sempre più complessi.
Poi sono arrivati i bus di comunicazione veloci su interposer e AMD ha fatto la sua architettura su chiplet. Questi bus sono evoluti così tanto che ora pure le GPU sono a chiplet (e non è una cosa banale mettere insieme chiplet che richiedono TB/s di banda per non avere colli di bottiglia). Blackwell sono praticamente due chip in SLI.
Abbattuto il problema dell'interconnessione nessuno impedisce di pensare a sistemi con 2,3,4,8 chiplet. Infatti AMD già lo fa. Vero che questi chiplet alla fine sono meno efficienti di un monolitico, ma un monolitico con quelle prestazioni non è possible.
Siamo quindi andati oltre al concetto di monolitico sempre più grande per avere prestazioni migliori.

L'idea di Intel è di scendere in livello ancora più in basso per cercare di aumentare le prestazioni.
La disperazione ce l'avrà chi non avendo pensato ad una soluzione alternativa si troverà a dover progettare nuovi core con miliardi di transistor in più per aumentare l'IPC del 5%.

Ma... ricordi quando Intel annunciò l'architettura ibrida nel mondo X86?
La annunciò come rivoluzionaria e che sarebbe stata il massimo come efficienza e prestazioni. Dopo X anni, un pozzo di soldi di R&D, il dopo Nova non sarà più ibrido.

Dopo aver annunciato il 18A come processo universale per i player di tutto il mondo (e forse anche dell'universo), si scopre che il 18A, al contrario del numeretto, è più simile al processo N3E TSMC di quanto abbia voluto far credere (e portò Pat in conflitto con il CEO TSMC).

Ancora c'è chi crede alle bufale Intel? Io ho seri dubbi che ad Intel sappiano bene alcune cose... tranne come far fallire una azienda che era un colosso.

Riportiamo i piedi per terra... Intel avrà circa 25 miliardi di perdita nel 2025, è in calo nei volumi di vendita e ancor più negli utili, non ha i soldi per il 14A (o entrano investitori sul progetto, o non si farà, parola del nuovo CEO), lato server, mobile, contratti con gli OEM, è tutto un declino costante. In molti riportano che Nova sarà l'ultima possibilità per non cedere le FAB (valevano 240 miliardi di $ quando erano al top, oggi valgono 100 miliardi (vedi operazione Governo USA)).
L'articolo parla di un brevetto, quindi siamo più sull'idea che un qualcosa di reale e commercializzabile nell'immediato. Non è possibile, ora come ora, saperne la validità... ma, nelle condizioni Intel, la probabilità che sia il solito fumo (e niente arrosto), per non far fuggire gli azionisti (ultimi), è tanta.

[ZeroSievert]

Ho cercato di leggere il brevetto velocemente ma ammetto che probabilmente mi sono sfuggiti molti punti.

Da quello che ho capito questa tecnologia permetterebbe di cambiare dinamicamente le pipeline di un core 'rubandole' da un altro. O no ? In questo caso mi chiedo quanto sia il costo in termini di complessita' dell'unita di scheduling delle istruzioni visto che deve supportare diverse configurazioni.

Oppure e' qualcosa come una specie di 'light threading' dove due cpu possono cooperare con un costo di sincronizzazione molto basso (register level)?

E anche qui non ho capito quanto sia trasparente. Alla fine un processore superscalare parallelizza il flusso di istruzioni implicitamente senza che serva un particolare supporto da parte del compilatore. In questo caso il compilatore dovrebbe riconoscere e taggare porzioni parallele ?
Mi chiedo quanto siano migliorati i compilatori rispetto ad itanium. Da quello che ho sempre saputo la 'forza' dei processori superscalari OoO e' che e' molto difficile predire lo stato a livello microarchitetturale di una CPU a compile time. E questo e', sempre da quello che so, e' uno dei motivi della disfatta dei VLIW come cpu general-purpose.

C'e' qualche appassionato/esperto di architetture che ci ha capito qualcosa e lo puo' spiegare in maniera umana?

[ZeroSievert]

Originariamente inviato da boboviz

No, no, era una cagata anche se lo faceva chiunque altro.
Hai una vaga idea di cosa voglia dire, a livello di chiamate di sistema, timing, ecc, affidare al software la gestione di più core "come fossero uno"?

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.

[CrapaDiLegno]

Originariamente inviato da paolo.oliva2

Ma... ricordi quando Intel annunciò l'architettura ibrida nel mondo X86?
La annunciò come rivoluzionaria e che sarebbe stata il massimo come efficienza e prestazioni. Dopo X anni, un pozzo di soldi di R&D, il dopo Nova non sarà più ibrido.

Dopo aver annunciato il 18A come processo universale per i player di tutto il mondo (e forse anche dell'universo), si scopre che il 18A, al contrario del numeretto, è più simile al processo N3E TSMC di quanto abbia voluto far credere (e portò Pat in conflitto con il CEO TSMC).

Ancora c'è chi crede alle bufale Intel? Io ho seri dubbi che ad Intel sappiano bene alcune cose... tranne come far fallire una azienda che era un colosso.

Riportiamo i piedi per terra... Intel avrà circa 25 miliardi di perdita nel 2025, è in calo nei volumi di vendita e ancor più negli utili, non ha i soldi per il 14A (o entrano investitori sul progetto, o non si farà, parola del nuovo CEO), lato server, mobile, contratti con gli OEM, è tutto un declino costante. In molti riportano che Nova sarà l'ultima possibilità per non cedere le FAB (valevano 240 miliardi di $ quando erano al top, oggi valgono 100 miliardi (vedi operazione Governo USA)).
L'articolo parla di un brevetto, quindi siamo più sull'idea che un qualcosa di reale e commercializzabile nell'immediato. Non è possibile, ora come ora, saperne la validità... ma, nelle condizioni Intel, la probabilità che sia il solito fumo (e niente arrosto), per non far fuggire gli azionisti (ultimi), è tanta.

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.

Originariamente inviato da ZeroSievert

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 potrebbero farlo visto che questo introduce un 'vincolo' per il riordino delle istruzioni a run-time.

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.

[ZeroSievert]

Originariamente inviato da CrapaDiLegno

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?

Originariamente inviato da articolo

. Tuttavia, l'implementazione non è priva di complessità: la suddivisione e la riallocazione delle istruzioni richiedono sincronizzazione estremamente rapida e il supporto di compilatori e sistemi operativi, con sfide simili a quelle che in passato hanno frenato architetture sperimentali come Itanium.

[Ripper89]

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.

[CrapaDiLegno]

Originariamente inviato da ZeroSievert

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?

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.

Originariamente inviato da Ripper89

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.

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.

[Ripper89]

Originariamente inviato da CrapaDiLegno

L'approccio di AMD era diverso.
AMD aveva un solo front-end per core.

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.

[ZeroSievert]

Originariamente inviato da CrapaDiLegno

...

Grazie delle informazioni

[CrapaDiLegno]

Originariamente inviato da Ripper89

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.

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.

[Ripper89]

Originariamente inviato da CrapaDiLegno

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.

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

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.