Link alla notizia: https://www.hwupgrade.it/news/cpu/avx-512-sulle-cpu-alder-lake-il-matrimonio-e-finito-i-nuovi-bios-sanciscono-il-divorzio_103748.html

Finora sulle motherboard Z690 e i processori Alder Lake era possibile attivare il set di istruzioni AVX-512, a patto di disabilitare gli E-core. Questa opzione non sarà però più possibile, Intel ha deciso di rimuoverla con un nuovo microcode che sta raggiungendo gli ultimi BIOS.

Click sul link per visualizzare la notizia.

Ho il dubbio che tra le modifiche ai prossimi P-core di RaptorLake ci sarà la rimozione proprio dell'unità AVX-512, mentre Intel ha detto che i core Gracemont rimarranno uguali.
Dovrebbe ridurre le dimensioni del P-core e magari anche un po' i consumi.

Non ricordo la fonte, ma il concetto era questo: I core x86, grazie alle estensioni e soprattutto all HT/SMT sono molto complessi da un punto di vista del silicio, in confronto agli ARM.

Che si stia andando verso una semplificazione? Forse.

In base ad alcuni test, si è rivelato molto utile per accelerare le prestazioni dell'emulatore PS3 RPCS3

Allora sono felice di avere Rocket Lake :O

Ho il dubbio che tra le modifiche ai prossimi P-core di RaptorLake ci sarà la rimozione proprio dell'unità AVX-512, mentre Intel ha detto che i core Gracemont rimarranno uguali.
Dovrebbe ridurre le dimensioni del P-core e magari anche un po' i consumi.

un unita non utilizzata non consuma

ma occupa spazio

ma occupa spazio

le unita avx 512 sono parte delle avx 256 quindi lo spazio occupato e minimo e la cpu viene usata nel mercato server e workstation dove l'unita viene attivata quindi costa di piu eliminarla

speriamo di avere più informazioni tecniche sulla questione...anche se credo come detto sopra più una situazione stile quadro, geforce dove certe cose le metteranno sugli xeon o sulla fascia main quando sarà veramente necessario.
Poi se parte del lavoro delle avx può essere fatto dai tensor core sulla cpu è sicuramente una soluzione custom ma da studiare.

Non ricordo la fonte, ma il concetto era questo: I core x86, grazie alle estensioni e soprattutto all HT/SMT sono molto complessi da un punto di vista del silicio, in confronto agli ARM.
Ancora con questa storia ?
Era vero 40 anni fa, oggi non più
Apple M1 pro ha 33 milioni di transistor e M1 Max 57 milioni

I Ryzen senza GPU stanno sui 6 milioni di transistor per 8 core
Il Threadripper da 64 core si ferma a 40 milioni

Intel non dice il numero dei transistor, ma le stime parlano di 8-10 milioni con la GPU per rocket lake

Qual è la CPU più complicata ?


Che si stia andando verso una semplificazione? Forse.

Al contrario, si va verso una sempre più elevata complicazione

un unita non utilizzata non consuma
Lo credi tu.
Se non hai un layer di alimentazione separato, i transistor di quell'unità consumeranno in leakage eccome.

le unita avx 512 sono parte delle avx 256 quindi lo spazio occupato e minimo e la cpu viene usata nel mercato server e workstation dove l'unita viene attivata quindi costa di piu eliminarla

Anche qui non è mica vero.
Siccome i die per le versioni server non sono gli stessi delle versioni a Intel costerebbe zero eliminare le unità AVX-512.
Io scommetto che con RaptorLake le unità AVX-512 spariranno dai P-core. Sono unità troppo specializzate e dal costo troppo alto per avere un senso nel mercato consumer.
In più portano tutta una serie di problematiche come la riduzione delle frequenze anche per le istruzioni normali quando si attivano.

E comunque anche se fossero gli stessi die tra server e consumer (come per AMD) dipende da quanti mm^2 alla fine sprechi in totale.
Fai 1000 CPU per server e 1.000.000 consumer?
Sprechi 10.000.000 di mm^2 in totale sulle CPU consumer che non hanno utilità? Quanto costano? Quanto costa fare una versione del die apposita?
Non siamo certo noi a dover insegnar loro questo tipo di calcoli, ma se qualcosa non serve, è grande e costa stai pur sicuro che il pensiero se eliminarla o meno se lo pongono.

