Link alla notizia: https://www.hwupgrade.it/news/cpu/linus-torvalds-spera-che-le-istruzioni-avx-512-muoiano-dolorosamente_90742.html

Linus Torvalds, commentando la possibile assenza di supporto alle istruzioni AVX-512 da parte della futura architettura Alder Lake, si è lasciato andare a una profonda critica contro le istruzioni e Intel.

Click sul link per visualizzare la notizia.

Ovviamente Sempre con il dito medio alzato:D

Il problema conoscendo la figura, avrà detto lo stesso per le AVX a 128 e poi per quelle a 256 e dirà lo stesso in futuro per quelle a 1024 XD

E' sempre contro tutto quello che non è farina del suo sacco lol

Le AVX512 sono parecchio utili invece. Prima di tutto sono gestite automaticamente da compilatore durante le ottimizzazioni quando si può fare, e in seconda battuta uno sviluppatore può usarle proficuamente a basso livello quando cerca prestazioni, ad esempio operazioni su vettori di double per calcoli matriciali, quaternioni etc.

Non è che se uno non sa usare le istruzioni o non vuole o semplicemente non ne ha bisogno allora fanno cagare a prescindere. A Tovards il mondo deve veramente molto, ma ha molto spesso il difetti di pensare che se una cosa non serve a lui allora non serve a nessuno e debba essere eliminata, come in questo caso.

Lui stesso dice che se ne frega della virgola mobile, ma il.mo di dei simulatori, delle simulazioni fem, dei CAD e via dicendo ci campano con la parallelizzazione dei double.

ad esempio operazioni su vettori di double per calcoli matriciali, quaternioni etc.

Ovvero casi speciali. Proprio come dice Torvalds.


Non è che se uno non sa usare le istruzioni o non vuole o semplicemente non ne ha bisogno allora fanno cagare a prescindere.


Non ha detto che fanno cagare. Ha detto che Intel dovrebbe sfruttare la sua forza lavoro e i transistor per cose più importanti. Cioè, esistono ben altre priorità.

Che penseresti se MS si concentrasse sul menu start, lasciando non patchate decine di vulnerablità?


Lui stesso dice che se ne frega della virgola mobile, ma il.mo di dei simulatori, delle simulazioni fem, dei CAD e via dicendo ci campano con la parallelizzazione dei double.

Priorità, priorità. Non muore nessuno se le prossime AVX-1024 ( arriveranno, arriveranno ) vengono rimandate di qualche anno.

Il problema di Intel era e rimane la scarsa modularità delle sue offerte. Dovrebbero imparare da ARM e magari cominciare a concedere più IP in licenza.

Se Pippo produce processori per HPC, integrerà allegramente AVX-512. Se Pluto produce processori per smartphone, integrerà altre robe. E così via.

Ma finchè Intel vorrà mantenere il totale controllo sul contenuto dei suoi SoC, la vedo dura. Ed è questa una delle ragioni per cui Apple è passata ai SoC ARM progettati in-house.

Che poi mi sembra anche che l'uso di AVX-512 causi una riduzione nella frequenza operativa del processore, non mi è ben chiaro il motivo, forse per tenere i consumi entro una certa soglia.

Alla fine della fiera se uno vuole performance serie per quella tipologia di calcoli usa la GPU non certo una CPU.

Non è un caso che il progetto Intel Phi sia fallito miseramente.

E pensare che adesso Intel ha intenzione anche di introdurre le istruzioni AMX per il calcolo matriciale.

Lui stesso dice che se ne frega della virgola mobile, ma il.mo di dei simulatori, delle simulazioni fem, dei CAD e via dicendo ci campano con la parallelizzazione dei double.

Questo genere di calcoli ormai si sta spostando sulle gpu.

E pensare che adesso Intel ha intenzione anche di introdurre le istruzioni AMX per il calcolo matriciale.

Quelle lì sono figlie dell'hype sulle reti neurali. Ormai tutti inseriscono mitologiche NPU, per accelerare il deep learning.

E ancora non è chiaro se abbiano un reale vantaggio rispetto alle GPU!

Che poi mi sembra anche che l'uso di AVX-512 causi una riduzione nella frequenza operativa del processore, non mi è ben chiaro il motivo, forse per tenere i consumi entro una certa soglia.

Alla fine della fiera se uno vuole performance serie per quella tipologia di calcoli usa la GPU non certo una CPU.

Non è un caso che il progetto Intel Phi sia fallito miseramente.

E pensare che adesso Intel ha intenzione anche di introdurre le istruzioni AMX per il calcolo matriciale.


Quasi di sicuro per quello. Quando introdussero le AVX 2 su Haswell, non veniva limitata la frequenza ma il consumo e il calore aumentava tantissimo quando venivano usate. Probabilmente è la stessa cosa ora con quelle

Quasi di sicuro per quello. Quando introdussero le AVX 2 su Haswell, non veniva limitata la frequenza ma il consumo e il calore aumentava tantissimo quando venivano usate. Probabilmente è la stessa cosa ora con quelle

Su un altro sito questo veniva spiegato in questo modo:
Per svolgere calcoli AVX i processori attuali sono costretti a ridurre la propria frequenza operativa per mantenere la stabilità, in quanto i core sono davvero messi sotto pressione. Implementare AVX-512 in una CPU consumer non è uno step facile perché l'implementazione fisica aumenta la dimensione del die – e di conseguenza i costi.

dice quello che io penso da anni, le avx 512 sono usate in una nicchia di software e solo in una nicchia di mercato, mentre le avx 2 sono stra usate anche in software commerciali le nuove sono adette solo a casi particolari che le rende ininfluente in un mercato consumer e nella granparte di quella server

Quasi di sicuro per quello. Quando introdussero le AVX 2 su Haswell, non veniva limitata la frequenza ma il consumo e il calore aumentava tantissimo quando venivano usate. Probabilmente è la stessa cosa ora con quelle

non è la stessa cosa perche le avx impattano leggermente quelle 512 impattano in maniera considerevole su tutta la cpu e per questo è rarissimo che un software ne faccia uso

Su un altro sito questo veniva spiegato in questo modo:
Per svolgere calcoli AVX i processori attuali sono costretti a ridurre la propria frequenza operativa per mantenere la stabilità, in quanto i core sono davvero messi sotto pressione. Implementare AVX-512 in una CPU consumer non è uno step facile perché l'implementazione fisica aumenta la dimensione del die – e di conseguenza i costi.

E ma probabilmente proprio per una questione di temperature e stabilità legata a quello. Evidentemente a frequenze di targa la richiesta energetica per quella porzione di transistor in più è talmente elevata da rendere necessario un cut di frequenze e tensione.

Ci sta, poi considerando che sono ancora su 14nm +*/^ puoi capire...

dice quello che io penso da anni, le avx 512 sono usate in una nicchia di software e solo in una nicchia di mercato, mentre le avx 2 sono stra usate anche in software commerciali le nuove sono adette solo a casi particolari che le rende ininfluente in un mercato consumer e nella granparte di quella server

non è la stessa cosa perche le avx impattano leggermente quelle 512 impattano in maniera considerevole su tutta la cpu e per questo è rarissimo che un software ne faccia uso


Le AVX2 sono usate tanto OGGI, nel 2013 quando furono introdotte su Haswell a parte qualche tool erano usate poco a favore di quelle a 128bit. E già allora in termini di consumo energetico e calore erano onerose, il mio 4770k faceva 30 gradi in più in avx2 rispetto alle avx1, non è poco.

Nel tempo sono migliorate, miglioreranno anche queste immagino. In teoria nel 2022 anche AMD le avrà sulle CPU consumer quindi nel tempo verranno usate anche loro di più. Ad oggi sono abbastanza inutili

E ma probabilmente proprio per una questione di temperature e stabilità legata a quello. Evidentemente a frequenze di targa la richiesta energetica per quella porzione di transistor in più è talmente elevata da rendere necessario un cut di frequenze e tensione.

Ci sta, poi considerando che sono ancora su 14nm +*/^ puoi capire...

Ma infatti Torvalds augurava ogni male possibile alle avx512 proprio per via delle richieste energetiche troppo elevate, con conseguente aumento delle temperature ovviamente...ora lui come il suo solito è molto colorito, però sinceramente penso che a questo giro non ha tutti i torti, alla fine sono istruzioni usate solo in pochi ambiti, dove per lo più si stanno spostando pure verso le gpu, quindi tutto sommato hanno poco senso.

Ma infatti Torvalds augurava ogni male possibile alle avx512 proprio per via delle richieste energetiche troppo elevate, con conseguente aumento delle temperature ovviamente...ora lui come il suo solito è molto colorito, però sinceramente penso che a questo giro non ha tutti i torti, alla fine sono istruzioni usate solo in pochi ambiti, dove per lo più si stanno spostando pure verso le gpu, quindi tutto sommato hanno poco senso.

Beh ma diciamo che fa parte anche del suo personaggio, nel senso anche secondo me oggi come oggi non hanno tanto senso, penso che la scelta di AMD di posticipare l'implementazione sia ragionata.

Però da un punto di vista di progresso tecnologico va fatto prima o poi che se ne faccia una ragione, il problema non sono le avx 512 in se, è solo come lo fanno in Intel che è discutibile...

Ma non capisco a lui che cambia, il suo kernel è usato anche in ambiti diversi da quelli mainstream e quindi le dovrebbe implementare in ogni caso (che sia ora o tra due anni)

Non ha detto che fanno cagare. Ha detto che Intel dovrebbe sfruttare la sua forza lavoro e i transistor per cose più importanti. Cioè, esistono ben altre priorità.La ormai comune prassi di estrapolare dal discorso solo quello che fa comodo :fagiano:

Ha anche detto che il set di istruzioni AVX-512 (Advanced Vector Extensions 512) sparisca dalla faccia della terra il più velocemente possibile, tra atroci sofferenze.
Credo che per lui facciano effettivamente cagare :asd:

Credo che per lui facciano effettivamente cagare :asd:

Il motivo lo ha anche detto :D:
Voglio raggiungere i power limit con il codice integer regolare, non con qualche vampiro energetico come AVX-512 che taglia la frequenza massima (perché le persone finiscono per usarlo per memcpy!) e riduce i core (perché quelle inutili unità di immondizia occupano spazio)

Al di là dei modi folcloristici del personaggio, in questo caso Torvalds ha fondamentalmente ragione. Per farla semplice: una CPU a 16 core con AVX2 ha la stessa capacità massima di calcolo di una a 8 core con AVX-512 ma è molto più flessibile, ha quindi più senso in qualunque contesto scalare la capacità di calcolo aumentando il numero di core piuttosto che esasperando le FPU specializzate nel calcolo SIMD, che restano e resteranno comununque inutilizzate nella grande maggioranza degli scenari applicativi.
Chi poi ha esigenze particolarmente elevate di calcolo vettoriale si rivolgerà sempre a una soluzione di derivazione GPU, incomparabilmente più potente ed energeticamente efficiente.

