AVX-512 definitivamente fuori da Alder Lake, Intel elimina il supporto a livello hardware

[Redazione di Hardware Upg]

Link alla notizia: https://www.hwupgrade.it/news/cpu/av...re_105282.html

Intel ha deciso di intervenire fisicamente sui chip Alder Lake per eliminare il supporto AVX-512, dopo i tentativi di disattivarlo tramite microcode e gli stratagemmi dei produttori di motherboard per riattivarlo.

Click sul link per visualizzare la notizia.

[frankie]

Lo sostengo da tempo, intel vuole semplificare i processori x86
Via le cose inutili:
AVX512
Deconding BR
HT, sì, con l'introduzione degli E-Core è proprio quello lo scopo. Perchè HT costa caro in termini "fisici" (transistor)

ARM ha fatto scuola su un architettura più semplice ed efficace

[omerook]

qualcuno aprirà una buona bottiglia di champagne!

https://www.hwupgrade.it/news/cpu/li...nte_90742.html

[jepessen]

Originariamente inviato da omerook

qualcuno aprirà una buona bottiglia di champagne!

https://www.hwupgrade.it/news/cpu/li...nte_90742.html

Perche' ovviamente se le cose non servono a Linus allora fanno cagare e devono essere eliminate dalla faccia della Terra... sta somigliando sempre piu' a Stallman quanto ad estremismo informatico...

[Gringo [ITF]]

Potrebbero semplificare ancora di più, tornando come un tempo...

Processore + Coprocessore AVX512/1024

Gaming con Mobo con un Socket CPU
Gaming + Lavoro Mobo con 2 Socket
Server .... Mobo con multi Socket o con Processore Xeon grande una piastrella
...anche se non vedo l'ora escano Server con Pontevecchio, vorrei vedere all'opera quelle piastrelline potenti come 2 schede nVidia RTX4090 TI in nVlink.

[omerook]

Originariamente inviato da jepessen

Perche' ovviamente se le cose non servono a Linus allora fanno cagare e devono essere eliminate dalla faccia della Terra... sta somigliando sempre piu' a Stallman quanto ad estremismo informatico...

ma io ho capito che riconosce il vantaggio delle avx512 nelle cpu specializzate, mentre pensa che siano delle zavorre nelle cpu generiche.

[coschizza]

Originariamente inviato da frankie

Lo sostengo da tempo, intel vuole semplificare i processori x86
Via le cose inutili:
AVX512
Deconding BR
HT, sì, con l'introduzione degli E-Core è proprio quello lo scopo. Perchè HT costa caro in termini "fisici" (transistor)

ARM ha fatto scuola su un architettura più semplice ed efficace

L HT costa pochissimo in termini "fisici" (transistor) infatti è la base di qualsiasi core ad alte prestazioni anche fuori dal modo x86

[s12a]

Eliminare l'HT sopperendo la mancanza con un numero maggiore di E-core e magari altre ottimizzazioni potrebbe comunque risolvere diversi problemi di vulnerabilità (speculative execution, ecc) degli attuali processori.

[CrapaDiLegno]

Originariamente inviato da coschizza

L HT costa pochissimo in termini "fisici" (transistor) infatti è la base di qualsiasi core ad alte prestazioni anche fuori dal modo x86

Cosa assolutamente falsa.
L'HT costa un sacco in termini di transistor nei processori moderni. Non siamo più all'inizio degli anni 2000 quando l'IPC era robetta.
Il numero di vie di esecuzione dei core, l'OoO migliorato ed ampliato in spazialità, il branch prediction, le cache aumentate, permette di mantenere molto alta l'occupazione della CPU con un singolo thread. Migliore è l'IPC di un core, meno è il vantaggio apportato dall'SMT.
Tanto che è meglio fare 2 core separati che uno che gestisce 2 thread. Meno transistor, più prestazioni. ARM ha insegnato e insegna ancora sotto questo punto di vista, e Intel ha seguito la linea. AMD farà lo stesso, l'ha già annunciato.