Ancora con questa storia ?
Era vero 40 anni fa, oggi non più
Apple M1 pro ha 33 milioni di transistor e M1 Max 57 milioni

I Ryzen senza GPU stanno sui 6 milioni di transistor per 8 core
Il Threadripper da 64 core si ferma a 40 milioni

Intel non dice il numero dei transistor, ma le stime parlano di 8-10 milioni con la GPU per rocket lake

Qual è la CPU più complicata ?

Al contrario, si va verso una sempre più elevata complicazione

Sono MILIARDI, non milioni.
Comunque si parla di unità in estensione al core, non parti del core vero e proprio. Posso esserci come non esserci e non cambia come è fatto il core.
La semplificazione, indipendentemente dal numero di transistor, è sul flusso dei dati.
Core SMT/HT richiedono tutta una serie di transistor aggiuntivi per fare operazioni "fuori banda" per aliasing e riordinazione e sostituzione, accessi alla memoria doppi, sfruttamento inferiore delle cache, cosa che un core monothread non incorre. E sono tutti transistor/banda che possono essere usati per incrementare le capacità di calcolo del core invece di cercare di sfruttare i periodi morti che sono sempre meno man mano che si cerca di aumentare l'IPC.

Lo credi tu.
Se non hai un layer di alimentazione separato, i transistor di quell'unità consumeranno in leakage eccome.



tutte le unita di esecuzione sono create con alimentazioni separate per andare in idle all'occorrenza quindi il consumo è pari a 0. Intel storicamente ha sempre detto che costa piu togliere del silicio che lasciarlo li dove sta e inutilizzato.
Una cpu con la igpu disabilitata consuma lo stesso a livello di mmw eppure ci sono miliardi di transistor

tutte le unita di esecuzione sono create con alimentazioni separate per andare in idle all'occorrenza quindi il consumo è pari a 0. Intel storicamente ha sempre detto che costa piu togliere del silicio che lasciarlo li dove sta e inutilizzato.
Una cpu con la igpu disabilitata consuma lo stesso a livello di mmw eppure ci sono miliardi di transistor

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.

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.

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

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

;47699076']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.

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

