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

[Redazione di Hardware Upg]

Link alla notizia: https://www.hwupgrade.it/news/cpu/av...io_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.

[CrapaDiLegno]

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.

[frankie]

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.

[StylezZz`]

Originariamente inviato da Redazione di Hardware Upgrade

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

Allora sono felice di avere Rocket Lake

[coschizza]

Originariamente inviato da CrapaDiLegno

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

[frankie]

ma occupa spazio

[coschizza]

Originariamente inviato da frankie

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

[demonsmaycry84]

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.

[Cfranco]

Originariamente inviato da frankie

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 ?

Originariamente inviato da frankie

Che si stia andando verso una semplificazione? Forse.

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

[CrapaDiLegno]

Originariamente inviato da coschizza

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.

Originariamente inviato da coschizza

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.

Originariamente inviato da Cfranco

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.

[coschizza]

Originariamente inviato da CrapaDiLegno

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

[CrapaDiLegno]

Originariamente inviato da coschizza

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.

[coschizza]

Originariamente inviato da CrapaDiLegno

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

[Gringo [ITF]]

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.

[CrapaDiLegno]

Originariamente inviato da coschizza

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

[CrapaDiLegno]

Originariamente inviato da Gringo [ITF]

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.

[Gringo [ITF]]

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

[CrapaDiLegno]

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

[LMCH]

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

[cdimauro]

Originariamente inviato da Manolo De Agostini

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.

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.

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

Originariamente inviato da CrapaDiLegno

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.

Originariamente inviato da frankie

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.

Originariamente inviato da coschizza

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.

Originariamente inviato da CrapaDiLegno

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

Originariamente inviato da CrapaDiLegno

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.

Originariamente inviato da CrapaDiLegno

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.

Originariamente inviato da CrapaDiLegno

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.

Originariamente inviato da Gringo [ITF]

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.

Originariamente inviato da CrapaDiLegno

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.

Originariamente inviato da LMCH

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.