I processori che ancora usano efficacemente l'SMT hanno scopi differenti rispetto al desktop e sono molto più limitati dall'I/O, cosa che favorisce l'uso di più thread condivisi su un solo core che è decisamente più complesso di un x86 (e tremendamente più complesso di un X1), quindi dove l'aumento dei transistor per gestire l'SMT è minore.

[coschizza]

Originariamente inviato da CrapaDiLegno

Cosa assolutamente falsa.
L'HT costa un sacco in termini di transistor nei processori moderni. Non siamo più all'inizio degli anni 2000 quando l'IPC era robetta.
Il numero di vie di esecuzione dei core, l'OoO migliorato ed ampliato in spazialità, il branch prediction, le cache aumentate, permette di mantenere molto alta l'occupazione della CPU con un singolo thread. Migliore è l'IPC di un core, meno è il vantaggio apportato dall'SMT.
Tanto che è meglio fare 2 core separati che uno che gestisce 2 thread. Meno transistor, più prestazioni. ARM ha insegnato e insegna ancora sotto questo punto di vista, e Intel ha seguito la linea. ARM farà lo stesso, l'ha già annunciato.

I processori che ancora usano efficacemente l'SMT hanno scopi differenti rispetto al desktop e sono molto più limitati dall'I/O, cosa che favorisce l'uso di più thread condivisi su un solo core che è decisamente più complesso di un x86 (e tremendamente più complesso di un X1), quindi dove l'aumento dei transistor per gestire l'SMT è minore.

eppure lo dice intel in persona non io

[CrapaDiLegno]

Originariamente inviato da Gringo [ITF]

Potrebbero semplificare ancora di più, tornando come un tempo...

Processore + Coprocessore AVX512/1024

Gaming con Mobo con un Socket CPU
Gaming + Lavoro Mobo con 2 Socket
Server .... Mobo con multi Socket o con Processore Xeon grande una piastrella
...anche se non vedo l'ora escano Server con Pontevecchio, vorrei vedere all'opera quelle piastrelline potenti come 2 schede nVidia RTX4090 TI in nVlink.

Un coprocessore su un socket separato sarebbe un suicidio in termini di latenze e quindi di prestazioni finali. Al massimo su un chiplet posto su un bus veloce e a bassissima latenza.
La verità è che questo tipo di istruzioni servono a ben poco in campo consumer e chi le usa sta facendo un lavoro per cui potrebbe benissimo permettersi uno Xeon con tali capacità.

Non dimentichiamo che se si vuole veramente fare elaborazione sfruttando le capacità delle istruzioni AVX-512 serve anche una gran quantità di banda, cosa che le CPU consumer non offrono. Se invece vuole accelerare un bench o una singola operazione che viene svolta una volta al minuto, la mancanza di tale supporto è meglio compensata da un risparmio di transistor poi impiegabili per accelerare il codice "normale".

[CrapaDiLegno]

Originariamente inviato da coschizza

eppure lo dice intel in persona non io

Ma dove?
Nella documentazione di 20 anni fa dove asseriva che serviva solo il 5% dei transistor per avere il supporto di 2 thread?

P.S: quindi, dopo aver risposto dopo appena 3 minuti al mio primo post con tanta sicurezza e solennità, dopo 2 ore ancora non hai trovato un link in cui Intel dice che l'HT costa poco in termini di transistor?
E dove magari dice, costa poco ma lo stesso noi abbiamo fatto una architettura ibrida, così, tanto per complicarci la vita?

P.P.S: niente, silenzio di tomba. L'hai sparata come fai spesso.

[calabar]

Originariamente inviato da CrapaDiLegno;

Nella documentazione di 20 anni fa dove asseriva che serviva solo il 5% dei transistor per avere il supporto di 2 thread?

L'argomenti in effetti interessa anche a me.

Del resto anche AMD, quando ha tirato fuori Zen, ha scelto la strada dell'SMT, forse più per non staccarsi troppo dal modo di funzionare dei processori Intel che per altro, ma questo da l'idea che la tecnologia in tempi recenti non fosse comunque considerata superata.

Puoi riportare qualche fonte autorevole che indichi un cambiamento evidente da allora o meglio ancora quantifichi l'impatto che ha SMT nelle moderne architetture?

[shodan]

Originariamente inviato da CrapaDiLegno