Indipendentemente dalle scelte di Intel, sarebbe un vero peccato se AMD si allineasse implementando AVX-512 nelle future archietetture Zen, perché significherebbe avere CPU meno potenti a parità di costo, proprio per il grande spreco di transistor sul silicio che ciò comporterebbe.

Torvald però sbaglia nell'analisi storica, le cose non stanno proprio come crede: Intel domina nelle FPU x86 a partire dal Pentium, cioè da 27 anni.

sempre più convinto che linus dovrebbe abbandonare la supervisione di linux per permettere ad un cambio di marcia e aumentare la diffusione del sistema
ma dubito che abbia l'umiltà necessaria a farlo come fece bill gates all'epoca
si certo linux è diffuso nei server però è fortemente personalizzato e per diffonderlo nei desktop ci vuole una mentalità diversa dalla sua

sempre più convinto che linus dovrebbe abbandonare la supervisione di linux per permettere ad un cambio di marcia e aumentare la diffusione del sistema
ma dubito che abbia l'umiltà necessaria a farlo come fece bill gates all'epoca
si certo linux è diffuso nei server però è fortemente personalizzato e per diffonderlo nei desktop ci vuole una mentalità diversa dalla sua

Veramente e` l'os di riferimento anche in ambiente mobile.

Linux va benissimo com`e` ed ha una buona diffusione. Il fatto che per alcune grandissime nicchie (utenti medi o videogamers) vada benissimo o meglio windows e` un altro paio di maniche.

sempre più convinto che linus dovrebbe abbandonare la supervisione di linux per permettere ad un cambio di marcia e aumentare la diffusione del sistema
ma dubito che abbia l'umiltà necessaria a farlo come fece bill gates all'epoca
si certo linux è diffuso nei server però è fortemente personalizzato e per diffonderlo nei desktop ci vuole una mentalità diversa dalla sua

Oh no, la sua mentalità va benissimo. A lui interessa la funzionalità, non si butta in guerre di religione. Semmai, quello che non va in Linux è la mentalità integralista di un numero significativo di "adepti": quelli per esempio che hanno abbandonato GitHub quando è stato comprato da Microsoft.
Curioso come una persona che dà più importanza agli aspetti razionali piuttosto che a quelli emotivi di un progetto informatico sia criticata per il linguaggio acceso.
Io non sono particolarmente filo Linux, ma gli interventi di Torvalds mi sembrano quasi sempre sensati, anche se talvolta un po' folcloristici.

La ormai comune prassi di estrapolare dal discorso solo quello che fa comodo :fagiano:

Ha anche detto che il set di istruzioni AVX-512 (Advanced Vector Extensions 512) sparisca dalla faccia della terra il più velocemente possibile, tra atroci sofferenze.
Credo che per lui facciano effettivamente cagare :asd:

Evidentemente ci sono dettagli implementativi che non gli piacciono. Stessa cosa che ha sempre detto di UEFI. Che effettivamente non è il top della buona ingegneria.

Ma ripeto che la ragione principale della sua tirata è: "Mi piacerebbe piuttosto vedere quel budget di transistor usato su altre cose che sono molto più rilevanti".

E condivido. Ci sono cose molto più importanti da fare. I magheggi coi vettori e le matrici, lasciamoli alle GPU, che tanto ormai s'installano pure nei supercomputer.

Ritorno ai tempi in cui le CPU sapevano fare solo le CPU.

Evidentemente ci sono dettagli implementativi che non gli piacciono. Stessa cosa che ha sempre detto di UEFI. Che effettivamente non è il top della buona ingegneria.

Ma ripeto che la ragione principale della sua tirata è: "Mi piacerebbe piuttosto vedere quel budget di transistor usato su altre cose che sono molto più rilevanti".

E condivido. Ci sono cose molto più importanti da fare. I magheggi coi vettori e le matrici, lasciamoli alle GPU, che tanto ormai s'installano pure nei supercomputer.

Ritorno ai tempi in cui le CPU sapevano fare solo le CPU.

Che poi se proprio vogliamo Intel ha messo le sue GPU pure nelle confezioni di patatine (ogni CPU ormai integra la GPU), con la nuova architettura "Xe" magari potrebbero uscire fuori cose interessanti.

Tra l'altro forse avrebbe proprio senso usare l'hardware GPU già esistente per accelerare una certa tipologia di istruzioni CPU. Ma penso sia fantascienza al momento.

Piuttosto degli Xeon con FPGA a bordo se n'è più saputo nulla?

Lui stesso dice che se ne frega della virgola mobile, ma il.mo di dei simulatori, delle simulazioni fem, dei CAD e via dicendo ci campano con la parallelizzazione dei double.

Appunto, il mondo HPC che come ha già scritto qualcuno ormai usa le GPU

Comunque Torvalds parlava di priorità e la priorità di Intel ora dovrebbe essere fare delle CPU intrinsecamente più sicure non pensare alle prossime AVX

Veramente e` l'os di riferimento anche in ambiente mobile.

Linux va benissimo com`e` ed ha una buona diffusione. Il fatto che per alcune grandissime nicchie (utenti medi o videogamers) vada benissimo o meglio windows e` un altro paio di maniche.

Se sono grandissime non sono nicchie. Queste nicchie su desktop sono la stragrande maggioranza.

Le AVX-512 non sono come "gli altri" set di istruzioni. Imbeccato da altri forum, ho dato una rapida scorsa su wikipedia: sembra chiaro che, come si dice altrove, il problema principale è la frammentazione e l'ambiguità: AVX-512 è composto da tante istruzioni e ogni cpu può supportarne un gruppo ma non un altro, quindi non sono come SSE, AVX e AVX2, che invece o ce le hai tutte oppure non ce le hai.

In più, nel paragrafo "Performance", si fa' riferimento al fatto che le AVX-512 causano un throttling della CPU (forse per motivi di dispendio energetico? O per motivi architetturali?) che rallenta anche il resto del codice.

Per approfondire: https://en.wikipedia.org/wiki/AVX-512

Piuttosto degli Xeon con FPGA a bordo se n'è più saputo nulla?

Ero rimasto che c'erano un paio di modelli in vendita per il mercato HPC.

Le AVX-512 non sono come "gli altri" set di istruzioni. Imbeccato da altri forum, ho dato una rapida scorsa su wikipedia: sembra chiaro che, come si dice altrove, il problema principale è la frammentazione e l'ambiguità: AVX-512 è composto da tante istruzioni e ogni cpu può supportarne un gruppo ma non un altro, quindi non sono come SSE, AVX e AVX2, che invece o ce le hai tutte oppure non ce le hai.

In più, nel paragrafo "Performance", si fa' riferimento al fatto che le AVX-512 causano un throttling della CPU (forse per motivi di dispendio energetico? O per motivi architetturali?) che rallenta anche il resto del codice.

Per approfondire: https://en.wikipedia.org/wiki/AVX-512

Ah ecco. Quindi Torvalds ha più di un motivo per odiarle. Non sapevo fossero separate in subset e non fossero un unico blocco monolitico. Alla fine si crea un casino terribile.

Veramente e` l'os di riferimento anche in ambiente mobile.

Linux va benissimo com`e` ed ha una buona diffusione. Il fatto che per alcune grandissime nicchie (utenti medi o videogamers) vada benissimo o meglio windows e` un altro paio di maniche.

certo come ho scritto per i server android è fortemente personalizzato
poi se mi dici che gamers e pc da ufficio sono delle nicchie mi sa che abbiamo una conoscenza diversa della lingua italiana
poi linus cosa ha fatto oltre a linux ? viene assunto da aziende solo per motivi di marketing ma realmente non ha mai la direzione di grandi progetti o innovazioni

Il problema conoscendo la figura, avrà detto lo stesso per le AVX a 128 e poi per quelle a 256 e dirà lo stesso in futuro per quelle a 1024 XD

E' sempre contro tutto quello che non è farina del suo sacco lol
Soprattutto contro quello che non capisce. Sarà rimasto fermo all'80386, dal quale partito...
Le AVX512 sono parecchio utili invece. Prima di tutto sono gestite automaticamente da compilatore durante le ottimizzazioni quando si può fare, e in seconda battuta uno sviluppatore può usarle proficuamente a basso livello quando cerca prestazioni, ad esempio operazioni su vettori di double per calcoli matriciali, quaternioni etc.

Non è che se uno non sa usare le istruzioni o non vuole o semplicemente non ne ha bisogno allora fanno cagare a prescindere. A Tovards il mondo deve veramente molto, ma ha molto spesso il difetti di pensare che se una cosa non serve a lui allora non serve a nessuno e debba essere eliminata, come in questo caso.

Lui stesso dice che se ne frega della virgola mobile, ma il.mo di dei simulatori, delle simulazioni fem, dei CAD e via dicendo ci campano con la parallelizzazione dei double.
This. Commento da incorniciare.
Ovvero casi speciali. Proprio come dice Torvalds.
Le istruzioni SIMD ormai sono diffusissime: altro che casi speciali.

Hai mai provato a disassemblare un qualunque eseguibile x86 o x64? Vedrai che ne troverai parecchie. Ovviamente quelle "intere" / general purpose saranno sempre di gran lunga più frequenti, ma qui stiamo parlando di ovvietà.

Le AVX-512 sono un'evoluzione delle estensioni SIMD che Intel ha introdotto con le SSE, peraltro sono fortemente legate ad esse (basti vedere come vengono mappati gli opcode AVX-512).
Non ha detto che fanno cagare. Ha detto che Intel dovrebbe sfruttare la sua forza lavoro e i transistor per cose più importanti. Cioè, esistono ben altre priorità.
Sostanzialmente sì: ha detto che fanno cacare.

Inoltre non è una questione mutuamente esclusiva: nessuno impedisce a Intel (o AMD) di implementare unità SIMD innovative E di migliorare le prestazioni generali dei singoli core.
Che penseresti se MS si concentrasse sul menu start, lasciando non patchate decine di vulnerablità?
Esempio fuori luogo: vedi sopra.
Priorità, priorità. Non muore nessuno se le prossime AVX-1024 ( arriveranno, arriveranno ) vengono rimandate di qualche anno.
E perché dovrebbero essere rimandate, visto che si potrebbe fare ANCHE questo assieme al resto?
Il problema di Intel era e rimane la scarsa modularità delle sue offerte. Dovrebbero imparare da ARM e magari cominciare a concedere più IP in licenza.
Non è il suo business model, e mi sembra che al momento le cose le vadano molto bene per pensare di cambiarlo.
Se Pippo produce processori per HPC, integrerà allegramente AVX-512. Se Pluto produce processori per smartphone, integrerà altre robe. E così via.
Anche gli smartphone ormai hanno bisogno di fare calcoli vettoriali.

