Sen kummemmin asiaan perehtymättä, tuo AVX on yleisesti liukulukulaskentaa, joka on verrattain raskasta, mutta tehokasta.
Markkinoille hyötysovelluksiin tuota ei varmaan hirveästi yritetä survoa juurikin sen takia, että ko. operointi vaatii tehoa melko paljon ja tukea ei välttämättä löydy työkoneista.
Ensinnäkin, AVX2 tukee myös 256-bittisillä kokonaislukuvektoreilla laskemista; Vaikka softa ei tekisi mitään liukuluvuilla, se voi hyötyä AVX2sta huomattavasti.
Toisekseen, ajattelet asiaa täysin väärinpäin.
Ohjelmakoodin pitää toteuttaa joko algoritmi, jotta ohjelma tekee sen mitä sen halutaan tekevän.
Ja se algoritmi pitää toteuttaa laskien jollain lukutyypillä, jotta tarkkuus on riittävä.
Jos lasketaan jotain järeätä fysiikkasimulaatiota, pitää käyttää kaksoistarkkuuden(64b = 52b+11b+S) liukulukuja(double) että tarkkuus riittää. Jos lasketaan pelin 3d-geometriaa, tai käsitellään ääntä tai kuvaa, yksöistarkkuuden liukuluku (32b = 23b+8b+S) yleensä riittää. Ja kuvankäsittelyyn voi usein riittää jopa puolen tarkkuuden liukuluvut(16b = 10b+5b+S). Jos taas käsitellään indeksejä ja osoitteita, pitää käyttää kokonaislukua jne.
x87, AVX ja SSE on sitten
työkaluja joita käyttäen saadaan laskettua se, mitä ohjelman
täytyy laskea. Ei siten että "jos AVX otetaan käyttöön niin ohjelman laskentamäärä kasvaa".
Jos ohjelman pitää suorittaa 100 miljardia liukulukuoperaatiota siihen itse laskentaan kuluu joka tapauksessa joku määrä sähköä riippumatta siitä, lasketaanko se x87lla(yksi operaatio/käsky), SSEllä(4 operaatiota/käsky, AVXllä(8 operaatiota/käsky) vai AVX-512lla (16 operaatiota/käsky.
Leveämmillä vektoreilla se laskenta vaan saadaan tehtyä nopeammin. Mutta, jotta niitä voidaan käyttää, laskennan pitää tapahtua (lähde)koodissa tarpeeksi "järjestelmälliselllä" tavalla. Jos koodi laskee asioita liian "sekaisessa järjestyksessä", sitä ei voida vektoroida, tai kääntäjä ei sitä osaa vektoroida, eikä näistä hyödytä.
Mutta, mutta leveämpi vektorikäskykanta on käytössä, sitä
vähemmän sitä sähköä kuluu kokonaisuudessaan samaan määrään laskentaa, koska käskyjen hakemiseen, dekoodaamiseen ja niiden skedulointiin ja kirjanpitoon prosessorin liukuhihnalla kuluu tällöin vähemmän sähköä. Leveämmän vektorit ovat siis
energiatehokkaampia kuin ei vektoreita tai kapeammat vektorit.
Ja tätä leveiden vektorien energiansäästöä vielä lisää se, että kun leveämmillä vektoreilla suorituskyky on parempi, samaan suorituskykyyn pääsemiseksi voidaan prosessori kellottaa matalammalle kellotaajuudelle ja ajaa sitä pienemällä jännitteellä. (tai kelloa ja jännitettä voidaan pudottaa hiukan, ja saada sekä skaalariversiota tai kapeaa vektoria parempi suorituskyky ETTÄ selvästi pienempi energiankulutus)
Kovassa laskennassahan AVX 512 on ilmeisesti melko ylivoimainen, mutta taitaa olla kovin käyttö jossain tieteellisen laskennan puolella toistaiseksi.
Melkein mikä tahansa kuvan- tai videonkäsittely tai pelien 3d-kordinaattien pyörittely olisi juuri sellaista laskentaa, missä AVX-512sta saataisiin todella suuri hyöty,
jos sitä käytettäisiin.
Mutta
tällä hetkellä vielä ei AVX-512sta käytetä, koska markkinoilla
ei ole yhtään AVX-512aa tukevia
kuluttajaprosessoreita. Ei kun siis, on tasan yksi malli, 2-ytiminen halpa cannon lake-i3-8121U joka käy melko matalilla kelloilla ja jota ei valmisteta kovin suuria määriä.
Ja edes AVXää ei kovin monessa pelissä hyödynnetä, koska pelien halutaan toimivan myös vanhemmilla prosessoreilla, jotka eivät AVXää tue (nehalem, phenom), ja olisi ylimääräistä vaivaa lisätä koodiin erilliset polut vanhoille ja uusille prosessoreille, ja kun pelin optimointien päätarkoitus on kuitenkin että peli pyörisi siedettävästi mahdollisimman vanhalla ja hitaalla raudalla, ja pelin optimoiminen käyttämään uusia käskykantoja ei tätä tavoitetta tue. Ja vaikka esim. zen1 ja bulldozer tukevat AVXää, ne eivät hyödy siitä, joten jos peliä on niillä rajoilla että pyöriikö se bulldozerilla siedettävästi vai ei, ja peliä halutaan optimoida jotta se toimisi bulldozerilla siedettävästi, AVX ei tätä ongelmaa ratkaise, vaan pelistä pitää optimoida aivan muita juttuja.