AVX-512 è "tecnicamente" supportato solo dai P-core Golden Cove e di conseguenza l'uso dell'istruzione disattiva gli E-core (Gracemont).
Non funziona così, Manolo. Gli E-Core devono essere appositamente disabilitati, per poter poi abilitare le AVX-512 e poterle usare.
In base ad alcuni test, si è rivelato molto utile per accelerare le prestazioni dell'emulatore PS3 RPCS3.
Bisognerà convincere ROBHANAMICI ad abilitare le AVX-512 e provare RPCS3, ma la vedo dura. :D
Allo stesso tempo, alcune prove di Igor's Lab hanno rilevato che AVX-512 funziona in modo più efficiente di AVX2.
Questo, unito a quest'altro:
AVX-512 è in grado di accelerare le prestazioni delle CPU per i carichi di lavoro e i modelli di utilizzo come le simulazioni scientifiche, l'analisi finanziaria, l'intelligenza artificiale (AI) e il deep learning e molto 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.
Comunque sia, se avete bisogno delle istruzioni AVX-512 sul vostro sistema Alder Lake non vi resta che dotarvi di una motherboard Z690 e di un BIOS che non è stato aggiornato all'ultima versione del microcode di Intel.
Fortunatamente c'è un'altra possibilità: Patching older ucode to restore AVX512. (https://www.overclock.net/threads/12900k-patching-older-ucode-to-restore-avx512.1796070/)

per chi volesse continuare a godere dei benefici di questo set d'istruzioni. ;)
Ho il dubbio che tra le modifiche ai prossimi P-core di RaptorLake ci sarà la rimozione proprio dell'unità AVX-512, mentre Intel ha detto che i core Gracemont rimarranno uguali.
Dovrebbe ridurre le dimensioni del P-core e magari anche un po' i consumi.
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.
Non ricordo la fonte, ma il concetto era questo: I core x86, grazie alle estensioni e soprattutto all HT/SMT sono molto complessi da un punto di vista del silicio, in confronto agli ARM.

Che si stia andando verso una semplificazione? Forse.
No, come ti è stato già detto.

Poi l'HyperThreading occupa poco silicio.
le unita avx 512 sono parte delle avx 256 quindi lo spazio occupato e minimo
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.
e la cpu viene usata nel mercato server e workstation dove l'unita viene attivata quindi costa di piu eliminarla
Esattamente. Tanto il core è sempre lo stesso, come dicevo prima.
Lo credi tu.
Se non hai un layer di alimentazione separato, i transistor di quell'unità consumeranno in leakage eccome.
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.
Anche qui non è mica vero.
Siccome i die per le versioni server non sono gli stessi delle versioni a Intel costerebbe zero eliminare le unità AVX-512.
Io scommetto che con RaptorLake le unità AVX-512 spariranno dai P-core.
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à.
Sono unità troppo specializzate e dal costo troppo alto per avere un senso nel mercato consumer.
I vantaggi ci sono anche in ambito consumer. Alcuni esempi li trovi nell'articolo.
In più portano tutta una serie di problematiche come la riduzione delle frequenze anche per le istruzioni normali quando si attivano.
Anche con le AVX le frequenze scendono.

L'importante, in entrambi i casi, è il risultato finale: che le prestazioni migliorino.
E comunque anche se fossero gli stessi die tra server e consumer (come per AMD) dipende da quanti mm^2 alla fine sprechi in totale.
Fai 1000 CPU per server e 1.000.000 consumer?
Sprechi 10.000.000 di mm^2 in totale sulle CPU consumer che non hanno utilità? Quanto costano? Quanto costa fare una versione del die apposita?
Non siamo certo noi a dover insegnar loro questo tipo di calcoli, ma se qualcosa non serve, è grande e costa stai pur sicuro che il pensiero se eliminarla o meno se lo pongono.
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).
La semplificazione, indipendentemente dal numero di transistor, è sul flusso dei dati.
Core SMT/HT richiedono tutta una serie di transistor aggiuntivi per fare operazioni "fuori banda" per aliasing e riordinazione e sostituzione, accessi alla memoria doppi, sfruttamento inferiore delle cache, cosa che un core monothread non incorre. E sono tutti transistor/banda che possono essere usati per incrementare le capacità di calcolo del core invece di cercare di sfruttare i periodi morti che sono sempre meno man mano che si cerca di aumentare l'IPC.
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.
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.
Hai notizie in merito?
Non avrebbe alcun senso lasciarle per disabilitarle dopo. I consumi statici ci sono e resterebbero.
Vedi sopra. 12900K consuma di più in idle anche perché ha più risorse, e non mi riferisco ai soli core.
Certo, se funzionano a frequenza bassa, ma appena alzi la testa.. booom.
E non è che serva molto per aumentare i consumi.
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.
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.
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.
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).
Penso di sì: almeno parzialmente l'EUV dovrebbe essere usato, se non ricordo male.
;47699201']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
Sbagli.
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".
This.
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).
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...
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).
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.

Col senno di poi è facile parlare.

Le AVX-512 nascono dalle ceneri di Larrabee, dei successivi progetti Knight *. Quindi parliamo di PARECCHI anni fa.
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.


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


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

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.


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

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.
Il problema principale delle AVX-512 (e, in generale, di unità vettoriali "wide") è che vengono poco usate su "codice desktop", mentre sono di di molto più facili da usare in ambito server/workstation, per non parlare poi di HPC dove l'utilizzo è pressoché immediato.

Pensa a quanto poco vengono ancora usate le AVX su desktop, persino in ambito gaming dov'è più facile sfruttarle, e capisci da solo che la situazione sia alquanto diversa.
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.
Intanto vedi sopra.

Poi ignori come storicamente siano arrivate prima implementazioni SIMD molto semplici e limitate, che col tempo si sono evolute, e nel caso di Intel ciò è stato fatto in maniera retrocompatibile, per riciclare direttamente o facilitare molto il passaggio alla nuova estensione SIMD. Nel caso di Intel la storia riguarda MMX, SSE (con le varie estensioni), AVX, e infine AVX-512.
Ma Intel non è certo stata l'unica a introdurre estensioni SIMD a lunghezza fissa. Tutt'altro. SUN coi suoi SPARC è stata una delle pioniere, ma potrei citarti anche HP coi suoi PA-RISC.