Ma dove?
Nella documentazione di 20 anni fa dove asseriva che serviva solo il 5% dei transistor per avere il supporto di 2 thread?

Ciao,
allo stato attuale, Hyperthreading (o SMT) occupa *meno* del 5% del die.

Per capirci, questa era l'allocazione dei transitor ai tempi del P4:


Il 5% di overhead era calcolato su un processore single core senza cache L3 né northbridge o switch PCIe integrato. Come puoi vedere dall'immagine, la logica "pura" della CPU occupava i 2/3 della superficie. Se guardi un die shot di Alder Lake, noterai che la CPU "vera e propria" occupa una parte molto più limitata (a occhio un 1/5) e quindi l'overhead dell'SMT, in termini di die space, è molto più basso.

Certo, nel tempo alcune strutture necessarie all'SMT che prima erano condivise sono state replicate, ma si parla davvero di poca roba (in termini numerici), per lo più focalizzate sul frontend. In linea generale, più complessa è la CPU, minore è l'overhead dell'SMT. Purtroppo le analisi in questo senso sono piuttosto vecchiotte, ma puoi trovare delle informazioni interessanti qui: https://research.ac.upc.edu/pact01/papers/s7p2.pdf, dove puoi vedere che per un singolo processore "semplice" l'overhead può arrivare anche al 25% sulla sola CPU+L1, mentre il valore scende molto mano a mano che vengono simulati processori più complessi (sempre senza L2/L3/nb/ecc).

Il vero problema dell'SMT è che per dare buoni risultati deve essere accoppiato a un backend all'altezza, cosa che impiega *tanti* transistor e occupa molto spazio. Dove questo è stato fatto i risultati sono di tutto rispetto. Prendi Power8: l'SMT4 forniva un throughput quasi doppio rispetto al "noSMT", mentre l'SMT8 dava "solo" un 10-20% di throughput in più.

I processori con CPU eterogenee (es: E-cores) possono fornire prestazioni aggregate anche migliori di quelle ottenibili con HT/SMT, ma gestire tali CPU in ambito enterprise/cloud è piuttosto scomodo (es: immagina di migrare una VM che gira su un P-core su un E-core). Per questo in tali ambiti si è scelto di usare cores omogenei "potenziati" da SMT più o meno spinto, così da recuperare parte del throughput.

A livello enterprise, quello che mi aspetto davvero (e che sta accadendo) è la realizzazione di CPU con solo E-cores (o equivalente AMD, vedi Zen4D) per massimizzare il throughput e mantenere comunque una discreta latenza. Per certi versi gli E-cores sono più interessanti dei P-cores: prestazioni non troppo diversa da Skylake con 1/4 dell'area e del consumo.

La questione sicurezza / side channel tra i threads è un altro argomento spinoso, anche se generalmente a essere criticato non è l'SMT per se, ma alcuni effetti secondari visibili sulle CPU Intel di precedente generazione.

Ciao.

[CrapaDiLegno]

La questione che hai scritto è vera e l'ho scritta pure io. Come detto i processori per lavori diversi dal desktop con un supporto extra CPU decisamente più mastodontico godono di più dall'uso del SMT.

Per quanto riguarda l' impatto su processori con grandi cache che vuoi consuderare nella diluizione dei transistor aggiunti per l'HT, devi considerare quanto è il costo di un core separato. Facciamo che la proporzione è 1/5 tra tutti i transistor cache comprese, quanto mi costa aggiungere un core?
Mettiamo che un core senza HT pesa 1/6. È equivalente a un aggiunta del 16%.

Considerando che il contributo dell'HT diminuisce all'aumentare dell'IPC e che la maggior parte dei transistor sono spesi per aumentare quest' ultimo, ne deriva che man mano che migliori il core (spendendo transistor) l'HT peggiora.
Con l'aumento delle vie di esecuzione serve una struttura sempre più complessa per mantenere la funzionalità HT (raddoppio di molte strutture intermedie). Ne deriva quindi che il numero di transistor cresce più del necessario e già non sono pochi.

