Intelin Alder Lake -arkkitehtuuri väitettyjen vuotojen kohteena

[Kaotik]

Kaotik kirjoitti uutisen/artikkelin:
Intelin 11. sukupolven Core -työpöytäprosessoreiden toimitukset eivät ole ehtineet vielä edes alkaa, mutta huhut ja vuodot seuraavan sukupolven Alder Lake -prosessoreiden ympärillä käyvät jo kuumina. Tällä kertaa vuorossa on VideoCardzin käsiinsä saamia väitettyjä vuotodioja.

VideoCardzin käsiinsä saamassa diassa käydään läpi yleisesti Alder Lake -arkkitehtuurin uudistuksia keskittymättä mihinkään tiettyyn verisoon, kuten S tai P. Dian mukaan arkkitehtuuri tarjoaisi uusien Golden Cove -ydinten myötä parhaimmillaan 20 % parempaa yhden säikeen suorituskykyä, mutta diassa ei mainita onko verrokkina työpöytäpuolen Cypress Covet vai mobiilista tutut, sukupolvea uudemmat Willow Covet. Prosessorit valmistetaan parannetulla 10 nanometrin SuperFin-prosessilla.

Monisäikeisen suorituskyvyn kerrotaan paranevan puolestaan parhaimmillaan jopa kaksinkertaiseksi uusien Gracemont-ydinten ja rautaohjatun skeduloinnin ansiosta. Prosessoreissa on enimmillään kahdeksan Golden Cove- ja kahdeksan Gracemont-ydintä. Koska vain Golden Cove -ytimet tukevat Hyper-threading-SMT-teknologiaa, voi prosessorin yhteensä 16 ydintä suorittaa samanaikaisesti maksimissaan 24 säiettä.

Muita uudistuksia Alder Lakessa on tuki uusimpien sukupolvien väylille, eli tässä tapauksessa PCI Express 4.0- ja 5.0 -standardeille, Thunderbolt 4:lle sekä Wi-Fi 6E:lle. Muistipuolella tuettuina ovat DDR4-, DDR5-, LPDDR4 ja LPDDR5. Näytönohjaimen virkaa toimittaa Xe-LP-arkkitehtuuriin perustuva integroitu grafiikkaohjain. Thunderbolt -tuki on ainakin työpöytäpuolella tuki erilliselle ohjainpiirille ja Wi-Fi-tuki on integroitu 600-sarjan piirisarjaan.



On mahdollista ja jopa todennäköistä, että LPDDR-muistituet on rajoitettu mobiilivariantteihin, sillä toisessa Alder Lake-S -malleja spesifisti käsittelevässä diassa mainitaan prosessorille DDR4-3200- ja DDR5-4800 -tuet. Lisäksi prosessorissa mainitaan olevan 16 PCI Express 5.0 -linjaa, neljä PCI Express 4.0 -linjaa ja kahdeksan DMI Gen4 -linjaa (PCIe 4).

600-sarjan piirisarjoissa kerrotaan puolestaan olevan sekä PCIe 3.0- että 4.0 -linjoja, SATA 3.0 -väyliä ja jo edellä mainittu intgroitu Wi-Fi 6E -ohjain. Thunderbolt 4 -tuki toteutetaan erillisellä piirisarjaan yhdistetyllä ohjainpiirillä. USB-puolella on tuettuna tuntematon määrä USB3-väyliä 5, 10 ja 20 Gbps:n nopeudella. Piirisarja tukee myös Optane Memory H20 -välimuisteja ja siitä löytyy Intelin integroitu verkko-ohjain.

Lähde: VideoCardz

Linkki alkuperäiseen juttuun

 

[aleksejjj]

"Monisäikeisen suorituskyvyn kerrotaan paranevan puolestaan parhaimmillaan jopa kaksinkertaiseksi uusien Gracemont-ydinten ja rautaohjatun skeduloinnin ansiosta."

Kiinnostaisi kyllä tietää, että miten Intel on saanut noista Gracemont-ytimistä puristettua kaksinkertaisen suorituskykyedun irti? Ja mikäli vuoto vain pitää paikkaansa, joudutaan varmaan odottelemaan 13 sukupolven Core-suorittimia että saadaan i9-prosessoriin 10 ydintä tai enemmän.

 

[pomk]

Ainakin on suorituskykyarviot sopivan realistiset, kun suorituskyvyn arvioidaan laskevan ainakin 80%. "Up to 20% performance"

 

[VmH]

"Monisäikeisen suorituskyvyn kerrotaan paranevan puolestaan parhaimmillaan jopa kaksinkertaiseksi uusien Gracemont-ydinten ja rautaohjatun skeduloinnin ansiosta."

Kiinnostaisi kyllä tietää, että miten Intel on saanut noista Gracemont-ytimistä puristettua kaksinkertaisen suorituskykyedun irti? Ja mikäli vuoto vain pitää paikkaansa, joudutaan varmaan odottelemaan 13 sukupolven Core-suorittimia että saadaan i9-prosessoriin 10 ydintä tai enemmän.

Helposti kun koko arkkitehtuuri pistetty uusiksi ja siinä on otettu huomioon menneiden arkkitehtuurien heikkoudet, joissa AMD vie Inteliä aika pitkälti kuin pässiä narussa, kuten juuri multi-threadingissa. Voisi siis olettaa että intelin alder lakeissa on keskinmäärin enemmän ytimiä vrt. esim. tähän viimeisimpään intelin 8-ytimiseen lippulaiva -suorittimeen ja tehonkulutuskin varmaan pienenee merkittävästi.

Ei ole siis sinänsä iso saavutus jos monisäikeistyvyydessä päästään vihdoinkin oletetulle tasolle, kun muistiohjainkin uudistuu DDR5:sta tukevaksi.

 

[moukula]

"20% parempi single thread suorituskyky" noin muotoiltuna ei tarkoita että se tulisi per kellojakso (IPC) saatikka että samalla tehonkulutuksella. Mikäli verrokkina sattuisi olemaan edellisen sukupolven mobiiliprosessori, niin helppohan tuo 20% on parantaa kun laitetaan vaan tuplasti watteja ja megahertsejä.

 

[pomk]

"Monisäikeisen suorituskyvyn kerrotaan paranevan puolestaan parhaimmillaan jopa kaksinkertaiseksi uusien Gracemont-ydinten ja rautaohjatun skeduloinnin ansiosta."

