Intelin AVX-512-laajennokset (Advanced Vector eXtensions) ovat olleet varsinainen sotku jo vuosia; eri prosessoreiden tuki sen ominaisuuksille on vaihdellut sukupolvesta toiseen ja lopulta se on tiputettu kuluttajapuolelta kokonaan pois, vaikka prosessoreissa tiettävästi itse toiminnallisuus edelleen olisikin.
Intelin nykyisten kuluttajaprosessoreiden tuki AVX-512-laajennoksille on kytketty kokonaan pois käytöstä, koska E-ytimet eivät tue ominaisuutta lainkaan. Nyt yhtiö on julkaissut kolme uutta päivitystä x86-laajennoksiinsa, joiden päämääränä on muun muassa yhtenäistää P- ja E-ytimien laajennostuki samalle tasolle. Samassa yhteydessä heitetään käytännössä hyvästit AVX-512:lle, sillä siihen ei tulla lisäämään enää uusia ominaisuuksia.
Ensimmäinen uusista laajennoksista on Intel Advanced Performance Extensions eli APX. APX:n myötä Intel tulee kaksinkertaistamaan yleisrekistereiden (GPR, General Purpose Register) määrän, mikä mahdollistaa luonnollisesti aiempaa suuremman määrän arvoja tallennettuna rekistereihin. Se puolestaan vähentää tarvetta selvästi hitaammille load- ja store-funktioille ja sen myötä vähentää myös tehonkulutusta. APX-tuella käännetyssä koodissa voi olla yhtiön mukaan jopa 10 % vähemmän load ja 20 % vähemmän store-käskyjä, kuin perinteisessä. Ensimmäisiä APX-tuellisia prosessoreita odotetaan markkinoille 2024.
AVX-puolelle saadaan taakse jätetyn AVX-512:n korvaajaksi AVX10, joka saapuu markkinoille kahdessa vaiheessa. Ensin saapuu AVX10.1, jota tuetaan vain P-ytimiä sisältävissä Xeon-prosessoreissa. AVX10.1:tä kuvataankin lähinnä ensiaskeleeksi kohti AVX10.2:ta eli ”oikeaa AVX10:iä”, joka tulee olemaan tuettu sekä P- että E-ytimillä. Kummankin AVX10-version kohdalla tuki 512-bittisille luvuille on vapaaehtoista. AVX tulee myös selkeyttämään tukiviidakkoa selkeällä ”versionumeroinnilla”, jossa tietty versio tukee tiettyjä ominaisuuksia. AVX-512:n kohdalla pelkkä nimi ei kertonut vielä mitään, sillä eri prosessoreiden tukemat AVX-512-laajennokset vaihtelivat merkittävästi eri mallien välillä.
Lähteet: Intel, Overclocked3D
Mielenkiintoista siinä mielessä että Zen 4 tukee kai lähes kauttaaltaan avx 512:sta.
Puuttuuko tästä lauseesta sana ”on”?
>Ensimmäinen uusista laajennoksista Intel Advanced Performance Extensions eli APX
Kyllä. Jatkossa tällaiset palautelomakkeella
Niinkuin avx on uusi käskykanta. Tässä on kyse käskykannan laajentamisesta ja uusi lisää vaikka eex,efx,egx ja ehx rekisterit ja niitä ei sitten käytä, jos ei prosessori tue laajennuksia.
Käskyn saa trapilla kiinni ja voidaan emuloida, rekisteriä ei.
Mitäköhän hittoa nyt taas? Ei kukaan tee noin.
Ohjelmat käännetään uusiksi niin, että ne tukevat käskykantaa ja sitten niistä tehdään joko paketti, jossa on mukana koodi uudella käskykannalla ja vanhalla, yhteensopivalla tavalla. Tai sitten pelkästään uudella käskykannan tuella, jolloin sitä ei tueta vanhoilla prosessorilla.
Varsinkin prosessointia nopeuttavien käskykantojen emulointi on TYHMÄÄ ja mitään käskykohtaisia "trappeja" on ihan turha laittaa sinne hidastamaan ohjelmaa.
Tietokoneen arkkitehtuuri ja Kääntäjät -kurssien pitäisi vieläkin olla pakollisia, ettei tälläisia aivopieruja tule tulevaisuudessa.
Rekisteri on käskyn parametri ei itse käsky. Tämän takia ohjelmaa, joka käyttää olemattomia rekisterilaajennoksia, ei saa samalla tavalla kiinni kuin käskyjä joita ei tueta. Voi tietysti olla että löytyy jokin uusi keskeytys johon langoittaa tällainen uusi virhetilanne. On ohjelmistoja joiden on aina toimittava, vaikka joku saattaa laittaa niitä ajoon vanhallekin raudalle. Emulointi ei ole tehokasta, mutta jos sillä vältetään järjestelmän kaatuminen, niin se on parempi vaihtoehto siihen asti että Joku(tm) hoitaa joko ohjelmiston tai raudan kuntoon.
Voi tuplahuoh.
Joo, rekisteri on mahdollinen parametri operandille/käskylle. Konekielitason käskyt ovat alin taso virtaa, joka menee prosessorille. Sen takia mitään vatun langoituksia tai keskeytyksiä ei käytetä, kun ne ovat jo suoritushierarkiassa käyttöjärjestelmätasolla. Jos tulee käsky, jota ei voi suorittaa, prosessori menee virhetilateeseen.
Lisäksi, jos käskykanta nopeuttaa, niin emulointi on vammaisten hommaa. Siinä sitten suorituskyvyn pitäisi nousta, mutta se kyykkääkin kymmenesosaan, niin tästä hyödy yhtään mitään ja kohta saan varoituksen, kun sanon mielipiteeni ihmisistä, jotka näitä emuloi..
—
Kun olen pihalla kuin lumiukko, niin väännetään nyt rautalangasta. Olen kännykällä, niin vähän kevyemmin ja ilman linkkejä.
Kun tietokoneelle tehdään ohjelma, se käännetään ensin kääntäjällä konekieleksi ja sitten binääriksi. Joskus jopa samalla kierroksella.
Jotta ohjelma voi hyötyä uusista käskylaajennoksista, kääntäjän pitää tukea niitä ja tuottaa sopiva konekieliversio/binääri. Ne ei yhtäkkiä lataudu ohjelmaan, eikä niitä voi millään laajennoksella ottaa käyttöön. Ohjelma on kääännettävä uusiksi. Kääntämällä käskykantaa tukevalla kääntäjällä, saadaan käskykanta käyttöön.
Tähän väliin ei tule mitään emulointia, kun se binääri edelleen on alin taso, missä koodia suoritetaan. Jos haluaa emuloida, niin väliin pitää laittaa virtuaalikone ja sen aiheuttama ylimääräinen prosessointiaika on luokkaa 10x , kun puhutaan uudesta käskykannasta.
Ne sinua fiksummat kaverit laittaa vaan yhteen binääriin monta versiota koodista useille käskykannoille. Eikä edes tarvitse olla kovin fiksu, sivistä itseäsi lukemalla Wikipedia Applen Universal Binarystä. Sitten kun koodi vie joitakin megatavuja binäärimuodossa, ketään ei oikeasti välitä, vaikka olisi 5 eri versiota.
Sitten koodin alkuun ohjelmoidaan ihmeellinen if-lause , jossa suoritetaan se osa koodista, jossa on koneen tukemat käskykannat. Jos if-lause ei ole tuttu käsite, voit kysellä jossain ohjelmoinnin perusketjussa.
Rekistereistä ei prosessoreissa ole pulaa, niitä on satoja. PRF-pohjainen rekisterien uudelleennimeäminen on Intelillä ollut Pentium 4sta lähtien (tosin välissä core2ssa yms. ei ollut, mutta Sandy Bridgessä tuli takaisin)
Mutta oikea ongelma rekisterien kanssa on käskyjen enkoodaus. Käskykannassa näkyvät rekisterit vaativat käskystä bittejä joilla valitaan se rekisteri, ja olemassaolevat käskykannat optimoidaan aina siten, että käskybitit käytetään tehokkaasti sille arkkitehtuurilliselle rekisterimäärälle mikä niissä on. Jos halutaan lisätä lisää rekisterejä laittamatta koko käskyenkoodausta täysin uudiksi, lisärekisterit pitää enkoodata käskyihin epätehokkaasti, tehden käskyjen enkoodaukseta rumemman ja vähemmän tehokkaan.
Esim x64-64n REX-prefix millä rekisterimäärä kasvatettiin 8=>16 on melkoista purkkaa.
Virtuaalikone ei aiheuta mitään tuollaista "luokkaa 10x" olevaa prosessoriaikaa.
Mikäli käskyjä tulkataan tulkkausloopissa, hidastus on paljon suurempi, lähempänä luokkaa 100x kuin 10x.
Mutta koodin voi myös binäärikäänrää, ja mikäli käskykannat ovat ominaisuuksiltaan riittävän samanlaiset (että platform jolle binäärikäännetään tukee käytännössä kaikkia toisen datatyyppejä ja muistin konsistenttiussäännöt ovat yhteensopivia jne) , sen binäärikäännäksen hidastava vaikutus on tyypillisesti selvästi alle 2x.
Esim. Apple ajaa oikein vauhdikkaasti x86-koodia ARMeillaan kun vaan laajensi niitä toimintatilalla jossa on x86-yhteensopivat muistin konsistenssiussäännöt ja virtuaalimuistimoodit.
… paitsi intel ja AMD, jotka tekevät noin mikrokoodilla monille monimutkaisemmille käskyille
Tämä toteutus vaan ei näy siinä käskykannassa, ei näy edes käyttöjärjestelmälle.
Valitettavasti vaan melkein kaikkien yliopistojen tietokoneen arkkitehtuuri-kurssi on todella pahasti jumittunut 1980-luvun lopulle asenteella "RISC on parasta mitä tietokoneille on koskaan tapahtunut" ja niistä saa melko vajaan kuvan siitä, miten oikeasti käytössä olevat prosessorit todellisuudessa toimivat.
Onhan se hyvin hyödyllinen kurssi, mutta ei pitäisi kuvitella, että se 1980-luvun hi-tech mitä siellä oppii pätee kaikkiin nykyaikaisiin prosessoreihin.