La soluzione è presto fatta: niente HT per un core più magro. ARM non ha mai sposato la filosofia SMT, e vediamo che se realizzati decentemente (e non solo per smartphone) le prestazioni ci sono senza necessità di SMT.
Cosa che sta insidiando i processori x86 usati in ambienti con codice altamente parallelo.

Non ho altro tempo per descrivere l'evoluzione della situazione per cui non serve inventarsi nulla, se non guardare gli investimenti fatti da Intel come pioniera che sarà seguita da AMD come già annunciato.

È la dimostrazione che l'SMT è giunto al capolinea, superato su desktop e su CPU per lavori altamente parallelizzati dove molto più core piccoli sono sempre meglio di meno core super pompati.

Non mi meraviglierei se i futuri P-core aumentassero l'IPC togliendo l'SMT nel prossimo futuro risparmiando in transistor e quindi liberando spazio per più P-core stessi o più E-core.

[calabar]

Originariamente inviato da CrapaDiLegno;

La questione che hai scritto è vera e l'ho scritta pure io.

Lui in realtà ha detto che la percentuale necessaria di silicio necessaria per implementare l'SMT è inferiore nei processori complessi (ossia le architetture moderne), mentre tu hai alluso il contrario, ossia che la stima del 5% fosse ormai datata e superata (il che a quanto dice lui è si vero, ma nel senso opposto a quanto sostenevi). Al netto delle cache L2 e L3, si intende.

Originariamente inviato da CrapaDiLegno;

Facciamo che la proporzione è 1/5 tra tutti i transistor cache comprese, quanto mi costa aggiungere un core?
Mettiamo che un core senza HT pesa 1/6. È equivalente a un aggiunta del 16%.

In questo caso però stiamo parlando di una percentuale inferiore al 5% per SMT, mentre il tuo "facciamo" parla di 1/5, ossia un ben più alto 20%. Come esempio teorico va bene, ma lo vedo lontano dall'applicazione nei casi attuali.

Questo naturalmente non toglie che quella dei core eterogenei possa essere una soluzione valida, si sta investendo in questo ambito e nei prossimi anni avremo risposte più chiare.
Del resto i core Intel che occupano 1/4 dell'area di un core classico sono un buon inizio, pur con le loro criticità, in particolare un'efficienza sotto le attese per lo meno nelle prime implementazioni (vedremo nel mobile dove le frequenze dovrebbero essere più vicine allo sweet spot) ma soprattutto il supporto disomogeneo alle istruzioni, vedi il caso delle AVX 512 di cui si è parlato di recente.

Originariamente inviato da CrapaDiLegno;

Non mi meraviglierei se i futuri P-core aumentassero l'IPC togliendo l'SMT nel prossimo futuro risparmiando in transistor e quindi liberando spazio per più P-core stessi o più E-core.

Io me ne meraviglierei invece, non è un caso che i P-Core intel mantengano l'SMT, senza non sarebbero sfruttati a dovere.
Del resto se l'SMT occupa meno del 5% del silicio del core mentre un e-core aggiuntivo ne occupa il 25%, per rinunciare all'SMT questo dovrebbe dare un apporto alle prestazioni del core inferiore al 20% di un e-core, e mi pare ohe mediamente ad oggi siamo molto sopra questo valore.

Gli e-core possono essere efficaci nel sostituire un grosso core con SMT, non l'SMT in un grosso core perchè il grosso del silicio occupato è del grosso core, non dell'SMT.
Ma al grosso core è difficile rinunciare, per le prestazioni di picco e single core. Farlo significherebbe probabilmente mettersi in una situazione simile a quella di AMD con Bulldozer, dove a mancare erano proprio i core ad alte prestazioni e ad abbondare il numero di core.

Originariamente inviato da CrapaDiLegno;

Considerando che il contributo dell'HT diminuisce all'aumentare dell'IPC

Questo è sostanzialmente inesatto.
L'SMT risulta meno efficace tanto più si riesce a sfruttare le risorse del core (dato che le tecnologie di SMT servono proprio a sfruttare le parti dei core non utilizzate dal thread principale che ci gira).
L'IPC è misura delle capacità del core, non della sua efficacia (di quanto si riesco cioè, nella pratica, a sfruttarne le risorse). Paradossalmente potrei aumentare l'IPC aggiungendo pipeline di calcolo nel core che però verrebbero sfruttate solo in piccola parte o saltuariamente, e in questo caso l'SMT potrebbe risultare più efficace.