Kiinnostaisi kyllä tietää, että miten Intel on saanut noista Gracemont-ytimistä puristettua kaksinkertaisen suorituskykyedun irti? Ja mikäli vuoto vain pitää paikkaansa, joudutaan varmaan odottelemaan 13 sukupolven Core-suorittimia että saadaan i9-prosessoriin 10 ydintä tai enemmän.

Jos vaikka verrataan 4 ytimiseen tigerlakeen, niin 8+8 ytimisellä alderlakella saa varmaan ihan aidosti sen 100% nopeamman monisäikeisen suorituskyvyn, ehkä jopa samalla sähkönkulutuksella. Vertailukohtaa ei ole mainittu, niin ei ton perusteella voi sanoa oikein mitään.

 

[hkultala]

Jos vaikka verrataan 4 ytimiseen tigerlakeen, niin 8+8 ytimisellä alderlakella saa varmaan ihan aidosti sen 100% nopeamman monisäikeisen suorituskyvyn, ehkä jopa samalla sähkönkulutuksella. Vertailukohtaa ei ole mainittu, niin ei ton perusteella voi sanoa oikein mitään.

.. ja vain workloadeilla, joissa AVX-512sta ei käytetä mihinkään merkittävissä määrin.

Intel ajaa tässä vähän kaksilla rattailla, kun samalla mainostaa myös suuria yhden säikeen suorituskykyparannuksia tehoytimille, mutta tilassa jossa nämä tämä "kaksinkertainen" monen säikeen suorituskyky on mahdollista suorittaa, AVX-512 onkin kytkettynä pois päältä, suorituskyky joillain uusilla hyvin optimoiduilla softilla jopa huonompi.

 

[egaD]

Aika epäluuloista porukkaa kommenteissa. Mun mielestä noi performanssiarviot eivät kuulosta lainkaan mahdottomilta/ylimitotetuilta. Jos AMD faneja tutisuttaa niin pitää muistaa että alder lake tulee zen3 refresh/zen4 vastaan ja AMD:lla on hyvä sauma pitää valtikka viimeistään zen4 myötä. Aika näyttää.

 

[moukula]

Pessimisti ei pety. Kun nuita valmistajien hypedioja tutkii niin pitää olla tarkkana sanamuotojen kanssa. Mihin on vertailtu, mitä oikeasti sanottiin ja mitä jätettiin sanomatta.

 

[Raivo]

Aika epäluuloista porukkaa kommenteissa. Mun mielestä noi performanssiarviot eivät kuulosta lainkaan mahdottomilta/ylimitotetuilta. Jos AMD faneja tutisuttaa niin pitää muistaa että alder lake tulee zen3 refresh/zen4 vastaan ja AMD:lla on hyvä sauma pitää valtikka viimeistään zen4 myötä. Aika näyttää.

Ei ketään varmaan 'tutisuta'. Realismi on kaunis asia ja hkultalan kommentti tiivistää asian.

 

[pomk]

Aika epäluuloista porukkaa kommenteissa. Mun mielestä noi performanssiarviot eivät kuulosta lainkaan mahdottomilta/ylimitotetuilta. Jos AMD faneja tutisuttaa niin pitää muistaa että alder lake tulee zen3 refresh/zen4 vastaan ja AMD:lla on hyvä sauma pitää valtikka viimeistään zen4 myötä. Aika näyttää.

Ei tutisuta yhtään, intelillä vaan on tapana perseillä vertailujensa kanssa niin paljon kun vaan ikinä pystyy ja olisi outoa jos muuttaisivat yllättäen tapansa. Tuon takia näitä lukuja on hauska miettiä, etenkin kun vuodosta puuttuu vertailukohdat. Se on varmaa että ei noi luvut ole ainakaan parhaaseen mahdolliseen intelin verrokkiin nähden missään noista prosentteina ilmoitetuista parannuksista.

 

[moukula]

Vähän luulen että 20% suorituskykyparannus yhdeen säikeen kuormissa ei toteudu ainakaan 11900K:ta vastaan.

 

[k1nggg]

Vähän luulen että 20% suorituskykyparannus yhdeen säikeen kuormissa ei toteudu ainakaan 11900K:ta vastaan.

Riippuu mille kellotaajuuksille saavat nämä viritettyä, mobiili tiger-laket menevät jo sen 5 GHz ja tässä pitäisi olla vielä olla yhden pykälän hiotumpi valmistusprosessi niihin verrattuna mikä lupaa ihan hyvää.

 

[moukula]

Mikäli tuo 11900K boostailee 5GHz:iin, ja mikäli oletetaan vaikka kohtuullinen 5% IPC-parannus vrt. Rocket Lake, niin se tarkoittaisi että näiden pitäisi boostailla 5,7:aan asti saavuttaakseen tuon 20% edun. Mikäli IPC ei ole parantunut niin pitäisi mennä 6GHz. Kuulostaa vähän epärealistiselta.

 

[hkultala]

Vähän luulen että 20% suorituskykyparannus yhdeen säikeen kuormissa ei toteudu ainakaan 11900K:ta vastaan.

Kyllä se _joissain softissa_ voi toteutua, mutta tosiaan joissain mennään myös takapakkia.

Jos esim. turbokello nousee 5.3 => 5.5 GHz niin siitä tulee joku 3.5% lisää suorituskykyä. Tällöin tämän lisäksi tarvitaan vielä n. 16% parempi IPC että saavcutetaan tuo 20%

Tästä 16%sta joku n. 4% voi olla ytimen yleisistä pikkuparannuksia, ja 12% kasvaneista välimuisteista (L2-kakut 2.5-kertaa suuremmat, L3-kakkua 1.875 kertaa enemmän),

Läheskään kaikki softat ei varmaan hyödy 12% niistä kasvaneista välimuisteista, eikä keskimääärinen parannus ehkä ole ihan niin paljoa, mutta löytynee merkittävä määrä, joka hyötyy. Erityisesti olettaisien pelien hyötyvän tästä kakkujen kasvamisesta eniten.

Mutta AVX-512sta tukevat tosiaan ottaa sitten takapakkia jos pikkuytimet pidetään enabloituna.

 

[Griffin]

Jospa saataisiin käyttikset pikkuhiljaa tajuamaan, että on erilaisia ytimiä. Ohjelmiin vain pitää rakentaa joku tapa pyytää käyttöön tietynlaisia ytimiä (Jos ei jo ole). Eli jos ohjelma ilmoittaa tarvitsevansa AVX2:sta, niin käyttis voisi ajaa sitä vain noilla isoilla ytimillä..
----------------
Mitä muutoin tulee suorituskykyyn, niin valmistajien hehkutuksille ei kannata antaa juuri mitään arvoa. Noiden suorituskyvyn tietää vasta sitten, kun useampi iso, kolmas osapuoli on ajanut noilla kattavia testejä.