Il problema di Intel è che ha sviluppato AVX-512 in maniera non scalabile: che ti piaccia o no, ti porti dietro ben 32 registri a 512 bit, mentre in alcuni ambiti potrebbero basterne 16 a 128 bit (come le SSE su x64), ad esempio, mantenendo tutte le caratteristiche peculiari e innovative di questa stupenda estensione SIMD.
Ma finchè Intel vorrà mantenere il totale controllo sul contenuto dei suoi SoC, la vedo dura. Ed è questa una delle ragioni per cui Apple è passata ai SoC ARM progettati in-house.
Apple ci sarebbe passata comunque, perché il suo obiettivo è di farsi tutto in casa, a prescindere da Intel, AMD, IBM, Motorola, etc.. Tant'è che si farà pure le GPU in casa.
Che poi mi sembra anche che l'uso di AVX-512 causi una riduzione nella frequenza operativa del processore, non mi è ben chiaro il motivo, forse per tenere i consumi entro una certa soglia.
Sì, è per mantenersi nel power-budget.
Alla fine della fiera se uno vuole performance serie per quella tipologia di calcoli usa la GPU non certo una CPU.
Non funziona così: le GPU vanno bene se hai da mandare loro in pasto grosse mole di dati e non t'interessa la latenza con cui riceverai indietro i risultati. Un modello del genere va bene in tanti casi, ma ce ne sono tanti altri per cui non va affatto bene.

Ecco perché esistono ancora le unità SIMD all'interno delle CPU, ed è il motivo per cui col tempo sono diventate e stanno diventando sempre più grandi. E no, non è una cosa che fa soltanto Intel: basti guardare ad ARM (SVE), IBM (con le VMX 2), e RISC-V (le estensioni vettoriali).
Non è un caso che il progetto Intel Phi sia fallito miseramente.
Quello è morto principalmente a causa dei problemi di Intel coi 10nm, che non sono arrivati secondo la roadmap, e quindi Intel non poteva realizzare i successivi modelli con molti più core (mantenendo ridotti i consumi, ovviamente).