Se fosse stato così facile come credi perché ARM ha presentato le NEON (peraltro parecchi anni dopo le sue estensioni packet/DSP) e non ha, invece, pensato di introdurre subito e soltanto le SVE? Peraltro le SVE hanno richiesto un seguito, le SVE2, perché non erano nemmeno complete.

E RISC-V c'ha impiegato pure una vita per la ratifica (arrivata 2 mesi fa, dopo anni di studi e discussioni), sfornando un mostro alquanto complicato (tante istruzioni, ma soprattutto diversi formati di opcode, e ben 111 pagine di documento solo per questa estensione).

Hanno tutti ignorati i Cray e il loro modello vettoriale? Io non credo proprio.
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.
Ci sono esclusivamente perché UN produttore di processori RISC-V, Andes, ci ha lavorato in parallelo, e siccome la sua soluzione era di gran lunga più semplice del mostro vettoriale che soltanto adesso è stato finalizzato (vedi sopra. Poi i produttori embedded non potevano mica aspettare i comodi degli accademici), alla fine è entrato a far parte dello standard.

Peraltro avrebbero benissimo potuto realizzare una versione ridotta delle attuali estensioni vettoriali, a uso embedded, come hanno fatto in diverse altre parti dell'ISA. Invece hanno realizzato un'estensione SIMD che non solo è a lunghezza fissa, ma alquanto diversa da quella a lunghezza variabile. Non penso sia strano?
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).
E, no, troppo comodo così. Anche ARM avrebbe potuto benissimo introdurre SVE direttamente al posto di NEON, visti i (presunti) vantaggi del primo, e considerato il fatto che i Cray li conoscono tutti. Invece ha deciso di passare prima per NEON...
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),
Vero. Come mai allora ARM le preferito la classica unità SIMD a lunghezza fissa (NEON)?
inoltre le SIMD tipo AVX hanno pure esse un unica lunghezza ed é fissa.
Esatto. E sono molto semplici da implementare, visto che è tutto già noto in partenza.

Questo IMO è il motivo per cui si sono diffuse prima le SIMD a lunghezza 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.
Non vedo il problema. Si ottimizzano gli hot-spot di un'applicazione.
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.
Sulla carta sì. Ma nella realtà è raro che codice JIT superi in prestazioni codice appositamente compilato, specialmente sfruttando code-path diversi a seconda delle estensioni supportate E del tipo di micro-architettura (anche questo è molto importante, e spesso viene ignorato dai compilatori JIT, che usualmente generano codice generico).
Infine un compilatore "classico" che parte dal codice sorgente può fare ancor meglio.
Esatto. Ed è quello che si fa normalmente: si prende un'applicazione e la si compila, sfruttando il più possibile estensioni E (di nuovo) micro-architetture.
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.
Questo m'era sfuggito ieri.

No, Intel testa tutto, per quanto avevo detto prima (un solo core viene usato per tutti gli ambiti).

Per inciso, testa pure roba che non ha mai visto la luce. :fagiano:

Quindi IMO le AVX-512 si possono tranquillamente utilizzare con Alder Lake. ;)

Alder Lake per molteplici motivi risulta essere una famiglia di CPU di transizione ma anche tirata fuori troppo velocemente, con conseguenti incongruenze ed "errori", già mettere il supporto ad un'istruzione in modo parziale e poi decidere di toglierla è tutto dire.
Penso che soltanto le versioni con P-cores siano oggi consigliabili, le altre lasciamole solo a chi piace sperimentare.

iT[o];47700778']Alder Lake per molteplici motivi risulta essere una famiglia di CPU di transizione ma anche tirata fuori troppo velocemente,
Ma assolutamente no. E' un progetto ben ponderato che ha richiesto anni per arrivare in produzione.
con conseguenti incongruenze ed "errori",
Non ci sono né gli uni né gli altri.
già mettere il supporto ad un'istruzione in modo parziale e poi decidere di toglierla è tutto dire.
Decisione "politica" (strategica) di Intel, come già detto.
Penso che soltanto le versioni con P-cores siano oggi consigliabili, le altre lasciamole solo a chi piace sperimentare.
Di nuovo, in totale disaccordo. Il futuro è rappresentato da soluzione ibride come queste. Dove, peraltro, il peso degli E-Core sarà sempre più rilevante. E AMD stessa ha dichiarato che seguirà lo stesso approccio.