Jokos nuo on ylihuomenna lähi K-kaupassa muropakettien vieressä myynnissä vai miksi noista nyt ollaan niin innoissaan?

Itse odottelen prossua, johon olisi integroitu HBM: tyyppistä ratkaisua joku 16 Gigaa.. Kumman hitaasti edistyy. Lisämuistille voisi sitten olla vaikka pari DDR5 kanavaa.. Tai edes 8 gigaa, se kuitenkin riittää yleensä läppärissä miltei kaikkeen, mitä teen.

 

[pomk]

Kyllä se _joissain softissa_ voi toteutua, mutta tosiaan joissain mennään myös takapakkia.

Jos esim. turbokello nousee 5.3 => 5.5 GHz niin siitä tulee joku 3.5% lisää suorituskykyä. Tällöin tämän lisäksi tarvitaan vielä n. 16% parempi IPC että saavcutetaan tuo 20%

Tästä 16%sta joku n. 4% voi olla ytimen yleisistä pikkuparannuksia, ja 12% kasvaneista välimuisteista (L2-kakut 2.5-kertaa suuremmat, L3-kakkua 1.875 kertaa enemmän),

Läheskään kaikki softat ei varman hyödy 12% niistä kasvaneista välimuisteista, eikä keskimääärinen parannus ehkä ole ihan niin paljoa, mutta löytynee merkittävä määrä, joka hyötyy. Erityisesti olettaisien pelien hyötyvän tästä kakkujen kasvamisesta eniten.

Mutta AVX-512sta tukevat tosiaan ottaa sitten takapakkia jos pikkuytimet pidetään enabloituna.

Myös jotkut puhtaasti muistikaistarajotteiset softat voi olla tuon 20% nopeampia, koska samalla siirrytään DDR5 muisteihin.

 

[hese_e]

Kyllä se _joissain softissa_ voi toteutua, mutta tosiaan joissain mennään myös takapakkia.

Jos esim. turbokello nousee 5.3 => 5.5 GHz niin siitä tulee joku 3.5% lisää suorituskykyä. Tällöin tämän lisäksi tarvitaan vielä n. 16% parempi IPC että saavcutetaan tuo 20%

Tästä 16%sta joku n. 4% voi olla ytimen yleisistä pikkuparannuksia, ja 12% kasvaneista välimuisteista (L2-kakut 2.5-kertaa suuremmat, L3-kakkua 1.875 kertaa enemmän),

Käsittääkseni rocket laken kakkuja leikattiin aika tavalla, jotta se saatiin 14nm prosesille siedettävän kokoisena. Joten en yhtään ihmettelisi, että jostain löytyisi softa joka pyörii sen up-to 20% paremmin, mitä 11000 sarjalla, kun data mahtuukin kokonaan välimuistiin.

Ihan samalla tavalla 11000 sarja saavuttaa sen 19% paremman ipc:n, mutta vain tietyissä skenaarioissa. Alustavien arvostelujen valossa käytännön tehoero ei ole niin iso.

Imho. Markkinointislidet kannattaa aina nauttia hyvin suolattuna, jos vertailukohtaa ei ole määritelty tai on tuo klassinen up-to maininta. Markkinointi - selkosuomella se on aina ollut parhaan mahdollisen skenaarion lopputulos. Ladakin kulkee up-to 250km/h tarpeeksi jyrkässä alamäessä.

 

[hkultala]

Myös jotkut puhtaasti muistikaistarajotteiset softat voi olla tuon 20% nopeampia, koska samalla siirrytään DDR5 muisteihin.

Tosin muistikaista tulee äärimmäisen harvoin vastaan yhdellä säikeellä. Useammin yhden säikeen suorituskyky vaan kärsii kavaneista viiveistä.

 

[pomk]

Tosin muistikaista tulee äärimmäisen harvoin vastaan yhdellä säikeellä. Useammin yhden säikeen suorituskyky vaan kärsii kavaneista viiveistä.

Aivan, monisäikeisten softien kanssa tilanne on sit parempi.
Joku tarkoitushakuinen avx-512 testi yhdellä muistikammalla voisi tuohon ehkä kyetä, pitäisi tarkemmin lukea vähän datasheettiä.

 

[eternality]

Luulisi olevan vähän ennenaikaista näihin lykätä pcie 5.0, kun nelostakaan ei kuluttajalaitteissa tue juuri mikään... Mutta eipä siitä kai haittaakaan ole. Nuo suorituskykylupaukset on kyllä yhtä tyhjän kanssa kun ei kerrota vertailukohtaa, ei olisi eka kerta kun intel vertaa johonkin useamman sukupolven vanhaan malliin.

 

[prc]

Intel ajaa tässä vähän kaksilla rattailla, kun samalla mainostaa myös suuria yhden säikeen suorituskykyparannuksia tehoytimille, mutta tilassa jossa nämä tämä "kaksinkertainen" monen säikeen suorituskyky on mahdollista suorittaa, AVX-512 onkin kytkettynä pois päältä, suorituskyky joillain uusilla hyvin optimoiduilla softilla jopa huonompi.

Valtaosa perus läppärin käyttäjistä ei tuosta AVX-512:sta hyödy oikeen yhtikäsmitään. Eiköhän tuo ole Intelillä mietitty sen suhteen, että ne jotka sitten oikeasti AVX-512:sta kaipaa ostaa laitteen erilaisella prossulla. Perusläppäriin hyvällä akkukestolla nuo liene on ihan ok kiviä.

En sano pahalla, mutta mulla on jotenkin sellainen kutina, että käytät / tarvitset AVX-512:sta kovasti ja on nyt sellainen kokemusharha/filterbubble sen "välttämättömyydestä" kun tuot sitä kovin usein esille. Eikä siinä se on ihan normaalia jos esim työkseen pulaa ongelmien kanssa jotka kannatta implementoida AVX-512:sta.

Tulee mieleen kun oli jossain CPU ketjussa liittyen 360hz näyttöihin ja kuinka yleistä se on.. Yhtenä "väittelijänä" oli joku kilpapelaaja jonka kaverit on kilpapelaajia niin se näyttää yleisemmältä tarpeelta kun on.