[shodan]

Per quanto riguarda l' impatto su processori con grandi cache che vuoi consuderare nella diluizione dei transistor aggiunti per l'HT, devi considerare quanto è il costo di un core separato. Facciamo che la proporzione è 1/5 tra tutti i transistor cache comprese, quanto mi costa aggiungere un core?
Mettiamo che un core senza HT pesa 1/6. È equivalente a un aggiunta del 16%.

Ciao, il punto è che le percentuali che riporti sono spropositate per un core moderno. Se l'HT prendeva il 5% di area su un P4 senza L3/NB/PCIE, oggi impiega probabilmente meno del 2%. La duplicazione delle risorse avviene solamente per poche risorse del frontend, che a livello di area/transistor occupano (relativamente) pochissimo. Considera che un approccio CMP (che duplica tutto l'integer cluster e impone un frontend importante) l'incremento di area è il 12% per modulo e solo il 5% a livello di intero chip:


Va da sé che SMT2 (o HT), non duplicando nulla nel backend, impone overhead molto minori.

Considerando che il contributo dell'HT diminuisce all'aumentare dell'IPC e che la maggior parte dei transistor sono spesi per aumentare quest' ultimo, ne deriva che man mano che migliori il core (spendendo transistor) l'HT peggiora.
Con l'aumento delle vie di esecuzione serve una struttura sempre più complessa per mantenere la funzionalità HT (raddoppio di molte strutture intermedie). Ne deriva quindi che il numero di transistor cresce più del necessario e già non sono pochi.

Non è l'aumento delle vie di esecuzione che limita l'uso dell'SMT, anzi. Guarda i Power7/8/9: i backend sono mastodontici, eppure beneficiano eccome dell'SMT. Il vantaggio dell'SMT diminuisce mano a mano che l'engine OoO diventa più complesso e riesce a estrarre un maggiore ILP su una finestra di istruzioni in-flight più ampia. Ma questo ha dei limiti, e un secondo thread di esecuzione è molto utile proprio su quei processori che hanno backend importanti. Se vogliamo il limite dell'HT di intel è proprio il contrario: fino a Skylake il backend era troppo stretto, mentre la logica OoO era molto evoluta. In altre parole, c'era poco da rosicare sul fondo del barile

La soluzione è presto fatta: niente HT per un core più magro. ARM non ha mai sposato la filosofia SMT, e vediamo che se realizzati decentemente (e non solo per smartphone) le prestazioni ci sono senza necessità di SMT.

In realtà ARM ha lanciano un core basato su A65AE che supporta proprio l'SMT: https://www.anandtech.com/show/13727...t-smt-cpu-core
I Cortex A510 supportano invece la modalità merged-cores che richiamano in modo abbastanza evidente (suppor con importanti differenze) l'approccio CMP di AMD: https://www.anandtech.com/show/16693...0-cortexa510/4

È la dimostrazione che l'SMT è giunto al capolinea, superato su desktop e su CPU per lavori altamente parallelizzati dove molto più core piccoli sono sempre meglio di meno core super pompati.

Vero: tanti piccoli cores hanno prestazioni aggregate maggiori di pochi core potenti, ma questo si sa da sempre. La vera novità è che le prestazioni dei "mid-cores" sono diventate sufficienti a non causare problemi di lentezza nel normale uso, dove la latenza gioca ancora un ruolo importante. Per tanti scenari d'uso, quindi, i "big cores" stanno semplicemente diventando superflui.

Non mi meraviglierei se i futuri P-core aumentassero l'IPC togliendo l'SMT nel prossimo futuro risparmiando in transistor e quindi liberando spazio per più P-core stessi o più E-core.

Anche questo è possibile, ma penso per una diversa motivazione: il progressivo allontanamento delle architetture client da quelle server, con queste ultime che saranno le uniche a ricevere determinate features. Chiaramente poi bisogna attendere e vedere come andranno davvero le cose...

Ciao.