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

[CrapaDiLegno]

Originariamente inviato da Ripper89

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.

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.

[boboviz]

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.

Restano solo da convincere gli sviluppatori dei software.
Ci sono ancora centinaia di programmi che sfruttano un solo core cpu, figurarsi riscriverli da zero per fargli "vedere" il super-core.

[boboviz]

Intanto Intel si sta muovendo benissimo...

https://www.hwupgrade.it/news/cpu/intel-forse-ci-riprova-arrow-lake-refresh-emerge-su-geekbench-ma-ha-davvero-senso_142872.html

[ZeroSievert]

Originariamente inviato da boboviz

Restano solo da convincere gli sviluppatori dei software.
Ci sono ancora centinaia di programmi che sfruttano un solo core cpu, figurarsi riscriverli da zero per fargli "vedere" il super-core.

Il problema del multithreading é che la sincronizzazione é piuttosto costosa e poco deterministica. Ergo ne vale la pena solo per carichi paralleli che eseguono molto lavoro tra una sincronizzazione e l'altra.

In questa soluzione invece la sincronizzazione sembra molto meno costosa. Ergo ha la potenzialità di essere adottata da un numero maggiore di programmi/algoritmi.

Comunque, se fosse necessario sfruttare nuove istruzioni per i super core, la fortuna della tecnologia verrebbe fatta dalla bontà dei compilatori. Alla peggio chi sviluppa software dovrà ricompilare i programmi per utilizzarla. Ma se desse veramente un forte incremento di IPC, non credo che i produttori software storcerebbero il naso all'idea.

[paolo.oliva2]

Originariamente inviato da CrapaDiLegno

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.

Quindi per te è l'ibrido che garantirebbe maggiore ST

Che il dopo Nova non sia più ibrida è una tua invenzione.

Non lo dico io... lo dice la stessa Intel per il dopo Nova, in quanto l'ibrido è troppo esoso in R&D e vantaggi zero.
A parte che Bartlett uscirà a breve e guarda a caso non è ibrido, 12 core P e sostituirà i caxxuti X24 ibridi...

Se non sbaglio lo avevi già detto di Nova. Ora è diventato il dopo Nova.
Tutto il resto sono vaneggiamenti giusto per gettare merda così.

Io non ho mai detto nulla nè di Nova e nè di Arrow.

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".

Guarda che il 1° Ryzen era 2 CCX ma monolitico = 1 unico die. Ma sai di cosa stai parlando?

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.

Praticamente pare la pubblicità Pat sull'ibrido

Spiegami questo:

Ibrido = maggiore efficienza = maggiore prestazione a parità di consumo.
N3B = +15% più efficiente dell'N4P

Quindi mi pare ovvio che sommando la maggiore efficienza dell'architettura ibrida al silicio N3B più efficiente dell'N4P, dovrebbe risultare Arrow più efficiente di8 Zen5 di un +20% almeno... invece un Arrow 285K è meno efficiente di un 9950X, fa conto che a CB23 con 350W fa lo stesso risultato del mio 9950X a 260W... di chi sarebbe la colpa? del corriere?

Io farei 2 conti prima di parlare ancora.

Originariamente inviato da boboviz

Intanto Intel si sta muovendo benissimo...

https://www.hwupgrade.it/news/cpu/in...so_142872.html

Intel produce wafer a 3nm da TSMC nella formula Take and Pay, ovvero fai l'ordine per un volume X e paghi quel volume, che tu produca o meno. Tra OEM e mercato libero, quanti Arrow sono stati venduti rispetto al volume concordato? Il refresh serve a produrre nuovi wafer di Arrow sull'N3B, perchè diversamente Intel dovrebbe pagare i wafer che non ha prodotto.

[Ripper89]

Originariamente inviato da CrapaDiLegno

Non so cosa tu intenda per "inverso di SMT di Intel".

E' semplice, per ogni 2 cores fisici avere 1 logico.
Ossia l'esatto contrario dell'SMT.

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.

Come mostrato nel precedente threads il numero di transistors è totalmente in linea con i Phenom II in realzione al numero di cores, quindi non c'è stato alcun risparmio in tal senso.

E infatti come architettura andava bene se gli si davano in pasto 8 thread

Faceva pena lo stesso, anche dandogli in pasto 8 threads era comunque inferiore agli i7 mainstream da 4 cores all'epoca.

[paolo.oliva2]

BD era l'unica possibilità con le risorse economiche di AMD allora.
C'è una grande differenza tra un discorso SMT e il BD d'allora, e lo si vede stracaricandolo.
L'SMT, per concetto, sfrutta i tempi vuoti delle ALU su un programma, arrivando al 100% di utilizzo.
BD riusciva a gestire fino ad un numero di TH 3X rispetto al nominale.
Ho avuto un FX8350 che mi ha dato tantissime soddisfazioni (il mio utilizzo è l'MT), pure in OC, sfiorando i 5,3GHz e un utilizzo @5GHz RS/DU.
In MT era superiore ai 4 core SMT di Intel, nonostante prodotto sul 32nm SOI vs Intel che disponeva di 32nm HKMG LK prima, poi 22nm ed infine 14nm.
Il problema era l'IPC basso, ma BD era stato progettato sulla convinzione che il 32nm SOI arrivasse a 6GHz "facili facili", ma si fermò a 5GHz a 200W, lo stesso tipo di errore dei PIV progettati per frequenze di 10GHz.

[Kirov HC]

quindi qual è il verdetto?