Itsellä taas on toki toiseen suuntaan oleva kokemusharha kun täällä kirjoitellaan geneerista weppi tunkkia ja mitä liene datan muunnosajoja melko geneerisesti.. jos käytetyt kirjastot / vm:t / x SSE/AVX/himmeliä tukee niin kiva, mutta ei näitä käsin aleta optimoimaan tietyille käskylaajennokksille ollenkaan. Eria asia sitten kannattaisiko, mutta siihen ei aikaa/rahaa anneta niin se sitten siitä.

 

[hkultala]

Valtaosa perus läppärin käyttäjistä ei tuosta AVX-512:sta hyödy oikeen yhtikäsmitään. Eiköhän tuo ole Intelillä mietitty sen suhteen, että ne jotka sitten oikeasti AVX-512:sta kaipaa ostaa laitteen erilaisella prossulla. Perusläppäriin hyvällä akkukestolla nuo liene on ihan ok kiviä.

En sano pahalla, mutta mulla on jotenkin sellainen kutina, että käytät / tarvitset AVX-512:sta kovasti ja on nyt sellainen kokemusharha/filterbubble sen "välttämättömyydestä" kun tuot sitä kovin usein esille. Eikä siinä se on ihan normaalia jos esim työkseen pulaa ongelmien kanssa jotka kannatta implementoida AVX-512:sta.

Ei tässä ole kyse "kokemusharhasta" vaan siitä että mietin asioita pitkällä tähtäimellä ja MAHDOLLISEN/POTENTIAALISEN suorituskyvyn näkökulmasta, enkä siitä näkökulmasta miten JUURI TÄLLÄ HETKELLÄ eniten käytössä olevat softat pyörii.


Eli, itse en käytä AVX-512aa ollenkaan, mutta suunnittelen työkseni erikoistuneita prosessoreita signaalinkäsittelyjuttuihin, ja niissä (järeä) SIMD on aivan elinehto järkevään suorituskykyyn ja hyvään energiatehokkuuteen.

Olen suunnitellut prosessoreita joissa on vielä AVX-512aakin leveämpi SIMD-datapolku. (toki kellot paljon pienempiä ja rinnakkaisten laskentayksiköiden määrät paljon pienempiä, kun kuitenkin kyse hyvin pienistä vähävirtaisista ytimistä)

Kun halutaan oikeasti sitä suorituskyvyn kannata parasta mahdollista lopputulosta numeronmurskaukseen, ja ollaan valmiita näkemään se vaiva sen käyttämisestä, järeä SIMD on aivan ehdoton.

PC-puolella vaan ongelma on se, että softa laahaa vuosia jäljessä, peleihin alkaa vasta nyt tulla optimointeja edes AVXlle, ja yhteensopivuussyyt estää kätevästi ottamasta uusia käskykantoja käyttöön.

Paljon suorituskykyä tarvitsevia workloadeja joissa AVX-512lla ei tee mitään on esim joku selaimen javascript-tulkki, tai kääntäjä, jolla käännetään koodia, tai joku palvelinsofta joka palvelee todella suurta määrää käyttäjiä. Tai sitten tosiaan tuollaiset massiivisten XMLien parsetukset tms.

Muuten suuri osa paljon suorituskykyä tarvitsevasta koodista on kuitenkin jossain määrin signaalinkäsittelytyylistä multimediakoodia, jossa kyllä löytyisi leveälle ja ominaisuusrikkaalle SIMD-käskykannalle vähintään paikoitellen käyttöä.

Eli ongelma on se, että kun mahdollinen tulevaisuuden kapasiteetti ja hyöty tämän hetken softilla on ihan eri tasolla, niin tavallinen pulliainen tuijottaa vaan niitä tämän hetken benchmarkkeja vanhoilla softilla, minä taas ajattelen potentiaalia optimoiduilla softilla (sekä sitä, koska ne optimoinnit niihin softiin viimein saataisiin, niitä optimointeja ei myöskään tule suuressa mittakaavassa ennen kuin rauta yleistyy, muna vs kana-ongelma)

Itsellä taas on toki toiseen suuntaan oleva kokemusharha kun täällä kirjoitellaan geneerista weppi tunkkia ja mitä liene datan muunnosajoja melko geneerisesti.. jos käytetyt kirjastot / vm:t / x SSE/AVX/himmeliä tukee niin kiva, mutta ei näitä käsin aleta optimoimaan tietyille käskylaajennokksille ollenkaan. Eria asia sitten kannattaisiko, mutta siihen ei aikaa/rahaa anneta niin se sitten siitä.

AVX-512 rikkaampien ominaisuuksiensa (mm. scatter) takia nimeomaan mahdollistaa sen, että kääntäjän on teoriassa helpompi automaattisesti (jos sille vaan annetaan lupa) vektoroida se koodi, että koodarin ei tarvitse tehdä mitään että ne SIMD-käskyt tulee joissain tilanteissa käyttöön

Tässä tulee kuitenkin ongelmaksi yhteensopivuus; Normaalit softankehitysmekanismit eivät tue sitä, että kääntäjä voisi helposti ja automaattisesti tehdä koodista monta eri versiota eri käskykantalaajennoksille ja ajonaikaisesti valittaisiin oikea, vaan koodaaja joutuu näkemään huomattavasti ylimääräistä vaivaa jos haluaa koodista monta eri polkua eri käskykantalaajennoksille. Tämän takia kääntäjälle tyypillisesti vaan sanotaan että "targetoi geneeristä x86-64sta" (eli SIMDn osalta joku SSE2) tai sitten "saat käyttää AVXää", mutta käytännössä mitään binäärimuodossa toimitettavaa softaa yhteensopivuussyistä voida kääntää vain AVX512-tuki päällä, koska se binääri ei toimisi suurimmalla osalla käyttäjistä.

Ja Intelin sähläys sen suhteen ettei ole tuonut AVX-512sta työpöytämalleihinsa eikä edes AVXää pikkuytimiinsä on vaan pahentanut tilannetta, ja taas tämä AVX-512n kytkeminen oletuksena pois päältä Adler Lakesta on samaa sähläystä. Joskus vuonna 2028 softankehittäjät eivät vieläkään voi kääntäjistään kytkeä oletuksena AVX-512aa päälle kun ihmisillä on silloin käytössään vielä edelleen liikaa Adler Lakeja jotka eivät sitä tue (zen4 todnäk tuo sille tuen ensi vuonna).