Con buona pace di chi non vuol vederlo...

Il problema principale delle AVX-512 (e, in generale, di unità vettoriali "wide") è che vengono poco usate su "codice desktop", mentre sono di di molto più facili da usare in ambito server/workstation, per non parlare poi di HPC dove l'utilizzo è pressoché immediato.

Pensa a quanto poco vengono ancora usate le AVX su desktop, persino in ambito gaming dov'è più facile sfruttarle, e capisci da solo che la situazione sia alquanto diversa.
Le AVX sono "poco usate" perchè il set di istruzioni "garantito" dall'ABI di Windows e Linux non include AVX, quindi se si usano lo si fa con librerie che in base al processore selezionano varianti di una stessa funzone ottimizzate per le varie estensioni "opzionali".


Poi ignori come storicamente siano arrivate prima implementazioni SIMD molto semplici e limitate, che col tempo si sono evolute, e nel caso di Intel ciò è stato fatto in maniera retrocompatibile, per riciclare direttamente o facilitare molto il passaggio alla nuova estensione SIMD. Nel caso di Intel la storia riguarda MMX, SSE (con le varie estensioni), AVX, e infine AVX-512.
Ma Intel non è certo stata l'unica a introdurre estensioni SIMD a lunghezza fissa. Tutt'altro. SUN coi suoi SPARC è stata una delle pioniere, ma potrei citarti anche HP coi suoi PA-RISC.

Se fosse stato così facile come credi perché ARM ha presentato le NEON (peraltro parecchi anni dopo le sue estensioni packet/DSP) e non ha, invece, pensato di introdurre subito e soltanto le SVE? Peraltro le SVE hanno richiesto un seguito, le SVE2, perché non erano nemmeno complete.

E RISC-V c'ha impiegato pure una vita per la ratifica (arrivata 2 mesi fa, dopo anni di studi e discussioni), sfornando un mostro alquanto complicato (tante istruzioni, ma soprattutto diversi formati di opcode, e ben 111 pagine di documento solo per questa estensione).

Hanno tutti ignorati i Cray e il loro modello vettoriale? Io non credo proprio.
Il mio punto é che le estensioni SIMD hanno senso con registri relativamente grandi, ma oltre un certo numero di bit ha piú senso passare ad estensioni vettoriali che mascherino l'effettiva dimensioni delle ALU SIMD effettivamente utilizzate e/o lo scatter-gather verso e da ALU distinte.
ARM non a caso si é fermata a registri a 128bit con le sue SIMD e poi ha aggiunto le SVE per poter supportare implementazioni vettoriali con ALU da 128 a 2048 bit con un unica estensione.
Poi non capisco come mai ti fai tanti problemi su come si sta evolvendo RISC-V, non é un set di istruzioni di una singola architettura, é invece una famiglia di set di istruzioni e di estensioni che si stanno evolvendo a velocità differenti e con dinamiche differenti rispetto a set di istruzioni sotto il controllo di un unica azienda.


Ci sono esclusivamente perché UN produttore di processori RISC-V, Andes, ci ha lavorato in parallelo, e siccome la sua soluzione era di gran lunga più semplice del mostro vettoriale che soltanto adesso è stato finalizzato (vedi sopra. Poi i produttori embedded non potevano mica aspettare i comodi degli accademici), alla fine è entrato a far parte dello standard.
E quale sarebbe il problema? Ora i produttori di cpu per applicazioni embedded hanno le estensioni "P" e per cose molto più pesanti ci sono le "V".


Non vedo il problema. Si ottimizzano gli hot-spot di un'applicazione.
Non ci sono solo gli hot-spot "grossi", ci sono anche quelli in cui serve codice inline ottimizzato sparso un po ovunque nel codice applicativo e li con chiamate a librerie ci fai poco.