AVX-512 sulle CPU Alder Lake, il matrimonio è finito: i nuovi BIOS sanciscono il divorzio

Tutte le unità quali? Lo sai che un layer di alimentazione indipendente ha costi economici e di ingegnerizzazione degli spazi notevoli?
Inoltre "attivare" una unità con una alimentazione separata significa latenza infinita (o credi che puoi togliere e mettere corrente nei circuiti con intervalli di nanosecondi?)
Quindi tutte le unità è una gran ca**ata.
Infatti un 12900K non consuma come un 12400 in idle (dove le unità non usate sarebbero non alimentate secondo te).
Così come una GPU a cui "tagli" le unità difettose non consuma proporzionalmente meno rispetto ad una GPU in cui le unità proprio non sono montate.

Intel storicamente aveva un PP di vantaggio con rese elevatissime sugli altri e sfornava CPU una dietro l'altra, e quindi qualche mm^2 in più di silicio non era un problema se voleva dire tempi di sviluppo ridotti. Ora con il fatto che ha un PP pessimo che consuma con rese ridotte, il problema si presenta esattamente come lo si presentava agli altri prima.
Vediamo se sui RaptorLake ci saranno le unità AVX-512. Di sicuro non ci saranno su MeteorLake che sarà una rivisitazione completa di tutta l'architettura su nuovo PP.
Non avrebbe alcun senso lasciarle per disabilitarle dopo. I consumi statici ci sono e resterebbero.

perche ha un PP pessimo? la cpu 12400 consuma come un 5600x e va uguale o piu veloce quindi direi che i 7nm intel sono come dice il nome simili ai 7nm tsmc, i numeri non mentono

Attenderemo i BIOS MOD, come fù per attivare il supporto per il BOOT da PCI-E sui chipset X79 per gli SSD MVE, avere un hardware che supporta alcune caratteristiche e castrarlo e un peccato, ci stà un gruppo che addirittura fa funzionare processori su mobo con chipset che NON li supportano, e ci stanno già lavorando, e io amo gli emulatori, emulare il processore CELL necessita le AVX-512 per l'emulazione delle SPE ad una velocità devente.

Certo, se funzionano a frequenza bassa, ma appena alzi la testa.. booom.
E non è che serva molto per aumentare i consumi.
Questi 10nm di Intel non sono ancora come i 7nm di TSMC. Certo sono meglio degli ormai stra abusati e vetusti 14nm, ma non sono allo stesso livello.
Finché Intel non passa ad usare l'EUV anche lei non c'è modo di raggiungere la qualità del PP di TSMC. Probabilmente il pareggio/sorpasso lo si avrà con Intel4 (o i 7nm Intel come si vuole chiamarli).

Non credo neanche che Intel faccia i test per vedere se le unità AVX-512 su ADL funzionino come dovrebbero. Per cui rischi alla grande ad usare quelle unità, sia in stabilità che nella correttezza dei risultati.

Pat Gelsinger, stà semplicemente facendo quello che "L'amministrazione" precedente non ha fatto, quindi...

1) Marketing Continuo
2) Non farsi sfuggire le teste (in questo caso riprendersele)
3) Far uscire l'innovazione e non tenerla nei cassetti

A Pat Gelsinger Intel deve fare un monumento pari a quello che noi Italiani dovremmo fare ad ILIAD quando è arrivata in ITALIA.... :3

Un poca di COMPETIZIONE vera serve, vedi che peperone queste mosse ha dato a AMD che ha anticipato di 18 mesi tutto... :3

POca innovazione Intel prima di Pat?
E certo, facile innovare quando hai PP nuovi.
Prova a fare qualcosa quando gli enormi investimenti nel nuovo PP non danno i propri frutti.
Con i 14nm Intel ha fatto i miracoli, altro che "non ha fatto".

La mia impressione é che AVX-512 sia stato un passo falso per Intel, avessero implementato un estensione vettoriale come SVE/SVE2 di ARM e le estensioni "V" di Risc-V (che permettono di allargare e restringere le ALU vettoriali a piacere tra un core e l'altro, mantenendo piena compatibilità non si sarebbero ritrovati in questa situazione grottesca in cui le AVX-512 sono troppo ingombranti in certi contesti ed ora é stato introdotto un nuovo set di registri per le AMX (e nuovamente vincolando il tutto a registri di dimensione prefissata nell'estensione stessa).
Intel può parlare fin che vuole delle sue librerie che supportano automaticamente le estensioni disponibili, ma c'é una notevole differenza rispetto a codice generato da un compilatore che sfrutta direttamente le estensioni disponibili senza continue chiamate e ritorni da subroutine (e no, la compilazione JIT non é una soluzione altrettanto efficace).

Non funziona così, Manolo. Gli E-Core devono essere appositamente disabilitati, per poter poi abilitare le AVX-512 e poterle usare.