(Juuri taisi uusi joku peli saada jonkun patchin jossa siitä disabloitiin AVX-tuki kun peli ei toiminut Atomeilla, Nehalemeilla tai Phenomeilla jotka ei tue AVXää, tosin ilmeisesti se peli kuitenkin käytti sitä AVXää vain hyvin vähän, oli aiottu olla käyttämättä yhteensopivuussyistä mutta vahingossa jäänyt päälle johonkin kirjastoon jolloin yhteensopivuutta ei aluksi ollutkaan)


Mutta tosiaan, itse en pidä AVX-512sta mitenkään täydellisenä, ARMin SVE/SVE2 on mielestäni paljon parempi, mutta AVX-512 on se kehittynein SIMD mikä meillä x86lla on, eikä ole mitään realistisia mahdollisuuksia että lähitulevaisuudessa tulisi x86lle mitään parempaa; jos halutaan vektoroida mahdollisimman suuri osa koodin loopeista niin sitten AVX-512 on siihen paras optio. Eli monessa koodissa parasta suorituskykyä halutessa joko aletaan ottaa x86lle AVX-512sta käyttöön tai hypätään kokonaan ARM-maailmaan

Jos Intel ei olisi alkanut aikoiaan puuhastelemaan Larrabeen kanssa niin meillä olisi ehkä AVX-512 tilalla joku hiukan puhtaampi mutta ei kuitenkaan merkittävästi erilainen AVX2sta kehittyneempi SIMD-laajennos. Mahdollisesti ehkä joku "AVX3" scatter-storella mutta edelleen 256-bittisillä vektoreilla.

 

[moukula]

Mielestäni juuri tuon takia AVX-512:lle ei kannata antaa tässä vaiheessa vielä suurta painoarvoa. Siinä vaiheessa kun se kyseinen ominaisuus on laajalti käytössä työpöydillä (ehkä 5 vuoden aikajänteellä jos optimistisia ollaan) niin nämä nykyiset prosessorit ovat serrikamaa jo muutenkin. Tietokoneraudassa ei kannata sijoittaa kovin montaa vuotta tulevaisuuteen.

Vähän sama keissi kuin että jos aikoinaan osti Ryzen 1700X:n sillä perusteella että "tulevaisuudessa ytimiä tarvitaan enempi" niin tämä alkaa realisoitumaan tässä pikkuhiljaa. Vasta Cyberpunk ja muutama muu tuore peli on alkanut tosissaan hyödyntämään ytimiä. Toki 1700X on edelleen ihan pelikelpoinen prosessori ja ne 8 ydintä varmistaa ettei ihan hirmuisia dippauksia frametimeissa pääse tapahtumaan vrt. joku 7700K saatikka 4c/4t i5-mallin prosessori, mutta sen single thread suorituskyky alkaa samalla käymään pullonkaulaksi.

 

[Timo 2]

Ei tässä ole kyse "kokemusharhasta" vaan siitä että mietin asioita pitkällä tähtäimellä ja MAHDOLLISEN/POTENTIAALISEN suorituskyvyn näkökulmasta, enkä siitä näkökulmasta miten JUURI TÄLLÄ HETKELLÄ eniten käytössä olevat softat pyörii.


Eli, itse en käytä AVX-512aa ollenkaan, mutta suunnittelen työkseni erikoistuneita prosessoreita signaalinkäsittelyjuttuihin, ja niissä (järeä) SIMD on aivan elinehto järkevään suorituskykyyn ja hyvään energiatehokkuuteen.

Olen suunnitellut prosessoreita joissa on vielä AVX-512aakin leveämpi SIMD-datapolku. (toki kellot paljon pienempiä ja rinnakkaisten laskentayksiköiden määrät paljon pienempiä, kun kuitenkin kyse hyvin pienistä vähävirtaisista ytimistä)

Kun halutaan oikeasti sitä suorituskyvyn kannata parasta mahdollista lopputulosta numeronmurskaukseen, ja ollaan valmiita näkemään se vaiva sen käyttämisestä, järeä SIMD on aivan ehdoton.

PC-puolella vaan ongelma on se, että softa laahaa vuosia jäljessä, peleihin alkaa vasta nyt tulla optimointeja edes AVXlle, ja yhteensopivuussyyt estää kätevästi ottamasta uusia käskykantoja käyttöön.

Paljon suorituskykyä tarvitsevia workloadeja joissa AVX-512lla ei tee mitään on esim joku selaimen javascript-tulkki, tai kääntäjä, jolla käännetään koodia, tai joku palvelinsofta joka palvelee todella suurta määrää käyttäjiä.

Muuten suuri osa paljon suorituskykyä tarvitsevasta koodista on sellaista että kyllä sieltä löytyisi leveälle ja ominaisuusrikkaalle SIMD-käskykannalle paikoitellen käyttöä.

Eli ongelma on se, että kun mahdollinen tulevaisuuden kapasiteetti ja hyöty tämän hetken softilla on ihan eri tasolla, niin tavallinen pulliainen joka ei ymmärrä asioita syvällisesti tuijottaa vaan niitä tämän hetken benchmarkkeja vanhoilla softilla.



AVX-512 rikkaampien ominaisuuksiensa (mm. scatter) takia nimeomaan mahdollistaa sen, että kääntäjän on teoriassa helpompi automaattisesti (jos sille vaan annetaan lupa) vektoroida se koodi, että koodarin ei tarvitse tehdä mitään että ne SIMD-käskyt tulee joissain tilanteissa käyttöön

Tässä tulee kuitenkin ongelmaksi yhteensopivuus; Normaalit softankehitysmekanismit eivät tue sitä, että kääntäjä voisi helposti ja automaattisesti tehdä koodista monta eri versiota eri käskykantalaajennoksille ja ajonaikaisesti valittaisiin oikea, vaan koodaaja joutuu näkemään huomattavasti ylimääräistä vaivaa jos haluaa koodista monta eri polkua eri käskykantalaajennoksille. Tämän takia kääntäjälle tyypillisesti vaan sanotaan että "targetoi geneeristä x86-64sta" (eli SIMDn osalta joku SSE2) tai sitten "saat käyttää AVXää", mutta käytännössä mitään binäärimuodossa toimitettavaa softaa yhteensopivuussyistä voida kääntää vain AVX512-tuki päällä, koska se binääri ei toimisi suurimmalla osalla käyttäjistä.