L'ISA era molto buona, tant'è che è finita pari pari nelle AVX-512 (infatti negli ultimi modelli di Xeon Phi le estensioni SIMD vettoriali non venivano più chiamate KNI, ma AVX-512, per l'appunto).
E pensare che adesso Intel ha intenzione anche di introdurre le istruzioni AMX per il calcolo matriciale.
Fa benissimo. E non è nemmeno l'unica a farlo.
Quasi di sicuro per quello. Quando introdussero le AVX 2 su Haswell, non veniva limitata la frequenza ma il consumo e il calore aumentava tantissimo quando venivano usate. Probabilmente è la stessa cosa ora con quelle
No, con le implementazioni di AVX-512 si abbassa realmente il clock.

Cosa che d'altra avviene già da qualche anno anche con le AVX/-2, che però ricevono la benedizione di Torvalds. Due pesi e due misure...

Con AVX-512 il clock si abbassa ancora di più rispetto alle AVX/-2, ovviamente perché macinano più dati per ciclo di clock. Ma in ogni caso, pur con l'abbassamento del clock, le prestazioni rimangono superiori (altrimenti sarebbe stato inutile).
dice quello che io penso da anni, le avx 512 sono usate in una nicchia di software e solo in una nicchia di mercato, mentre le avx 2 sono stra usate anche in software commerciali le nuove sono adette solo a casi particolari che le rende ininfluente in un mercato consumer e nella granparte di quella server
Le AVX/-2 hanno impiegato parecchio tempo per diffondersi, e ancora oggi non è che lo siano così tanto.

Stessa cosa succederà alle AVX-512: serve tempo per sfruttarle. A maggior ragione perché in ambito consumer non sono mai arrivate (escludendo una manciata di portatili Cannonlake).
Le AVX2 sono usate tanto OGGI, nel 2013 quando furono introdotte su Haswell a parte qualche tool erano usate poco a favore di quelle a 128bit. E già allora in termini di consumo energetico e calore erano onerose, il mio 4770k faceva 30 gradi in più in avx2 rispetto alle avx1, non è poco.

Nel tempo sono migliorate, miglioreranno anche queste immagino. In teoria nel 2022 anche AMD le avrà sulle CPU consumer quindi nel tempo verranno usate anche loro di più. Ad oggi sono abbastanza inutili
Esattamente.
Ma infatti Torvalds augurava ogni male possibile alle avx512 proprio per via delle richieste energetiche troppo elevate, con conseguente aumento delle temperature ovviamente...ora lui come il suo solito è molto colorito, però sinceramente penso che a questo giro non ha tutti i torti, alla fine sono istruzioni usate solo in pochi ambiti, dove per lo più si stanno spostando pure verso le gpu, quindi tutto sommato hanno poco senso.
Ha torto marcio, invece, perché, come già detto, è già da un po' di anni che anche la AVX/-2 abbassano il clock del processore.

Quanto al discorso GPU, vedi sopra.
Il motivo lo ha anche detto :D:
Voglio raggiungere i power limit con il codice integer regolare, non con qualche vampiro energetico come AVX-512 che taglia la frequenza massima (perché le persone finiscono per usarlo per memcpy!) e riduce i core (perché quelle inutili unità di immondizia occupano spazio)
E ha detto delle colossali minchiate. Come suo solito.

Primo perché le frequenze vengono tagliate anche da AVX/-2, che invece lui ha salvato.

Secondo, perché col codice integer "regolare" (sigh!) è estremamente difficile che si possa arrivare al power-limit, visto che non si possono processare enormi quantità di dati. Il codice "intero/scalare" è abbastanza pieno di salti e spostamento di dati, e le istruzioni aritmetiche et similia sono in quantità nettamente inferiori (anche qui: prendete un po' di eseguibili a caso, disassemblateli, e generate delle statistiche sulle istruzioni più usate. Questo a livello "statico". A livello "dinamico" serve lanciare gli eseguibili con tool di profiling/instrumenting che raccolgano le stesse statistiche, ma prendendo tutte le istruzioni eseguite).

Terzo, dimostra una colossale ignoranza: questo sbruffone non apre un manuale delle ottimizzazioni delle architetture (sempre che sappia cosa sia) da eoni.
Già da Haswell Intel ha introdotto dei notevoli miglioramenti nell'esecuzione delle cosiddette istruzioni "di stringa", che consento di eseguire operazioni come memcpy/memset in media più velocemente rispetto alle soluzioni basate su istruzioni SIMD.

Quarto, 9 donne incinte non fanno un bambino in un mese. Aumentare i core comporta ALTRE problematiche, e sappiamo bene (non lui, evidentemente) che è difficile parallelizzare l'esecuzione per sfruttare tutti i core a disposizione.
Per questo preferisco, da sempre, avere processori con pochi core, ma ad alte prestazioni, perché consentono ti coprire molto meglio la maggior parte del codice.
Al di là dei modi folcloristici del personaggio, in questo caso Torvalds ha fondamentalmente ragione. Per farla semplice: una CPU a 16 core con AVX2 ha la stessa capacità massima di calcolo di una a 8 core con AVX-512 ma è molto più flessibile,
Una CPU a 16 core con AVX2 occupa molto più silicio di una CPU con 8 core con AVX-512...
ha quindi più senso in qualunque contesto scalare la capacità di calcolo aumentando il numero di core piuttosto che esasperando le FPU specializzate nel calcolo SIMD, che restano e resteranno comununque inutilizzate nella grande maggioranza degli scenari applicativi.
Se restano inutilizzate nella maggioranza degli scenari, lo saranno ancora meno i tanti core a disposizione.
Chi poi ha esigenze particolarmente elevate di calcolo vettoriale si rivolgerà sempre a una soluzione di derivazione GPU, incomparabilmente più potente ed energeticamente efficiente.
Vedi un po' più sopra riguardo alle GPU.
Indipendentemente dalle scelte di Intel, sarebbe un vero peccato se AMD si allineasse implementando AVX-512 nelle future archietetture Zen, perché significherebbe avere CPU meno potenti a parità di costo, proprio per il grande spreco di transistor sul silicio che ciò comporterebbe.
Invece l'ha già previsto, com'è giusto che sia, e al contrario: si avranno CPU che avranno prestazioni per core più elevate.
Torvald però sbaglia nell'analisi storica, le cose non stanno proprio come crede: Intel domina nelle FPU x86 a partire dal Pentium, cioè da 27 anni.
Tranquillo: non è l'unico sbaglio che ha fatto.
Oh no, la sua mentalità va benissimo. A lui interessa la funzionalità, non si butta in guerre di religione. Semmai, quello che non va in Linux è la mentalità integralista di un numero significativo di "adepti": quelli per esempio che hanno abbandonato GitHub quando è stato comprato da Microsoft.
This.
Curioso come una persona che dà più importanza agli aspetti razionali piuttosto che a quelli emotivi di un progetto informatico sia criticata per il linguaggio acceso.
Io non sono particolarmente filo Linux, ma gli interventi di Torvalds mi sembrano quasi sempre sensati, anche se talvolta un po' folcloristici.
A me no: raramente ho visto affermazioni sensate.

S'è sempre distinto per spararle grosse. Nella storia, però, rimarranno le colossali vaccate sul C++...
Evidentemente ci sono dettagli implementativi che non gli piacciono.
No, è evidente che non sa di cosa parla. Vedi sopra.
Stessa cosa che ha sempre detto di UEFI. Che effettivamente non è il top della buona ingegneria.
Meglio il vecchio BIOS?
Ma ripeto che la ragione principale della sua tirata è: "Mi piacerebbe piuttosto vedere quel budget di transistor usato su altre cose che sono molto più rilevanti".

E condivido. Ci sono cose molto più importanti da fare. I magheggi coi vettori e le matrici, lasciamoli alle GPU, che tanto ormai s'installano pure nei supercomputer.

Ritorno ai tempi in cui le CPU sapevano fare solo le CPU.
Ma anche no, e vedi (un po') sopra.
Che poi se proprio vogliamo Intel ha messo le sue GPU pure nelle confezioni di patatine (ogni CPU ormai integra la GPU), con la nuova architettura "Xe" magari potrebbero uscire fuori cose interessanti.

Tra l'altro forse avrebbe proprio senso usare l'hardware GPU già esistente per accelerare una certa tipologia di istruzioni CPU. Ma penso sia fantascienza al momento.
Si potrebbe fare, ma non sempre la GPU è la soluzione migliore per determinati compiti.

Tanto per fare un esempio, se per ordinare un insieme di dati perdi più tempo a trasferirli alla GPU, farglieli processare, e poi ritrasferirli di nuovo nella memoria di sistema, quando la CPU riesce a farlo molto più velocemente (e magari quei dati gli servono il prima possibile), è chiaro che è meglio preferire quest'ultima.
Piuttosto degli Xeon con FPGA a bordo se n'è più saputo nulla?
Veramente ci sono già da parecchi anni: da prima che Intel acquisisse Altera (e questo è stato uno dei motivi: portarsi dentro tutto).
Appunto, il mondo HPC che come ha già scritto qualcuno ormai usa le GPU
Per l'HPC magari ha più senso.
Comunque Torvalds parlava di priorità e la priorità di Intel ora dovrebbe essere fare delle CPU intrinsecamente più sicure non pensare alle prossime AVX
A parte che le AVX-512 esistono da parecchi anni ormai, per cui non deve certo pensarci ancora, le due cose non sono mutuamente esclusive.
Se sono grandissime non sono nicchie. Queste nicchie su desktop sono la stragrande maggioranza.
This.
Le AVX-512 non sono come "gli altri" set di istruzioni. Imbeccato da altri forum, ho dato una rapida scorsa su wikipedia: sembra chiaro che, come si dice altrove, il problema principale è la frammentazione e l'ambiguità: AVX-512 è composto da tante istruzioni e ogni cpu può supportarne un gruppo ma non un altro, quindi non sono come SSE, AVX e AVX2, che invece o ce le hai tutte oppure non ce le hai.

In più, nel paragrafo "Performance", si fa' riferimento al fatto che le AVX-512 causano un throttling della CPU (forse per motivi di dispendio energetico? O per motivi architetturali?) che rallenta anche il resto del codice.

Per approfondire: https://en.wikipedia.org/wiki/AVX-512
Mentre va benissimo avere le SSE, SSE2, SSE3, SSSE3, SSE4, più una miriade di altre singole istruzioni aggiunte per specifici scopi?

Almeno con le AVX-512 c'è un sostanzioso set di base, e poi dei gruppi di istruzioni per specifici scopi. Quindi, esattamente al contrario, c'è molto più ordine, chiarezza, e meno frammentazione.
Ah ecco. Quindi Torvalds ha più di un motivo per odiarle. Non sapevo fossero separate in subset e non fossero un unico blocco monolitico. Alla fine si crea un casino terribile.
Intanto vedi sopra. Se poi aggiungiamo pure le AVX/-2 al blocco precedente, c'è ancora più casino. Ma in questi casi il casino (!) piace a Torvalds, e va tutto bene, vero?

Torvalds dimostra non soltanto incoerenza, ma una grandissima ignoranza in materia...

Ha torto marcio, invece, perché, come già detto, è già da un po' di anni che anche la AVX/-2 abbassano il clock del processore.

Quanto al discorso GPU, vedi sopra.

Veramente lui ha detto che oltre ad abbassare il clock tolgono posto anche a eventuali processori in più, il suo pensiero è molto diverso, sta semplicemente dicendo che lui preferirebbe avere più core al posto delle avx512.
Riguardo al discorso gpu sono un analista numerico, i set di dati che tratto sono sempre estremamente grandi, non conviene mai farli fare a un pc normale, li fai sempre sul server, per i set di dati piccoli ti basta un processore di 10/15 anni fa, non c'è bisogno neanche di avere una cpu all'avanguardia.

Tanto per fare un esempio, se per ordinare un insieme di dati perdi più tempo a trasferirli alla GPU, farglieli processare, e poi ritrasferirli di nuovo nella memoria di sistema, quando la CPU riesce a farlo molto più velocemente (e magari quei dati gli servono il prima possibile), è chiaro che è meglio preferire quest'ultima.

Dipende dal set di dati, dipende dal processore e dalla gpu, un algoritmo di ordinamento efficiente non scende al di sotto di nlog(n), è matematica, non si cambia...le latenze con set di dati molto grandi sono trascurabili se la gpu ha una capacità elaborativa di molto superiore al processore...il concetto di "fare prima" è sempre molto relativo.

Mentre va benissimo avere le SSE, SSE2, SSE3, SSSE3, SSE4, più una miriade di altre singole istruzioni aggiunte per specifici scopi?

Almeno con le AVX-512 c'è un sostanzioso set di base, e poi dei gruppi di istruzioni per specifici scopi. Quindi, esattamente al contrario, c'è molto più ordine, chiarezza, e meno frammentazione.

Non devi porre le tue domande a me, io non ho espresso alcuna opinione. Mi sembrava chiaro che avessi citato solo wikipedia per fare chiarezza in merito al pensiero di Torvalds.

Poi se vuoi la mia opinione, se Torvalds dice che le AVX-512 sono m***a, tendo a credergli, anche perché ha argomentato la sua posizione ed è Torvalds. Se tu mi dici che invece è tutto il contrario e ti allacciano anche le scarpe, meh... :rolleyes:

Torvald però sbaglia nell'analisi storica, le cose non stanno proprio come crede: Intel domina nelle FPU x86 a partire dal Pentium, cioè da 27 anni.

Su x86 Intel dall'80387 (la FPU) in poi è sempre stata competitiva, perlomeno fino al Pentium III.

Credo piuttosto che lui intendesse dire che all'epoca altre architetture (leggi PowerPC, Alpha, ...) avevano FPU ben più performanti di Intel.

In programmi come Cinema 4D 21 basato su Intel Embree 3.2.2., ottimizzato per cpu Intel e che usa le AVX-512, alla fine, il risultato a parità di core è questo:
https://techgage.com/article/maxon-cinema-4d-cpu-performance/

stessa cosa con Blender 2.83 nel test cpu:
https://techgage.com/article/blender-2-83-best-cpus-gpus-for-rendering-viewport/

si fa' presto a dire che il tal programma usa le Avx-512

Torvald però sbaglia nell'analisi storica, le cose non stanno proprio come crede: Intel domina nelle FPU x86 a partire dal Pentium, cioè da 27 anni.

Embè 'nsomma. Power ha sempre potuto dire la sua. Non conosco confronti specifici, ma ho letto vari articoli in cui si mostrava la superiorità di Power ( e di Altivec ) rispetto alle controparti x86, in alcuni benchmark.

Torvald però sbaglia nell'analisi storica, le cose non stanno proprio come crede: Intel domina nelle FPU x86 a partire dal Pentium, cioè da 27 anni.

Direi di no.

Veramente lui ha detto che oltre ad abbassare il clock tolgono posto anche a eventuali processori in più,
Sì, e non è necessariamente una cosa cattiva.
il suo pensiero è molto diverso, sta semplicemente dicendo che lui preferirebbe avere più core al posto delle avx512.
Lui vorrebbe far sparire queste estensioni. Ergo: togliere la possibilità di usarla agli altri.

Vedi tu se ha senso un'affermazione del genere da uno nella sua posizione...
Riguardo al discorso gpu sono un analista numerico, i set di dati che tratto sono sempre estremamente grandi, non conviene mai farli fare a un pc normale, li fai sempre sul server,
L'avevo già detto, infatti.

Ma il tuo caso funziona bene se i dati sono anche nel server, perché se dovessi metterti a caricarli dal tuo PC molto probabilmente ti converrebbe processarli localmente, vista la lentezza delle connessioni.
per i set di dati piccoli ti basta un processore di 10/15 anni fa, non c'è bisogno neanche di avere una cpu all'avanguardia.
In tal caso non servirebbero nemmeno processori moderni, che però esistono e vengono usati: quindi servono.
Dipende dal set di dati, dipende dal processore e dalla gpu, un algoritmo di ordinamento efficiente non scende al di sotto di nlog(n), è matematica, non si cambia...le latenze con set di dati molto grandi sono trascurabili se la gpu ha una capacità elaborativa di molto superiore al processore...il concetto di "fare prima" è sempre molto relativo.
Ma avevo già detto anche questo: dipende da quello che ci devi fare.
Non devi porre le tue domande a me, io non ho espresso alcuna opinione. Mi sembrava chiaro che avessi citato solo wikipedia per fare chiarezza in merito al pensiero di Torvalds.
Io ho portato i fatti, però: la sfilza di estensioni SIMD che precedono le AVX-512 (e non ho nemmeno riportato le singole istruzioni aggiuntive), in barba a quello che dice Torvalds.
Poi se vuoi la mia opinione, se Torvalds dice che le AVX-512 sono m***a, tendo a credergli, anche perché ha argomentato la sua posizione ed è Torvalds. Se tu mi dici che invece è tutto il contrario e ti allacciano anche le scarpe, meh... :rolleyes:
A me non serve che ci sia qualcuno che mi allacci le scarpe: le "argomentazioni" di Torvalds le ho smontate una per una. E chiunque abbia un minimo di conoscenza in materia le può verificare.

Peraltro in una discussione dovrebbero essere importanti i fatti, e non chi parla. Altrimenti si scade nel ricorso all'autorità: una nota fallacia logica.

Infatti non ho chiesto e non chiedo a nessuno di credermi sulla parola. Se a te piace credere a Torvalds soltanto perché è lui che parla, non ha nemmeno senso discutere.
Su x86 Intel dall'80387 (la FPU) in poi è sempre stata competitiva, perlomeno fino al Pentium III.

Credo piuttosto che lui intendesse dire che all'epoca altre architetture (leggi PowerPC, Alpha, ...) avevano FPU ben più performanti di Intel.
Sì, facendo il confronto con le altre architetture. Anche Itanium era messo meglio.
In programmi come Cinema 4D 21 basato su Intel Embree 3.2.2., ottimizzato per cpu Intel e che usa le AVX-512, alla fine, il risultato a parità di core è questo:
https://techgage.com/article/maxon-cinema-4d-cpu-performance/

stessa cosa con Blender 2.83 nel test cpu:
https://techgage.com/article/blender-2-83-best-cpus-gpus-for-rendering-viewport/

si fa' presto a dire che il tal programma usa le Avx-512
E' difficile comprendere i benefici delle AVX-512 da quei test. L'ideale sarebbe utilizzare la stessa CPU, eseguendo test con e senza AVX-512.

Ho recuperato velocemente qualche benchmark:
https://www.pugetsystems.com/labs/hpc/Skylake-X-7800X-vs-Coffee-Lake-8700K-for-compute-AVX512-vs-AVX2-Linpack-benchmark-1068/
https://www.pugetsystems.com/labs/hpc/Build-TensorFlow-CPU-with-MKL-and-Anaconda-Python-3-6-using-a-Docker-Container-1133/
https://www.servethehome.com/intel-xeon-d-2183it-benchmarks-and-review-16c-soc/2/
https://www.phoronix.com/scan.php?page=article&item=gcc9-skylake-avx512&num=1

Il primo è interessante perché ci sono due macchine abbastanza simili, anche se non identiche (ma quella dotata di AVX-512 è messa peggio su tutto il resto).
Il secondo, invece, consente di vedere la differenza fra AVX-512 e non, sulla stessa macchina.

Comunque mi sembra evidente che ci siano dei vantaggi, anche notevoli, usando questa nuova estensione SIMD.
Embè 'nsomma. Power ha sempre potuto dire la sua. Non conosco confronti specifici, ma ho letto vari articoli in cui si mostrava la superiorità di Power ( e di Altivec ) rispetto alle controparti x86, in alcuni benchmark.
https://militaryembedded.com/radar-ew/signal-processing/avx-leap-forward-dsp-performance

9 anni fa: con le AVX (nemmeno le -2) appena uscite...

Sì, e non è necessariamente una cosa cattiva.

Lui vorrebbe far sparire queste estensioni. Ergo: togliere la possibilità di usarla agli altri.

Vedi tu se ha senso un'affermazione del genere da uno nella sua posizione...

Ha espresso la sua opinione, nel modo più assurdo come al solito, ma se a lui queste estensioni non piacciono e preferisce più core amen, tanto intel se ha scelto una strada non la cambia di certo per le colorite affermazioni di Torvalds...che tra l'altro è passato pure alla concorrenza, quindi potrebbe anche semplicemente rimarcare il perché della sua scelta.

Ma il tuo caso funziona bene se i dati sono anche nel server, perché se dovessi metterti a caricarli dal tuo PC molto probabilmente ti converrebbe processarli localmente, vista la lentezza delle connessioni.

La prima cosa che si fa quando si acquisiscono dei dati è caricarli sul server, prima di tutto per avere una copia di sicurezza, poi perché nel 99,9% dei casi verranno processati li...questo indipendentemente dai dati, può essere un file da pochi mb, come uno da qualche gb.

In tal caso non servirebbero nemmeno processori moderni, che però esistono e vengono usati: quindi servono.

Possono servire i processori nuovi in generale, le estensioni sono una cosa in più, ma che a conti fatti se un pc di 10 anni fa impiega 1 secondo e quello nuovo 0.6 secondi fa poca differenza...fossero anche 5 secondi e 1 secondo non farebbe differenza.

Io ho portato i fatti, però: la sfilza di estensioni SIMD che precedono le AVX-512 (e non ho nemmeno riportato le singole istruzioni aggiuntive), in barba a quello che dice Torvalds.


E che paragone sarebbe?

La sfilza di estensioni si sono succede in quanti anni? Partiamo dalle SSE dei Pentium III alle AVX2 di qualche anno fa'. Non è un paragone calzante, perché una osservazione (ma non unica) di Torvalds riguarda il fatto che le AVX-512 sono de facto progettate per frammentare il mercato.


A me non serve che ci sia qualcuno che mi allacci le scarpe: le "argomentazioni" di Torvalds le ho smontate una per una. E chiunque abbia un minimo di conoscenza in materia le può verificare.


Mah, sono assolutamente perplesso, non mi è sembrata una gran difesa la tua, sia per il paragone improprio di prima sia per il fatto che affermi che AVX-512 porta ordine, cosa che oggettivamente non fa'. Peraltro non si capirebbe l'astio di Torvalds nei confronti di queste benedette istruzioni, se fossero davvero utili e portassero davvero ordine.
Quindi o Torvalds una mattina s'è svegliato e ha detto "oggi faccio una crociata contro le AVX-512", oppure ragionandoci sopra s'è accorto che qualcosa non va'.


Peraltro in una discussione dovrebbero essere importanti i fatti, e non chi parla. Altrimenti si scade nel ricorso all'autorità: una nota fallacia logica.

Infatti non ho chiesto e non chiedo a nessuno di credermi sulla parola. Se a te piace credere a Torvalds soltanto perché è lui che parla, non ha nemmeno senso discutere.


Non è che a me "piace credere" - asserto che sminuisce la capacità critica dell'interlocutore in materia, cioè io - a Torvalds perché è tale, ma se in una discussione sulle finanze dello stato mi si contrappongono il ministro dell'economia e l'ultimo beone del bar sport, mi sembra naturale che il ministro riceva più credito.
Se poi uno ha anche la capacità tecnica di discernere tra le argomentazioni tanto meglio.

9 anni fa: con le AVX (nemmeno le -2) appena uscite...

E per forza, dai 128 bit di Altivec, ai 256 di AVX. Il punto è capire a quanta gente servono. Torvalds non sta criticando l'idea di inserire processori vettoriali nei SoC, ma si lamenta della troppa concentrazione su AVX-512 e sul fatto che sia presenti, secondo lui, in troppi modelli di processori.

Ha espresso la sua opinione, nel modo più assurdo come al solito, ma se a lui queste estensioni non piacciono e preferisce più core amen, tanto intel se ha scelto una strada non la cambia di certo per le colorite affermazioni di Torvalds...che tra l'altro è passato pure alla concorrenza, quindi potrebbe anche semplicemente rimarcare il perché della sua scelta.
Cosa che non mi pare abbia fatto, per l'appunto.

Ognuno ha le sue preferenze, e su questo nessuno dovrebbe avere nulla da dire (De gustibus).
Si sarebbe potuto limitare a dire: "per le MIE esigenze non servono né le operazioni a virgola mobile (che rimarrebbe falso: se devi compilare servono pure quelle, e non sto qui a spiegare il perché) né unità SIMD potente (e qui potrebbe starci), ma più core". Fine della questione.
Possono servire i processori nuovi in generale, le estensioni sono una cosa in più, ma che a conti fatti se un pc di 10 anni fa impiega 1 secondo e quello nuovo 0.6 secondi fa poca differenza...fossero anche 5 secondi e 1 secondo non farebbe differenza.
Come già detto prima, ormai da parecchi anni si usano anche le estensioni SIMD: basti prendere un qualunque eseguibile e disassemblarlo per prenderne atto.

Ad esempio i giochi, che sono uno dei tipi di software più diffuso, le usano abbondantemente (per ovvie ragioni).

Dunque tali estensioni servono anche nei processori "general-purpose".
E che paragone sarebbe?

La sfilza di estensioni si sono succede in quanti anni? Partiamo dalle SSE dei Pentium III alle AVX2 di qualche anno fa'. Non è un paragone calzante, perché una osservazione (ma non unica) di Torvalds riguarda il fatto che le AVX-512 sono de facto progettate per frammentare il mercato.
Non sono frammentate, ma l'esatto contrario.

Infatti per avere ciò che le AVX-512 offrono devi prendere tutte le estensioni SSE + tutte le AVX (non-512) + altre singole istruzioni e metterle assieme.

Le AVX-512 hanno unificato i precedenti set di istruzioni SIMD offrendo un'ampia base comune che può essere utilizzata in tanti ambiti.

IN PIU' ha aggiunto dei gruppi di istruzioni che servono a coprire SPECIFICHE esigenze, e che sono abilitate in particolari settori (HPC, IA, ecc.) e che quindi sono presenti in specifici processori.

A me pare una soluzione di gran lunga più ordinata nonché ingegnerizzata.
Mah, sono assolutamente perplesso, non mi è sembrata una gran difesa la tua, sia per il paragone improprio di prima sia per il fatto che affermi che AVX-512 porta ordine, cosa che oggettivamente non fa'.
T'ho risposto meglio sopra. Spero che sia sufficiente, perché se non ti basta il prossimo passo sarebbe snocciolare una per una tutte le istruzioni introdotte da tutte le precedenti estensioni SIMD (incluse certe singole istruzioni) e farti vedere come te le trovi quasi tutte nel set base di AVX-512, che è quello che verrà usato in tutti i processori Intel.
Peraltro non si capirebbe l'astio di Torvalds nei confronti di queste benedette istruzioni, se fossero davvero utili e portassero davvero ordine.
Quindi o Torvalds una mattina s'è svegliato e ha detto "oggi faccio una crociata contro le AVX-512", oppure ragionandoci sopra s'è accorto che qualcosa non va'.
Propendo per la seconda, per quanto detto sopra.

Inoltre "dimentica" che sono state introdotte principalmente per aumentare le prestazioni SIMD. Com'è sempre stato in passato.

E non sto nemmeno entrando nei dettagli, perché potrei anche mostrarti alcune utilissime caratteristiche che sono utilizzabili/applicabili a tutte le istruzioni SIMD, che consentono di risolvere in maniera efficiente (più veloce) ed elegante pattern comuni che con le altre istruzioni richiedono un certo numero di istruzioni e (spesso) registri utilizzati in più (mentre su AVX-512 ciò si traduce nell'abilitare alcuni flag/bit nell'opcode dell'istruzione).
Non è che a me "piace credere" - asserto che sminuisce la capacità critica dell'interlocutore in materia, cioè io - a Torvalds perché è tale, ma se in una discussione sulle finanze dello stato mi si contrappongono il ministro dell'economia e l'ultimo beone del bar sport, mi sembra naturale che il ministro riceva più credito.
Se poi uno ha anche la capacità tecnica di discernere tra le argomentazioni tanto meglio.
La storia dimostra che un ministro che ricopre una certa carica non necessariamente abbia conoscenze in materia (non faccio esempi, anche recenti, che potrebbero dimostrarlo facilmente, perché si finirebbe in caciara).

Ciò precisato, e come già detto prima, le discussioni dovrebbero essere incentrate su argomentazioni e fatti.
Nel primo commento ho riportato in maniera precisa e puntuale argomentazioni e fatti alle sparate di Torvalds. Liquidarle con "mi fido di Torvalds e quindi concordo" lascia il tempo che trova in una discussione, specialmente se tali affermazioni siano state contestate (e non con un simmetrico: "non è vero, perché non mi fido di Torvalds".
Per cui se pensi che ciò che abbia scritto non corrisponda al vero, sei liberissimo di quotare le singole parti (visto che s'è parlato di diversi punti "indipendenti" / che meritano una trattazione specifica), e possiamo intavolare una discussione seria sull'argomento. E se certe cose non sono chiare non ho problemi ad approfondire, portando anche esempi concreti.
Più di questo non posso fare.
E per forza, dai 128 bit di Altivec, ai 256 di AVX.
Non sarebbe sufficiente a giustificare questo:
"How does AVX stack up to AltiVec and SSE? In application tests using VSIPL, the combination of AVX and a second-generation Intel Core i7 (2.1 GHz) processor did well when compared to AltiVec running on a Freescale 8640 (1 GHz) processor. Running a range of 1D complex FFTs with sample range sizes from 256 bytes to 512 Kbytes on a single core, the Intel/AVX platform’s performance ranged 5 to 14x faster than the 8640. When compared on multiple 1D complex FFTs, the Intel/AVX platform measured 5 to 10x faster. When performance was compared running a complex matrix transpose, the Intel/AVX platform was rated at 7 to 26x faster. Also, in a test of vector multiply speed, the Intel/AVX was 4.6 to 72x faster than the 8640/AltiVec."
Limitando il confronto alle sole AVX vs SSE, la situazione è questa:
"Intel has published direct SSE versus AVX comparisons with benchmarks run on the same second-generation Core i7 processor with FFT performance improvements ranging from 1.2 to 1.8x"
Quindi anche riducendo i precedenti risultati di un fattore 1,8, le SSE obliterano letteralmente Altivec.
Il punto è capire a quanta gente servono. Torvalds non sta criticando l'idea di inserire processori vettoriali nei SoC,
No, è proprio quello che fatto, invece, ed è andato pure ben oltre dicendo che non gli servono le istruzioni in virgola mobile...
ma si lamenta della troppa concentrazione su AVX-512 e sul fatto che sia presenti, secondo lui, in troppi modelli di processori.
Com'è meglio che siano: quando diventeranno più comuni ci sarà più software a supportarle, e in futuro potremmo avere software per le sole AVX-512, anziché software che abbia code-path appositi per tutte o un sottoinsieme delle varie estensioni SSE/AVX (e singole istruzioni).

Omogeneità vs frammentazione: l'esatto contrario delle sue tesi...

...come al solito con quanto leggo/scritto dal Dott. Di Mauro.
Gli insiemi di istruzioni Single Instruction Multiple Data secondo la notissima tassonomia, vengono impiegati (soprattutto il set SSE2 ma non solo questo anche l'AVX ed AVX2) in modo esteso per superare uno dei grossi problemi dell'architettura di unità in virgola mobile x87, ovvero il relativo stack con numero ridotto di registri.
Torvalds forse è ancora romanticamente legato alla "opzione" del coprocessore matematico 80387 ad esempio che in epoca di estrema diffusione delle catene di franchising di personal computer, anche da noi in Italia veniva acquistato se e quando ve ne fosse bisogno oppure quando si capiva che con le sole istruzioni assembly "su interi" si poteva fare poco (esistevano emulatori anche per i coprocessori 8087 e seguenti. Lo impiegai su di un piccolissimo HP 95LX per usare Matlab).
Il calcolo in virgola mobile è stato un tallone di Achille classico per le cpu con ISA x86 almeno fino al possente processore Pentium Pro ma invero anche in quel periodo dato che le cpu RISC erano molto più diciamo "rapide".
Anche con i coprocessori matematici installati oppure integrati a partire dall'80486 ma in versione DX, c'era come ricorderete sicuramente l'esigenza di impiegare pochissimo le istruzioni trascendentali molto "lente" e che richiedevano molti cicli di "orologio" ooooppss clock.
Motivo per cui il Motorola MC68040 che era più potente del coevo 80486, anche per risparmiare il numero di transistor integrati, le emulava in software.
Grazie.

Marco71

Ora Torvalds ok, però pure quelli di cloudflare ne consigliano la disattivazione per server e desktop, è un caso?
https://blog.cloudflare.com/on-the-dangers-of-intels-frequency-scaling/

...che esiste già dall'epoca dei set di istruzioni SIMD AVX ed AVX2.

https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/performance-xeon-e5-v3-advanced-vector-extensions-paper.pdf

Che si ripropone solamente.

Grazie.

Marco71

...che esiste già dall'epoca dei set di istruzioni SIMD AVX ed AVX2.

Beh, il problema deve essersi aggravato molto se consigliano addirittura di disattivarle se non se ne hanno specifiche necessità.

...dell'impatto sul "consumo"/assorbimento di potenza elettrica.

https://tu-dresden.de/zih/forschung/ressourcen/dateien/projekte/firestarter/Energy-Efficiency-Features-of-the-Intel-Skylake-SP-Processor-and-Their-Impact-on-Performance.pdf?lang=en

Marco71

Da dire però che attualmente le rodate avx2 aiutano molto nella compressione video (in h265, h264, ecc.), a volte anche in build di chromium con tale supporto.

...dell'impatto sul "consumo"/assorbimento di potenza elettrica.

Consumo molto alto e che di fatto ne limita l'utilità...non mi sembrano valutazioni molto positive.

Lui vorrebbe far sparire queste estensioni. Ergo: togliere la possibilità di usarla agli altri.

Nella stessa discussione Torvalds chiarisce meglio la sua posizione riguardo le AVX-512:
https://www.realworldtech.com/forum/?threadid=193189&curpostid=193203

In poche parole, quello che gli sta sul caXXo è che Intel continua ad aggiungere istruzioni senza considerare a sufficienza che implicazioni hanno a livello architetturale e complicando inutilmente la vita agli sviluppatori.

Si è appena visto con Alder Lake, che implementa una soluzione analoga a big.LITTLE ma con il casino aggiuntivo che le AVX-512 sono utilizzabili solo sui core "big", questo complica lo scheduler e lo sviluppo del codice poichè servono modifiche al S.O. per sfruttare davvero tutti i core (oppure compilando il codice senza il supporto AVX-512).

Invece Torvalds vede molto bene le SVE2 (le SVE "per tutti" di ARM) perchè permettono di scrivere codice che gira da implementazioni a 128bit su fino 2048bit senza toccare una riga di codice e scrivendo già ora codice che semmai verrà fatta l'implementazione a 2048bit potrà sfruttarle al massimo senza dover ritoccare manco una riga di codice.

Inoltre proprio perchè SVE2 è "vector Lenght Agnostic" (VLA):
da un lato chi sviluppa codice sa che se usa quelle istruzioni, indipendentemente dalla cpu su cui girano otterrà il massimo delle prestazioni da quel specifico core.
e dall'altro chi sviluppa l'hardware può implementare SVE2 nel modo che preferisce (es: vector lenght a 128bit per i core little e vectore lenght 1024 per i big) con codice che è perfetamente switchabile tra un core big ed uno little senza rotture di scatole particolari.

Non è un caso se per Risc-V non si sono ancora definite le SIMD standard e neppure quelle "vettoriali" standard, il motivo principale sta tutto nel trovare il giusto equilibrio (e suppongo vogliano pure valutare "nel mondo reale" cosa sia sfuggito nello sviluppare le AVX-512 di Intel e le SVE2 di ARM).

Ora Torvalds ok, però pure quelli di cloudflare ne consigliano la disattivazione per server e desktop, è un caso?
https://blog.cloudflare.com/on-the-dangers-of-intels-frequency-scaling/
Beh, il problema deve essersi aggravato molto se consigliano addirittura di disattivarle se non se ne hanno specifiche necessità.
Consumo molto alto e che di fatto ne limita l'utilità...non mi sembrano valutazioni molto positive.
Non sta scritto da nessuna parte che le AVX-512 debbano fornire le migliori prestazioni in tutti gli scenari.

In quello utilizzato e analizzato da Cloudflare c'è un calo prestazionale generale perché, paradossalmente, sono usate poco (soltanto per la decrittazione), e quindi il sistema diminuisce la frequenza, ma quando poi deve fare altro (non usando le AVX-512) il clock è ancora troppo basso e le prestazioni del codice non-AVX-512 ne risentono di conseguenza.

Ma non è uno scenario applicabile ovunque (vedi i link che ho postato prima), per cui il consiglio generalizzato di Cloudflare di disattivare le AVX-512 è sbagliato.

Anche perché, come giustamente fatto osservare dall'Ing. Marco71 (che ringrazio anche per l'interessante paper), la diminuzione del clock succede anche con le AVX/-2, e quindi scenari del genere possono verificarsi anche con queste estensioni (in maniera più limitata, certamente, perché la frequenza è più alta rispetto alle AVX-512).

Detto in altri termini: fare la guerra tout court soltanto alle AVX-512 è del tutto insensato e denota soltanto un preconcetto.
Da dire però che attualmente le rodate avx2 aiutano molto nella compressione video (in h265, h264, ecc.), a volte anche in build di chromium con tale supporto.
Esistono build che usano le AVX-512?
Nella stessa discussione Torvalds chiarisce meglio la sua posizione riguardo le AVX-512:
https://www.realworldtech.com/forum/?threadid=193189&curpostid=193203

In poche parole, quello che gli sta sul caXXo è che Intel continua ad aggiungere istruzioni senza considerare a sufficienza che implicazioni hanno a livello architetturale e complicando inutilmente la vita agli sviluppatori.
Non è quello che ha detto in quel commento.

Ha ribadito, invece, la sua irrazionale (e sono parole sue) avversione alle unità FP e vettoriali, classificando come "benchmark" (tutto) il codice che le usa (in buona sostanza: sono tali benchmark che spingono a pompare tali unità).

Intel l'ha menzionata soltanto per le AVX-512 (quindi non a livello generale), e per motivazioni ben diverse (ma ne parlo meglio dopo).
Si è appena visto con Alder Lake, che implementa una soluzione analoga a big.LITTLE ma con il casino aggiuntivo che le AVX-512 sono utilizzabili solo sui core "big", questo complica lo scheduler e lo sviluppo del codice poichè servono modifiche al S.O. per sfruttare davvero tutti i core (oppure compilando il codice senza il supporto AVX-512).
Questa è una cosa completamente diversa e non riguarda specificamente le AVX-512.

Infatti esistono altri processori aventi core con configurazioni eterogenee e che richiedono supporto a livello di scheduler per gestire correttamente il context switch dei processi (in modo da non smistare processi a core che non li possono eseguire).

Per cui cose del genere non le stiamo scoprendo per la prima volta con Intel...
Invece Torvalds vede molto bene le SVE2 (le SVE "per tutti" di ARM) perchè permettono di scrivere codice che gira da implementazioni a 128bit su fino 2048bit senza toccare una riga di codice e scrivendo già ora codice che semmai verrà fatta l'implementazione a 2048bit potrà sfruttarle al massimo senza dover ritoccare manco una riga di codice.

Inoltre proprio perchè SVE2 è "vector Lenght Agnostic" (VLA):
da un lato chi sviluppa codice sa che se usa quelle istruzioni, indipendentemente dalla cpu su cui girano otterrà il massimo delle prestazioni da quel specifico core.
e dall'altro chi sviluppa l'hardware può implementare SVE2 nel modo che preferisce (es: vector lenght a 128bit per i core little e vectore lenght 1024 per i big) con codice che è perfetamente switchabile tra un core big ed uno little senza rotture di scatole particolari.
E' chiaro (e l'ha esplicitato) preferisca soluzioni VLA, perché scrivi il codice una volta e poi si demanda il tutto alla specifica micro-architettura, ma Torvalds sbaglia a usare la parola frammentazione in questo contesto.

Le AVX-512 non frammentano, da questo punto di vista, perché esiste una sola estensione SIMD, ed è a 512 bit.

Lui, invece, preferisce implementazioni a 128 bit (che trova ottimale. Bontà sua..) e che VLA (perché non devi scrivere codice per estensioni a 128, 256, e 512 bit).

Se dovessi parlare di frammentazione a livello di "aggiunta di istruzioni" (come s'è sempre fatto), non è certo un problema dei soli processori Intel, visto che pure altre architetture hanno fatto lo stesso. Perfino wiki riporta le varie estensioni di casa ARM.

Ad esempio: https://en.wikipedia.org/wiki/AArch64 E mi sono limitato alla sola ISA a 64 bit, che è la più recente nonché "nuova di pacca", con la quale l'azienda ha avuto tutto il tempo per definire un "clean design" e limitare le estensioni. Invece l'elenco mi pare piuttosto eloquente.
Ed è singolare che, dopo aver avuto tutto il tempo per tirare fuori le SVE e "farle bene", a circa due anni di distanza abbia annunciato le SVE2 per estendere quest'unità SIMD.
Ma immagino che qui andrà tutto bene per Torvalds: non ci sarà frammentazione nel dover supportare sia SVE sia SVE2, vero?
Non è un caso se per Risc-V non si sono ancora definite le SIMD standard e neppure quelle "vettoriali" standard,
Le SIMD standard sono sostanzialmente le versioni "packed" che ha sviluppato Andes per agevolare codice di tipo DSP, e penso che rimarranno solo quelle.

Le vettoriali standard sono in lavorazione da parecchio tempo ormai (come dicevo in un altro messaggio), e devono ancora finalizzarle nonostante avessero promesso che la ratifica sarebbe dovuta arrive già un paio di anni fa. E non che manchino loro menti pregiate, eh! Ormai da tempo su RISC-V si sono buttate quasi tutte le aziende, per cui non mancano certo i contributi.

I problemi sorgono quando a dirigere la baracca ci sono cattedratici alla ricerca della "perfezione", della "purezza" dell'ISA, mentre la realtà e il pragmatismo stanno dimostrando, man mano che si va avanti con la definizione delle specifiche, che andranno ben lontani dall'iperuranio che avevano agognato...
il motivo principale sta tutto nel trovare il giusto equilibrio (e suppongo vogliano pure valutare "nel mondo reale" cosa sia sfuggito nello sviluppare le AVX-512 di Intel e le SVE2 di ARM).
Non è che ci voglia tanto per fare queste valutazioni: basti andare a guardare la storia, che come sempre aiuta e mette le cose in chiaro.

Le nuove estensioni SIMD di Intel derivano dal progetto Larrabee, da cui hanno riciclato una buona parte del design (inclusa struttura degli opcode e parecchie istruzioni). Anno di nascita (di Larrabee): 2009 (l'annuncio di Intel).
Morto Larrabee, l'anno dopo Intel annuncia Knights Ferry, orientato al GPGPU computing, che è largamente basato sull'ISA Larrabee, come dicevo. Anno: 2010.
L'anno dopo (2011) tocca a Knights Corner, e al suo set di istruzioni che è molto simile alle AVX-512.
Infine il 2013 è l'anno di Knights Landing e dell'annuncio ufficiale delle AVX-512 (si chiameranno così le estensioni SIMD a 512 bit di Intel, per tutti i suoi processori).

Queste estensioni, quindi, sono arrivate ben 7 anni fa (quando ero appena arrivato alla Intel. :D E ho lavorato nonché testato sistemi Knights Corner e Knights Landing, visto che è ciò di cui mi occupavo principalmente).

Vogliamo vedere quando sono arrivate le altre istruzioni SIMD? Intanto ARMv8 è stato annunciato nel 2011, e non aveva nessuna SVE, ma Neon (della precedente ISA ARM a 32 bit) migliorato.
Quindi non esattamente lo stesso Neon, ma un'altra versione --> welcome, fragmentation!
SVE è stata annunciata nel 2016 e finalizzata un paio d'anni dopo (se non ricordo male). Inoltre non mi pare che ci siano attualmente processori che la implementino (forse sarà Apple la prima, coi prossimi "Apple Silicon").
SVE2 sono state annunciate lo scorso anno (2019) e dovrebbero essere già finalizzate. Vedremo quando qualcuno le implementerà.

Comunque, long story short, le AVX-512 hanno avuto un parto molto travagliato e sono estensioni abbastanza vecchie (confrontandole con ARM, ARMv8 era stata annunciata da appena due anni, e non aveva nulla del genere), mentre le estensioni SIMD "VLA" sia di ARM sia di RISC-V (ma non ancora pronte) sono roba molto più recente.

Certo anche Intel avrebbe potuto fare lo stesso... col senno di poi.

Ma potrebbe ancora fare qualcosa: l'encoding per i possibili futuri 1024 bit è ancora libero. Basterebbe usare quello e le stesse, identiche, istruzioni/opcode potrebbero diventare di colpo "VLA".
Nella mia architettura, invece, ho preferito sacrificare il supporto alle istruzioni MMX (che ormai sono desuete) per abilitare le VLA, lasciando lo spazio anche per i 1024 fissi.

Questa discussione mi interessa pur non sapendo nulla di AVX-512, chissà perchè :D

Faccio solo notare che degli ultimi 3 link riportati, uno risale al 2014 e uno al 2017... un pò vecchiotti, direi archeologici visto che parliamo d'informatica.

Non è quello che ha detto in quel commento.

Ha ribadito, invece, la sua irrazionale (e sono parole sue) avversione alle unità FP e vettoriali, classificando come "benchmark" (tutto) il codice che le usa (in buona sostanza: sono tali benchmark che spingono a pompare tali unità).

Scusa, ma io ho interpretato la cosa in modo diverso leggendo il suo post a cui l'articolo fa riferimento:
https://www.realworldtech.com/forum/?threadid=193189&curpostid=193190
C'e' da notare che Torvalds è finlandese e quindi quello che dice quando "si scalda" va interpretato in termini di "management by perkele (https://www.youtube.com/watch?v=rxTKJgsxwpE)". :D



Le AVX-512 non frammentano, da questo punto di vista, perché esiste una sola estensione SIMD, ed è a 512 bit.

Lui, invece, preferisce implementazioni a 128 bit (che trova ottimale. Bontà sua..) e che VLA (perché non devi scrivere codice per estensioni a 128, 256, e 512 bit).


Non è che "preferisce" le implementazioni a 128bit, semplicemente se uno vuole un estensione SIMD "a lunghezza fissa" al momento i 128bit sono il compromesso migliore come efficienza dell'hardware complessivo della cpu.
Se si vuole andare oltre, l'approccio migliore al momento sembra invece essere un estensione VLA (un unica "interfaccia di programmazione" e massima libertà nel scegliere l'ampiezza effettivamente implementata in hardware).

Questa discussione mi interessa pur non sapendo nulla di AVX-512, chissà perchè :D
:)
Faccio solo notare che degli ultimi 3 link riportati, uno risale al 2014 e uno al 2017... un pò vecchiotti, direi archeologici visto che parliamo d'informatica.
Interessante osservazione: non c'avevo fatto caso. Grazie.
Scusa, ma io ho interpretato la cosa in modo diverso leggendo il suo post a cui l'articolo fa riferimento:
https://www.realworldtech.com/forum/?threadid=193189&curpostid=193190
C'e' da notare che Torvalds è finlandese e quindi quello che dice quando "si scalda" va interpretato in termini di "management by perkele (https://www.youtube.com/watch?v=rxTKJgsxwpE)". :D
Perdonami, ma del suo originale post ne abbiamo già ampiamente parlato (e ho esposto quasi tutte le mie critiche già al mio primo commento).
Poi sei arrivato con un link in cui dicevi che avesse precisato, e ho fatto notare che, invece, non ci fosse alcuna precisazione (a parte l'ammissione di essere irrazionale sull'argomento. Non che ci volesse molto a capirlo).
Adesso hai riportato nuovamente il link a primo messaggio.
Non è che "preferisce" le implementazioni a 128bit, semplicemente se uno vuole un estensione SIMD "a lunghezza fissa" al momento i 128bit sono il compromesso migliore come efficienza dell'hardware complessivo della cpu.
E invece non è affatto vero, perché dipende tutto da quello che devi farci.

A livello consumer ormai le estensioni a 256 bit cominciano a essere diffuse (il problema, al solito, è sempre stato il supporto, che all'inizio è inesistente e che richiede parecchio tempo per attecchire), e i suoi frutti li danno.

Torvalds ha scelto AMD come sua nuova piattaforma, che con Zen2/Ryzen3K offre ben 4 porte a 256 bit per l'esecuzione di codice SIMD, contro le sole 3 di Intel (anche se c'è da dire che Intel consente l'esecuzione di istruzioni/operazioni FMA, mentre AMD continua a spezzarle in due micro-op che esegue sequenzialmente).
Se si vuole andare oltre, l'approccio migliore al momento sembra invece essere un estensione VLA (un unica "interfaccia di programmazione" e massima libertà nel scegliere l'ampiezza effettivamente implementata in hardware).
Ma non sei tu, consumatore, a scegliere l'ampiezza dell'implementazione: lo fa per te il produttore di processori.

Vedrai che fra un po' arriveranno delle implementazioni a 512 bit delle SVE di ARM anche a livello consumer, perché rimanere ancora fermi agli attuali 128 bit non rende la piattaforma ARM competitiva.
Poi cosa farà Torvalds, si straccerà le vesti di nuovo?
Perché sarà evidente che si dovrà scendere col clock, perché gestire dati a 512 bit richiede parecchie risorse in campo, e queste consumano corrente e fanno aumentare le temperature: non si scappa. Vale adesso per Intel, e varrà in futuro anche per altre aziende che produrranno processori con implementazioni SIMD a 512 bit.

Vedrai che fra un po' arriveranno delle implementazioni a 512 bit delle SVE di ARM anche a livello consumer, perché rimanere ancora fermi agli attuali 128 bit non rende la piattaforma ARM competitiva.
.

Le SVE di ARM sono una cosa ancora "mitica". Che io sappia, le hanno solo i supercomputer di Fujitsu e se le tengono ben strette. Ancora non sono riuscito ad usarle realmente, ma sempre e solo in emulazione. Esistono processori in commmercio con le SVE?

Le SVE di ARM sono una cosa ancora "mitica". Che io sappia, le hanno solo i supercomputer di Fujitsu e se le tengono ben strette. Ancora non sono riuscito ad usarle realmente, ma sempre e solo in emulazione. Esistono processori in commmercio con le SVE?

Ed è giusto così. Perchè sprecare transistor per qualcosa che è di nicchia? I supercomputer Fujitsu ne hanno bisogno, lo smartphone di Pippo e il PC di Maria no.

Ed è giusto così. Perchè sprecare transistor per qualcosa che è di nicchia? I supercomputer Fujitsu ne hanno bisogno, lo smartphone di Pippo e il PC di Maria no.

Le istruzioni vettoriali sono usate in svariati ambiti. I supercomputer sono solo il campo in cui vengono sfruttate al massimo, sopratutto perché i codici sono scritti in un certo modo proprio per spremerle. Quindi se un processore vuole essere competitivo deve averle.

Le istruzioni vettoriali sono usate in svariati ambiti. I supercomputer sono solo il campo in cui vengono sfruttate al massimo, sopratutto perché i codici sono scritti in un certo modo proprio per spremerle. Quindi se un processore vuole essere competitivo deve averle.

E infatti nessuno si è mai lamentato delle AVX e AVX2. Torvalds dice un paio di cose molto precise

"And AVX512 has real downsides. I'd much rather see that transistor budget used on other things that are much more relevant. Even if it's still FP math (in the GPU, rather than AVX512). Or just give me more cores (with good single-thread performance)"

"I want my power limits to be reached with regular integer code, not with some AVX512 power virus that takes away top frequency (because people ended up using it for memcpy!) and takes away cores (because those useless garbage units take up space)."

"Stop with the special-case garbage, and make all the core common stuff that everybody cares about run as well as you humanly can."

E siamo nell'era del GPGPU, delle NPU, ecc... davvero abbiamo bisogno delle AVX512?

Intel ha un brutto atteggiamento, ovvero credono di sapere meglio di noi ciò di cui abbiamo bisogno. E ci vendono un pacchetto già prefabbricato, senza possibilità di scelta. Ovviamente quest'ultima frase è riferita a quanto invece avviene tra ARM e i produttori di SoC, i quali hanno un'incredibile libertà di scelta su cosa integrare e cosa no.

E infatti nessuno si è mai lamentato delle AVX e AVX2. Torvalds dice un paio di cose molto precise

"And AVX512 has real downsides. I'd much rather see that transistor budget used on other things that are much more relevant. Even if it's still FP math (in the GPU, rather than AVX512). Or just give me more cores (with good single-thread performance)"

"I want my power limits to be reached with regular integer code, not with some AVX512 power virus that takes away top frequency (because people ended up using it for memcpy!) and takes away cores (because those useless garbage units take up space)."

"Stop with the special-case garbage, and make all the core common stuff that everybody cares about run as well as you humanly can."

E siamo nell'era del GPGPU, delle NPU, ecc... davvero abbiamo bisogno delle AVX512?

Intel ha un brutto atteggiamento, ovvero credono di sapere meglio di noi ciò di cui abbiamo bisogno. E ci vendono un pacchetto già prefabbricato, senza possibilità di scelta. Ovviamente quest'ultima frase è riferita a quanto invece avviene tra ARM e i produttori di SoC, i quali hanno un'incredibile libertà di scelta su cosa integrare e cosa no.

Non è mica solo Intel ad avere istruzioni vettoriali eh. Se le implementa Intel è cattivona se lo fanno gli altri va tutto bene?


E siamo nell'era del GPGPU, delle NPU, ecc... davvero abbiamo bisogno delle AVX512?


Ma hai mai portato un codice su GPU? Se lo fai con CUDA è un bagno di sangue, sia il porting che il mantenimento. Devi sbudellare il codice, come minimo. Un pò meglio se usi OpenACC o le più recenti specifiche di OpenMP.

Perlomento con le istruzioni vettoriali spesso e volentieri fa tutto il compilatore.

Non è mica solo Intel ad avere istruzioni vettoriali eh. Se le implementa Intel è cattivona se lo fanno gli altri va tutto bene?


Ehm, mi pare di averlo scritto che il problema non SONO LE ISTRUZIONI VETTORIALI MA LE AVX-512!!!

Ma poi la questione è un'altra, ovvero che ci fanno le AVX-512 nel PC della sora Maria? Ok per il supercomputer dei laboratori Lawrence Livermore, ma la Maria non se ne fa niente. E potrebbe invece godere di più core, minori consumi, minor calore, ecc...


Ma hai mai portato un codice su GPU? Se lo fai con CUDA è un bagno di sangue, sia il porting che il mantenimento. Devi sbudellare il codice, come minimo. Un pò meglio se usi OpenACC o le più recenti specifiche di OpenMP.


Si può discutere sulle virtù o la mancanza di esse di CUDA, ma il risultato è spettacolare. Altro che AVX-512.


Perlomento con le istruzioni vettoriali spesso e volentieri fa tutto il compilatore.

Beh, se è per questo esistono pure librerie Python ( per esempio Numba ) che supportano automaticamente CUDA, per cui non hai bisogno di fare nulla.

Ehm, mi pare di averlo scritto che il problema non SONO LE ISTRUZIONI VETTORIALI MA LE AVX-512!!!


Se è per questo io mi riferivo alle SVE... Hai quotato un mio intervento dicendo che sono inutili e poi dici di riferirti alle AVX-512. Va bè.


Ma poi la questione è un'altra, ovvero che ci fanno le AVX-512 nel PC della sora Maria? Ok per il supercomputer dei laboratori Lawrence Livermore, ma la Maria non se ne fa niente. E potrebbe invece godere di più core, minori consumi, minor calore, ecc...



Semplicemente perché Intel non può prevedere la sora Maria cosa ci farà ( e neanche lei lo sa probabilmente). Quindi per semplificare mette tutto in tutti i processori.



Si può discutere sulle virtù o la mancanza di esse di CUDA, ma il risultato è spettacolare. Altro che AVX-512.



Se il codice si presta sicuramente. Andare su GPU richiede un parallelismo massivo che non tutti i codici hanno e magari le AVX sono più che sufficienti. Senza parlare della difficoltà di mantenimento di un codice su GPU e che devi avere ulteriore hardware, ovvero una GPU.



Beh, se è per questo esistono pure librerie Python ( per esempio Numba ) che supportano automaticamente CUDA, per cui non hai bisogno di fare nulla.

Ci sono vari modi certo, tutto dipende quanto controllo vuoi avere sul codice. Ogni soluzione comporta dei compromessi.

Le SVE di ARM sono una cosa ancora "mitica". Che io sappia, le hanno solo i supercomputer di Fujitsu e se le tengono ben strette. Ancora non sono riuscito ad usarle realmente, ma sempre e solo in emulazione. Esistono processori in commmercio con le SVE?
Processori desktop non credo ce ne siano. Nemmeno Apple, che è affamata di prestazioni, ha integrato queste estensioni (forse aspetta di passare direttamente alle SVE2).
Ed è giusto così. Perchè sprecare transistor per qualcosa che è di nicchia? I supercomputer Fujitsu ne hanno bisogno, lo smartphone di Pippo e il PC di Maria no.
Perché un'estensione SIMD non è di nicchia, e ne abbiamo già ampiamente discusso in questo stesso thread.
E infatti nessuno si è mai lamentato delle AVX e AVX2. Torvalds dice un paio di cose molto precise

"And AVX512 has real downsides. I'd much rather see that transistor budget used on other things that are much more relevant. Even if it's still FP math (in the GPU, rather than AVX512). Or just give me more cores (with good single-thread performance)"

"I want my power limits to be reached with regular integer code, not with some AVX512 power virus that takes away top frequency (because people ended up using it for memcpy!) and takes away cores (because those useless garbage units take up space)."

"Stop with the special-case garbage, and make all the core common stuff that everybody cares about run as well as you humanly can."

E siamo nell'era del GPGPU, delle NPU, ecc... davvero abbiamo bisogno delle AVX512?
Sì, e abbiamo già ampiamente parlato anche di questo: perché continui a ripetere a pappagallo le stesse cose? Soltanto per difendere il tuo mito, nonostante il colossale cumulo di sciocchezze che ha proferito?
Intel ha un brutto atteggiamento, ovvero credono di sapere meglio di noi ciò di cui abbiamo bisogno. E ci vendono un pacchetto già prefabbricato, senza possibilità di scelta.
Ma basta con questa retorica Stallmaniana della mancanza di libertà.

Se conosci un modo di far produrre chip personalizzati SENZA aumentare i costi di produzione (e quindi ridurre i guadagni) presentati alla porta di Intel (e di qualunque altro produttore di chip, perché i problemi sono esattamente gli stessi per tutti) e vedrai che ti ricopriranno d'oro.

Il prossimo Nobel per l'economia non te lo leva nessuno...
Ovviamente quest'ultima frase è riferita a quanto invece avviene tra ARM e i produttori di SoC, i quali hanno un'incredibile libertà di scelta su cosa integrare e cosa no.
Allora fai una cosa: bussa alla porta di Apple e chiedile di realizzare più varianti dello stesso core Apple Silicon. Tanto è un chip ARM, no? A tuo dire ci sarebbe molta più "libertà" da queste parti.

Fanne realizzare uno senza unità SIMD NEON (tanto c'è la GPU, no?), e magari uno che non ha nemmeno l'FPU (d'altra parte nemmeno questa serve a Torvalds). Integers do it better!

Anzi, inviagli pure direttamente la lista delle istruzioni che ti servono, perché non penso che userai tutte le circa 900 (NO-VE-CEN-TO) di AArch64: non vorrai mica sprecare del silicio per tutta quella roba inutile?

E' arrivata l'era dei chip su misura...
Ehm, mi pare di averlo scritto che il problema non SONO LE ISTRUZIONI VETTORIALI MA LE AVX-512!!!
Che... rullo di tamburi... SONO istruzioni vettoriali.
Ma poi la questione è un'altra, ovvero che ci fanno le AVX-512 nel PC della sora Maria? Ok per il supercomputer dei laboratori Lawrence Livermore, ma la Maria non se ne fa niente. E potrebbe invece godere di più core, minori consumi, minor calore, ecc...
E che ne sai tu se non vengano già usate dalla ssiuuura Maria? Anzi, se ha un portatile con Cannonlake, Icelake, o TigerLake, è sicuro che le starà già usando senza che nemmeno se ne accorga: misteri dell'informatica...
Si può discutere sulle virtù o la mancanza di esse di CUDA, ma il risultato è spettacolare. Altro che AVX-512.
Fai una cosa: sostituisci tutte le estensioni SIMD (tanto la tua tesi, da tempo, è che ci sono le GPU per quelle. Non riguarda soltanto le AVX-512) con CUDA, e poi vediamo di quanto caleranno le prestazioni. Perché quello succederà, come ho già ampiamente spiegato prima e che hai ignorato.
Beh, se è per questo esistono pure librerie Python ( per esempio Numba ) che supportano automaticamente CUDA, per cui non hai bisogno di fare nulla.
Magari fosse così: sarebbe una pacchia! Purtroppo non si può usare Python ovunque. E in ogni caso, anche se fosse possibile, ricadremmo in quello che ho scritto sopra (e anche avevo scritto anche prima).

Per il resto concordo con Unrue.