Bisognerà convincere ROBHANAMICI ad abilitare le AVX-512 e provare RPCS3, ma la vedo dura.

Questo, unito a quest'altro:

e al fatto che Intel dovrebbe tornare nel segmento HEDT con una soluzione basata su Alder Lake, per l'appunto, è molto probabilmente la vera ragione per cui Intel abbia deciso adesso di rimuovere completamente il supporto alle AVX-512 per i processori desktop, nonostante sia passato tutto questo tempo e abbia rilasciano più di 30 anni versioni del microcodice.

Fortunatamente c'è un'altra possibilità: Patching older ucode to restore AVX512.

per chi volesse continuare a godere dei benefici di questo set d'istruzioni.

No, Intel progetta un solo core per tutte le sue soluzioni, agendo poi col laser o a livello di microcodice (come in questo caso) per "modulare" i core in base allo specifico segmento di mercato.

No, come ti è stato già detto.

Poi l'HyperThreading occupa poco silicio.

Se vuoi sfruttare per bene le AVX-512, come Intel fa (e ha migliorato proprio con Alder Lake: fino al doppio rispetto a Rocket Lake in scenari con l'uso di dati in virgola mobile), devi necessariamente occupare più spazio per:
- la dimensione effettiva dei registri;
- la dimensione effettiva delle porte di esecuzione per quelle in grado di accogliere istruzioni AVX-512.

AVX-512 richiede parecchio spazio. Anche questo è il motivo per cui i P-Core sono così grossi rispetto agli E-Core.

Esattamente. Tanto il core è sempre lo stesso, come dicevo prima.

Non c'è soltanto questa soluzione. Con le AVX-512 è possibile spegnere le single ALU "per lane".

Mettiamo che, ad esempio, stai manipolando dati in virgola mobile a doppia precisione. In un registro a 512 bit di AVX-512 ce ne possono stare 8. Quindi hai 8 lane, che controlli tramite i registri di maschera e il relativo meccanismo di predicazione, dove un bit del registro maschera controlla se l'operazione dev'essere applicata o meno a quella lane. Ebbene, durante le operazioni, se una lane non è attiva l'ALU può essere spenta, visto che per quel dato non serve effettuare l'operazione (in questo caso o viene mantenuto lo stesso valore, oppure viene azzerato).

E' con questi "trucchetti" che si riesce a far scendere un po' i consumi di unità energivore come queste.

Ma similmente si fa con le AVX: quando non vengono usati 128 bit alti dei registri o ALU a 256 bit, queste parti vengono spente.

E perderesti perché, come dicevo prima, Intel realizza un solo core che poi utilizza per tutti i mercati in cui opera, disabilitando ad hoc certe funzionalità.

I vantaggi ci sono anche in ambito consumer. Alcuni esempi li trovi nell'articolo.

Anche con le AVX le frequenze scendono.

L'importante, in entrambi i casi, è il risultato finale: che le prestazioni migliorino.

Il pensiero c'è ovviamente, ma tale rimane.

Il motivo è proprio quello che immagini: costa parecchio realizzare dei core appositi.

Oggi soltanto per realizzare un processore servono gruppi di lavori di 500-1000 ingegneri, impiegati per 2-3 anni (a seconda che si tratti di aggiornamenti di una microarchitettura, o di una nuova architettura). A cui si aggiungono altri 2-3 di testing da parte di altri ingegneri, prima di arrivare in commercio. In tutto ciò ci sono poi altri impiegati che si occupano di vari altri aspetti (project management, QA, ecc.).

Non è pensabile, quindi, di fare lo stesso per ogni nuovo core.

E' molto più economico, nonché comodo, lavorare a un solo core, e poi disabilitarne alcune parti alla bisogna.

Il resto lo farà l'economia di scala e l'uso di processi produttivi sempre più avanzati (che consentono di ridurre lo spazio occupato dalle parti non usate).

Transistor ne vengono usati pochi per aggiungere l'HT/SMT nei processori. Non è certamente questo il problema.

L'uso della banda dipende dal carico di lavoro in un preciso momento. Comunque ci sono anche politiche di allocazione / prioritizzazione dell'uso delle risorse.

Ciò che conta alla fine è sempre la stessa cosa: il risultato. L'HT/SMT offre chiaramente un vantaggio in core di grosse dimensioni, dove ci sono un sacco di risorse nonché unità di esecuzione. I test parlano chiaro.

Hai notizie in merito?

Vedi sopra. 12900K consuma di più in idle anche perché ha più risorse, e non mi riferisco ai soli core.

12900K è esagerato perché Intel ha voluto strafare, è chiaro, ma non serve scendere troppo in frequenza per ottenere dei buoni consumi con Alder Lake.

Igor's Lab ha fatto dei test in merito.

Tra l'altro pure il 12900K si è mostrato efficiente in diversi scenari.

C'è da dire che il processo di TSMC è più low-power. E nonostante quello di Intel sia high-power, si è rivelato abbastanza efficiente.

Lo vedremo meglio con le soluzioni mobile di Intel, quando saranno a confronto con quelle della concorrenza basate su TSMC.

Penso di sì: almeno parzialmente l'EUV dovrebbe essere usato, se non ricordo male.

Sbagli.

This.

Col senno di poi è facile parlare.

Le AVX-512 nascono dalle ceneri di Larrabee, dei successivi progetti Knight *. Quindi parliamo di PARECCHI anni fa.

Quando le ha presentate le sue SVE Arm? E quando il consorzio RISC-V? Hanno avuto tutto il tempo per pensare a soluzioni più scalabili.

Nonostante tutto RISC-V ha tirato fuori un'ISA SIMD estremamente complessa che, come ti ho riportato in un recente commento, sta creando parecchi problemi a chi la vuole implementare anche su sistemi embedded. Tant'è che alcuni produttori di chip parlano di implementarne soltanto un sottoinsieme. Il che significherebbe l'n-esimo (perché mica è la prima estensione che cannino) errore di progettazione di questi accademici che hanno i piedi ben poco piantati per terra e pensano più a soddisfare la loro voglia accademica di soluzioni teoricamente perfette.

Altra cosa, il modello a registri di dimensione fissa ha anche i suoi perché e i suoi vantaggi. Ed è esattamente il motivo per cui non solo ARM con Neon (che NON ha abbandonato), ma anche RISC-V con l'estensione P, hanno adottato estensioni SIMD di questo tipo.

D'altra parte se vedi come funzionano le estensioni vettoriali "length-agnostic" puoi vedere tu stesso che è difficile adattarle a tutte le problematiche relative al massiccio calcolo vettoriale. Soprattutto la soluzione RISC-V è molto limitante, potendo lavorare esclusivamente su un vector length alla volta, e per giunta con un solo tipo di dato pre-impostato prima del loop vettoriale.

Quindi ci starei molto attento a incensare queste soluzioni disprezzando quelle a lunghezza fissa...

Se ti riferisci al dispatching automatico dell'esecuzione in base al tipo di unità SIMD (o, in generale, processore) guarda che stai sbagliando, perché non esiste alcun JIT e il codice sfrutta il classico meccanismo di salto indiretto che va di moda nella programmazione OOP.

Quindi è molto simile alle virtual table, insomma. Ed è abbastanza efficiente.

Si potrebbe fare di meglio in merito (ho delle idee in merito), ma servirebbe un po' di sperimentazione.

Parecchi anni fa ed un vicolo cieco per Intel.
Mi sa che le AVX-512 sono "sopravvissute" ai vari Knight * (Xeon Phi) perché altrimenti un sacco di clienti istituzionali molto importanti (CERN, USA, Cina, ecc.) che avevano puntato su Xeon Phi per i loro supercomputer, avrebbero potuto prendere in considerazione qualcun altro se veniva a mancare il supporto ad AVX-512.
Non é un caso se hanno impiegato anni prima di arrivare sulle cpu desktop.


Le istruzioni vettoriali erano già utilizzate negli anni '70 sui supercomputer Cray, non é che fossero un concetto sconosciuto. Renderle scalabili costava poco rispetto a tutto il resto.


Primo: le estensioni "V" di riscv non esistono nel vuoto, ci sono anche le "P" che ad esempio che coprono le esigenze di quelli a cui serve qualcosa di più compatto.
Secondo: ARM ha limitato le NEON a registri ampi 128 bit e non é andata avanti a colpi di allargamenti dei registri SIMD come ha fatto Intel, perché quello portava ad introdurre vincoli che limitavano l'evoluzione delle implementazioni.
Invece al momento giusto ha introdotto SVE "per la fascia alta" e le estensioni SIMD Helium per i Cortex-M (più adatte alle esigenze in ambito embedded).
Terzo: la vector lenght variabile é comunque più vantaggiosa di quella "fissa", poiché permette di passare da implementazioni semplici a più complesse senza dover manco ricompilare il codice (cosa molto utile se si usano configurazioni big-LITTLE), inoltre le SIMD tipo AVX hanno pure esse un unica lunghezza ed é fissa.


Mi riferisco al fatto che con una libreria che rimappa le chiamate ad una funzione su una di N varianti ottimizzate in base alle estensioni disponibili può ottimizzare ... solo quelle funzioni, non il resto del codice dell'applicazione o del S.O.
Un runtime JIT può far meglio (se supporta la generazione di codice anche per le estensioni che non fanno parte del set "standard" supportato dall'ABI del S.O. utilizzato.
Infine un compilatore "classico" che parte dal codice sorgente può fare ancor meglio.