Ja Intelin sähläys sen suhteen ettei ole tuonut AVX-512sta työpöytämalleihinsa eikä edes AVXää pikkuytimiinsä on vaan pahentanut tilannetta, ja taas tämä AVX-512n kytkeminen oletuksena pois päältä Adler Lakesta on samaa sähläystä. Joskus vuonna 2028 softankehittäjät eivät vieläkään voi kääntäjistään kytkeä oletuksena AVX-512aa päälle kun ihmisillä on silloin käytössään vielä edelleen liikaa Adler Lakeja jotka eivät sitä tue (zen4 todnäk tuo sille tuen ensi vuonna).

(Juuri taisi uusi joku peli saada jonkun patchin jossa siitä disabloitiin AVX-tuki kun peli ei toiminut uusilla Atomeilla jotka ei tue AVXää ja tuli liikaa valitusta tästä...)

Miten haluat kommentoida väitettä, että avx 512 on hyödytön, koska sen pystyy ajamaan näytönohjaimella nopeammin/helpommin. Taisi olla @pomk joka tätä ajtusta on pitänyt esillä. Tämä vain sivusta seeuraavan näkökulmasta.

 

[Kaotik]

Miten haluat kommentoida väitettä, että avx 512 on hyödytön, koska sen pystyy ajamaan näytönohjaimella nopeammin/helpommin. Taisi olla @pomk joka tätä ajtusta on pitänyt esillä. Tämä vain sivusta seeuraavan näkökulmasta.

Taitaa iso osa niistä laskuista olla sellaisia, että siirtoviiveet kumoaisivat näytönohjaimella ajon mahdolliset hyödyt

 

[pomk]

Miten haluat kommentoida väitettä, että avx 512 on hyödytön, koska sen pystyy ajamaan näytönohjaimella nopeammin/helpommin. Taisi olla @pomk joka tätä ajtusta on pitänyt esillä. Tämä vain sivusta seeuraavan näkökulmasta.

Tuo ei pidä yleisesti paikkaansa, vaan sitä silloisessa keskustelussa esillä pidettyä ian cutlessin 3dpm testisoftaa ei kannata käyttää esimerkkinä tuosta syystä johtuen. Se olisi kokonaisuudessaan mahdollista toteuttaa ihan typerän paljon nopeampana GPU softana.

On paljon softia jotka hyötyisivät nopeasta avx-512 suorituksesta jonkin verran ja joita ei voisi siirtää GPU:n laskettavaksi ilman hankalia pullonkauloja.

 

[hkultala]

Miten haluat kommentoida väitettä, että avx 512 on hyödytön, koska sen pystyy ajamaan näytönohjaimella nopeammin/helpommin. Taisi olla @pomk joka tätä ajtusta on pitänyt esillä. Tämä vain sivusta seeuraavan näkökulmasta.

Kaotika jo vastasikin, kun rinnakkaisesti laskettavat asiat on pieniä ja niitä on paljon, siirtoviiveet ja ajuriviiveet näyttikselle dominoisivat ja pilaisivat suorituskyvyn, ja jos laskentaa tehdään vähän/siirretty arvo, laskenta on nopeampaa CPUlla kuin sen siirtäminen näyttikselle ja takaisin.

Geneeristen rinnakkaisten asioiden laskeminen näyttiksellä toimii hyvin kun kaikki seuraavista ehdoista toteutuu

1) Jokaista siirrettyä arvoa kohden tehdään tarpeeksi paljon laskentaa, että siirron kaista ei ole niin paha pullonkaula, että CPU laskisi sen nopeammin. Tässä puhutaan nykyään suuruusluokkaa ~100 laskuoperaatiosta/siirretty lukuarvo.

2) Jokainen rinnakkaisesti suoritettava koodialue on laskennan määrältään tarpeeksi pitkä että ajurioverhead ja tiedonsiirron latenssi ei tule pullonkaulaksi.

3) Koodari jaksaa nähdä vaivan siitä, että nysvää sen datan sinne näytikselle laskettavaksi, eli kirjoittaa koodinsa esim. OpenCL:llä. Tässä on tyypillisesti selvästi enemmän nysväämistä ja vaivaa kuin SIMDille optimoinnissa, tosin tähän on tulossa uusia helpompia rajapintoja.

 

[Timo 2]

Tuo ei pidä yleisesti paikkaansa, vaan sitä silloisessa keskustelussa esillä pidettyä ian cutlessin 3dpm testisoftaa ei kannata käyttää esimerkkinä tuosta syystä johtuen. Se olisi kokonaisuudessaan mahdollista toteuttaa ihan typerän paljon nopeampana GPU softana.

On paljon softia jotka hyötyisivät nopeasta avx-512 suorituksesta jonkin verran ja joita ei voisi siirtää GPU:n laskettavaksi ilman hankalia pullonkauloja.

Kiitos selvennyksestä.

Pahoittelut, että muistin/ymmärsin väärin.

 

[prc]

Ei tässä ole kyse "kokemusharhasta" vaan siitä että mietin asioita pitkällä tähtäimellä ja MAHDOLLISEN/POTENTIAALISEN suorituskyvyn näkökulmasta, enkä siitä näkökulmasta miten JUURI TÄLLÄ HETKELLÄ eniten käytössä olevat softat pyörii.

Eli, itse en käytä AVX-512aa ollenkaan, mutta suunnittelen työkseni erikoistuneita prosessoreita signaalinkäsittelyjuttuihin, ja niissä (järeä) SIMD on aivan elinehto järkevään suorituskykyyn ja hyvään energiatehokkuuteen.

Tuo toki mutta jossain on se järjellinen raja kuinka leveitä laskureita kannattaa vääntää geneerisen CPU:n jokaisen coren sisään. Se missä se raja sitten menee en osaa sanoa, mutta ilmeisesti low power corejen kohdalla sinne ei haluta 512b.

Ihan sillä pohdin, kun SIMD yksiköitä halutaan jatkuvasti leventää (ja ihan syystä).. missä tulee se raja, että ne pitää heivata sieltä coresta ulos, mutta johonkin lähemmäksi kuin ulkoisen väylän toisessa päässä kuten dGPU. 4, 64, 128kbit?

Tuli vaan mieleen tuo coren ulkopuoelle sijoittaminen, kun nyt AMD:llä on hinku FPGA vireveiltä paketoida CPU:n lähelle. Toisaalta aikoinaan se FPU oli ulkoisena resurssina. Ei toki ihan triviaalia, kun sitten corella ei enää ole kontrollia siihen resurssiin samalla tapaa + kaikki cache coherencyt ja viiveet yms.

Toki olisi kivan helppoa jos aina voisi legacyt vaan heivata olan yli.. kokemusta on sentäs softapuolelta, tänään sai ihmetellä jotain viime vuosituhannen koodihirviöitä joista toki ei ole mitään dokumentaatiota missään..

 

[Kaotik]

Tuo toki mutta jossain on se järjellinen raja kuinka leveitä laskureita kannattaa vääntää geneerisen CPU:n jokaisen coren sisään. Se missä se raja sitten menee en osaa sanoa, mutta ilmeisesti low power corejen kohdalla sinne ei haluta 512b.

Ihan sillä pohdin, kun SIMD yksiköitä halutaan jatkuvasti leventää (ja ihan syystä).. missä tulee se raja, että ne pitää heivata sieltä coresta ulos, mutta johonkin lähemmäksi kuin ulkoisen väylän toisessa päässä kuten dGPU. 4, 64, 128kbit?

Tuli vaan mieleen tuo coren ulkopuoelle sijoittaminen, kun nyt AMD:llä on hinku FPGA vireveiltä paketoida CPU:n lähelle. Toisaalta aikoinaan se FPU oli ulkoisena resurssina. Ei toki ihan triviaalia, kun sitten corella ei enää ole kontrollia siihen resurssiin samalla tapaa + kaikki cache coherencyt ja viiveet yms.

Toki olisi kivan helppoa jos aina voisi legacyt vaan heivata olan yli.. kokemusta on sentäs softapuolelta, tänään sai ihmetellä jotain viime vuosituhannen koodihirviöitä joista toki ei ole mitään dokumentaatiota missään..

Intelhän on tarjoillut jo vuodesta 2018 Xeoneita joissa on FPGA integroitu samaan paketointiin. Toki suoraan itse sirulle integroitu on vielä ison askeleen pidemmällä, mutta veikkaan että nuo tulee todellisuudessa löytymään semi-custom prossuista, ellei AMD aio sitten eriyttää palvelin- ja kuluttajaytimiä toisistaan. Kuluttajamalleissa PEU-yksiköille on vaikeampi löytää kylliksi käyttöä oikeuttamaan niiden viemää tilaa

 

[hkultala]

Tuo toki mutta jossain on se järjellinen raja kuinka leveitä laskureita kannattaa vääntää geneerisen CPU:n jokaisen coren sisään. Se missä se raja sitten menee en osaa sanoa, mutta ilmeisesti low power corejen kohdalla sinne ei haluta 512b.

Itse yksiköiden ei ole pakko olla täyslevyisiä, jos tyydytään hitaampaan suorituskykyyn, leveät SIMD-käskyt voi pilkkoa pieneen palaan ja suorittaa osissa, kunhan vaan rekisterifileeessä riittää kapasiteetti kaikille arkkitehtuurisille rekistereille. Esim. juuri noissa pikkuytimssä vajaalevyinen toteutus olisi hyvin järkevä, kun se haluttaiisin sinne vain yhteensopivuussyistä, että sen voi kytkeä päälle isoilla ytimillä.

Veikkaan, että Adlder Lakessa 256-bittiset AVX-käskyt suoritetaan pikkuytimillä tällä tavalla pilkkomalla ne kahteen 128-bittiseen osaan, mutta en ole varma. AVX-512 siten vaatisi neljään osaan pilkkomista 128-bittisellä datapolulla.

Samoin esim Zen1ssä oli vain 128-bittinen SIMD-datapolku, mutta silti tuki 256-bittisille AVX-operaatioille.

Ihan sillä pohdin, kun SIMD yksiköitä halutaan jatkuvasti leventää (ja ihan syystä).. missä tulee se raja, että ne pitää heivata sieltä coresta ulos, mutta johonkin lähemmäksi kuin ulkoisen väylän toisessa päässä kuten dGPU. 4, 64, 128kbit?

Ei niitä voi heittää "ytimeltä ulos" jos ne suorittaa samaa käskystreamia.

Mutta se, mitä voidaan tehdä on, että tuodaan jotain erillisiä rinnakkaisen laskennan kiihdytinytimiä (jotka siis suorittavat eri käskystreamia, joudutaan edelleen kärsimään ajuriviivettä tai vähintään synkronointiviivettä), mutta kaistaa on tarpeeksi koska väylä on nopea) CPUn kanssa samalle piilastulle, nopean sisäisen väylän päähän.

APUthan oikeastaan ovat tällaisia.

Tuli vaan mieleen tuo coren ulkopuolelle sijoittaminen, kun nyt AMD:llä on hinku FPGA vireveiltä paketoida CPU:n lähelle. Toisaalta aikoinaan se FPU oli ulkoisena resurssina. Ei toki ihan triviaalia, kun sitten corella ei enää ole kontrollia siihen resurssiin samalla tapaa + kaikki cache coherencyt ja viiveet yms.

Ydin ja piiri oli eri asioita. FPU oli erillisellä fyysisellä piirillä mutta loogisesti se oli osa ydintä.

 

[vemkki]

Luulisi olevan vähän ennenaikaista näihin lykätä pcie 5.0, kun nelostakaan ei kuluttajalaitteissa tue juuri mikään... Mutta eipä siitä kai haittaakaan ole.

Kyllähän uusimmat näytönohjaimet tukevat PCIe 4.0:aa, ja näytönohjaimia vartenhan tuo väylä on. Eri asia tietysti on, että milloin tulevat ensimmäiset näytönohjaimet PCIe 5.0 -tuen kera ja mitä käytännön hyötyä siitä seuraa.

 

[mRkukov]

Kyllähän uusimmat näytönohjaimet tukevat PCIe 4.0:aa, ja näytönohjaimia vartenhan tuo väylä on. Eri asia tietysti on, että milloin tulevat ensimmäiset näytönohjaimet PCIe 5.0 -tuen kera ja mitä käytännön hyötyä siitä seuraa.

Massamuistit hyötyy noista enemmän kuin näyttikset. Harva uusikaan näyttis tukehtuu PCIe3 väylän takia.

 

[Timo 2]

Massamuistit hyötyy noista enemmän kuin näyttikset. Harva uusikaan näyttis tukehtuu PCIe3 väylän takia.

Tieteellisessä laskennassa ehkä joo, mutta ei kuluttajakäytössä. Sata ssd:kin riittää todella pitkälle ja kingston a2000 riittä noupeuden osalta 99 % ja cs3030 riittääkin sitten 99,99 %.

 

[mRkukov]

Tieteellisessä laskennassa ehkä joo, mutta ei kuluttajakäytössä. Sata ssd:kin riittää todella pitkälle ja kingston a2000 riittä noupeuden osalta 99 % ja cs3030 riittääkin sitten 99,99 %.

Massamuisteilla vaan saadaan selkeitä eroja testiohjelmissa. Jos uusi levy on 40% nopeampi kuin vanha, niin vanha on hidas. Tämä siitä huolimatta että se vanha olisi ollut jo 10x nopeampi kuin mitä käyttäjä oikeasti tarvitsee. Itsellä edelleen pelkkiä sata levyjä pöytäkoneessa.

 

[hkultala]

Massamuisteilla vaan saadaan selkeitä eroja testiohjelmissa.

Tietokoneita ei yleensä ostella testiohjelmien ajamista varten, vaan sitä varten että sillä ajetaan joko hyötyohjelmia tai käytetään viihdekäytössä eli pelataan tms.

Ja näiden nopeudelle sillä levyn raa'alla siirtonopeudella ei ole käytännössä MITÄÄN väliä.

Sen sijaan levyn HAKUAJALLA eli viiveellä on näille paljon väliä. Käytetyn PCI-väylän versiolla ei kutienkaan ole käytännössä mitään vaikutusta tähän viiveeseen.

Tyypillinen luku massamuistista on virtuaalimuistisivun (4 kiB) kokoluokkaa. 4 gigatavua sekunnissa siirtävällä 4x pci 3.0-väylällä tämä siirtyy teoriassa n. mikrosekunnissa, ja käytännössä nopeat kuluttaja-SSDt pääsevät n. parin gigatavua sekunnissa siirtonopeuteen, eli tämä siirtyy n. 2 mikrosekunnissa.

NAND Flash-pohjaisten SSDiden viive on kuitenkin 50-100 mikrosekunnin luokkaa. Sen datansiirron aloittamista siis tyypillisesti odotellaan n. 25-50 kertaa enemmän kuin siihen itse siirtoon menee aikaa. Se, että sen SSDn siirtonopeus tuplattaisiin tarkoittaisi siis vain 2-4% nopeutusta siihen, kuinka kauan käyttäjä joutuu tyypillisesti odottelemaan koneen tehdessä levy-IOta.

Sen sijaan että tuijottaa niitä teoreettisia siirtonopeuksia, on ziljoona kertaa fiksumpaa tuijottaa viiveitä.

Jos uusi levy on 40% nopeampi kuin vanha, niin vanha on hidas. Tämä siitä huolimatta että se vanha olisi ollut jo 10x nopeampi kuin mitä käyttäjä oikeasti tarvitsee. Itsellä edelleen pelkkiä sata levyjä pöytäkoneessa.

Jos ostetaan kaupunkiliikenteesen autoa ja valitaan kahden välillä, toinen kulkee 200 km/h ja toinen 280km/h, onko se 200km/h kulkeva hidas?

Sen sijaan jos toista pitää lämmittää minuutin ennen kuin moottori suostuu käynnistymään ja toinen käynnistyy heti sekunnissa, se sekunnissa käynnistyvä on kaikessa hyötykäytössä nopeampi.

 

[Timo 2]

Massamuisteilla vaan saadaan selkeitä eroja testiohjelmissa. Jos uusi levy on 40% nopeampi kuin vanha, niin vanha on hidas. Tämä siitä huolimatta että se vanha olisi ollut jo 10x nopeampi kuin mitä käyttäjä oikeasti tarvitsee. Itsellä edelleen pelkkiä sata levyjä pöytäkoneessa.

Kyllä sen näytönohjaimen testiohjelmakin saadaan hyötymään tuosta pci-e 4.0 standardista. Mutta missään muualla tuosta ei ole hyötyä. Sama juttu ssd levyn kanssa. Toki jos harrastat kopiointia levyltä toiselle, niin sitten ...

 

[mRkukov]

Tietokoneita ei yleensä ostella testiohjelmien ajamista varten, vaan sitä varten että sillä ajetaan joko hyötyohjelmia tai käytetään viihdekäytössä eli pelataan tms.

Kyllä sen näytönohjaimen testiohjelmakin saadaannhyötymään tuosta pci-e 4.0 standardista. Mutta missään muualla tuosta ei ole hyötyä. Sama juttu ssd levyn kanssa. Toki jos harrastat kopiointia levyltä toiselle, niin sitten ...

Itse siis samaa mieltä. Juuri mitään todellista hyötyä ei perus käyttäjä huomaa. Edes tehokäyttäjälle ero ei ole kovin suuri (itsellä 2x sata raid0 tuomassa kaistaa).

Mutta, se joka katsoo vain levyjen testituloksia pikaisesti uutta konetta kasatessa tulkitsee helposti niin ettei vanhalla tee mitään. Maksiminopeudet esitelty samaan tapaan kuvaajana kuin näyttisten pelinopeudet. Eihän sitä nyt voi huippukoneeseen mitään vanhaa roskaa laittaa! (/sarkasmi)

 

[prc]

Itse yksiköiden ei ole pakko olla täyslevyisiä, jos tyydytään hitaampaan suorituskykyyn, leveät SIMD-käskyt voi pilkkoa pieneen palaan ja suorittaa osissa, kunhan vaan rekisterifileeessä riittää kapasiteetti kaikille arkkitehtuurisille rekistereille. Esim. juuri noissa pikkuytimssä vajaalevyinen toteutus olisi hyvin järkevä, kun se haluttaiisin sinne vain yhteensopivuussyistä, että sen voi kytkeä päälle isoilla ytimillä.

Veikkaan, että Adlder Lakessa 256-bittiset AVX-käskyt suoritetaan pikkuytimillä tällä tavalla pilkkomalla ne kahteen 128-bittiseen osaan, mutta en ole varma. AVX-512 siten vaatisi neljään osaan pilkkomista 128-bittisellä datapolulla.

Samoin esim Zen1ssä oli vain 128-bittinen SIMD-datapolku, mutta silti tuki 256-bittisille AVX-operaatioille.
...

Jeh tuo pilkkominen olikin sinänsä tuttu. Oikeastaan ihan sillä kyselinkin näkemyksiäsi kun noista tiedät. Joskus oli hilkulla olisiko lähtenyt softalle vai piirisuunnittelu puolelle opiskelemaan, mutta softalle tuli mentyä. Perusteet nyt ymmärtää frontin, coren ja backendin toiminnasta, mutta siihen se sitten jää.