RISC-V-kehittäjä SiFive ja Intel yhteistyöhön

[Kaotik]

Kaotik kirjoitti uutisen/artikkelin:
Avoimen RISC-V-arkkitehtuurin johtaviin kehittäjiin lukeutuva SiFive on ilmoittanut tänään merkittävistä uutisista. Yhtiö on aloittanut yhteistyön Intelin kanssa sekä kehitysalustojen että tuotannon puolella.

Intel tulee tarjoamaan SiFiven IP-portfoliota (Intellectual Property, immateriaalioikeudet) jatkossa Intel Foundry Services -tuotantolaitosten asiakkaille 7 nanometrin prosessilla toteutettuna. Intel pyrkii IFS:n kautta kilpailemaan vakavasti TSMC:n, Samsungin ja muiden puolijohdevalmistajien kanssa asiakaspiirien tuotannosta ja on ilmoittanut aiemmin tulevansa lisensoimaan jopa x86-ytimiään asiakaspiireihin.

SiFiven RISC-V IP on ensimmäinen kolmannen osapuolen IP, jota tullaan tarjoamaan IFS:n asiakkaille. Pakettiin kuuluvat tässä vaiheessa ainakin SiFive Performance P550- ja P270-ytimet. P550 eli RV64GBC on pinta-alaoptimoitu arkkitehtuuri, jonka ytimet vievät 7 nanometrin prosessilla tilaa vain 0,38 mm2. Ytimet ovat 13-vaiheisia kolme käskyä kerralla liikuttaviaa Out-of-Order-tyyppisiä RISC-V-ytimiä, joilla on oma L1- ja L2-tason välimuistinsa. P550 on suunniteltu maksimissaan neliytimiseksi ja ytimet jakavat L3-välimuistin keskenään. Kevyempi P270 eli RV64GBCV vie tilaa vaivaiset 0,175 mm2 ja ne ovat 8-vaiheisia kahta käskyä kerralla liikuttavia In-Order-tyyppisiä RISC-V-ytimiä.

Toinen aiheeseen liittyvä merkittävä uutinen on puolestaan Intelin päätös julkaista SiFiven Performance P550 -kehitysalusta. Horse Creek -koodinimellä ja 7 nanometrin prosessilla valmistettava kehitysalusta tulee hyödyntämään P550-ytimiä, mutta esimerkiksi PCIe-ohjaimet ja DDR-muistiohjaimet tulevat olemaan Intelin käsialaa. Kehitysalusta tuodaan markkinoilla ensi vuoden aikana.

Lähteet: AnandTech (1), (2)

Linkki alkuperäiseen juttuun

 

[julmuri]

Toivottavasti Intel siirtyy pikkuhiljaa pois x86-käskykannasta RISC-V kantaan.

 

[jive]

Jaahas sitten odotellaan Cyclone sarjaan FPGA+RISC-V tuotteita. Mikäs tämmöinen 7nm Intel prosessi on? Luulin että skippasivat ja tähtäävät suoraan 5nm luokkaan.

 

[JiiPee]

Toivottavasti Intel siirtyy pikkuhiljaa pois x86-käskykannasta RISC-V kantaan.

Varmaan konesaleihin toi tulee yleistymään jonkin verran, mutta muualla on niin paljon kaikenlaista legacy softaa jonka on pyörittävä että en näe että esim. 2030 toi olisi kaikkialla.

Sinänsä sääli koska tuolla olis mahdollista rakentaa varsin tehokas CPU ainakin JIm Kellerin mielestä:

Because there's no legacy. It's actually an open instruction set architecture, and people build it in universities where they don’t have time or interest to add too much junk, like some architectures have. So relatively speaking, just because of its pedigree, and age, it's early in the life cycle of complexity. It's a pretty good instruction set, they did a fine job. So if I was just going to say if I want to build a computer really fast today, and I want it to go fast, RISC-V is the easiest one to choose. It’s the simplest one, it has got all the right features, it has got the right top eight instructions that you actually need to optimize for, and it doesn't have too much junk.

x86 esim kannetaan mukana kaikenmoista roskaa koska se tuki täytyy säilyttää jollekin kivikautisella softalle.

 

[Kaotik]

Jaahas sitten odotellaan Cyclone sarjaan FPGA+RISC-V tuotteita. Mikäs tämmöinen 7nm Intel prosessi on? Luulin että skippasivat ja tähtäävät suoraan 5nm luokkaan.

Ettet ole sekoittanut nyt siihen, että Intelin "7nm:n" ja TSMC:n (ja vissiin Samsunginkin) "5nm:n" odotetaan olevan suurin piirtein samaa koko/tiheysluokkaa?

 

[perho92]

Ettet ole sekoittanut nyt siihen, että Intelin "7nm:n" ja TSMC:n (ja vissiin Samsunginkin) "5nm:n" odotetaan olevan suurin piirtein samaa koko/tiheysluokkaa?

Intelillä olisi nyt hyvä hetki napata tuo "markkinointitermiero" kiinni, myymällä tätä heidän yhtä tiheetä "7nm" prosessia suoraan "5nm" nimellä, kuten kilpailijat tekee.

Hyppy 14 -> 5 työpöytäprosessorien puolella näyttäisi aika hurjalta paperilla, ja oikein markkinoituna herättäisi varmasti positiivistakin huomiota siitä, miten Intel on vihdoin kirinyt itsensä kärkitaisteluihin TSMC:n ja Samsungin kanssa.

Kukaan ei ainakaan voisi valittaa, että Intel valehtelee oman prosessinsa olevan tiheämpää, kuin mitä vastaavalla nanometrilukemalla varustetut kilpailijat, koska todellisuudessa Samsung ja TSMC ovat käyttäneet pienempiä ja sitä myötä virheellisempiä lukuja vielä enemmän hyväkseen tähän asti, esim. tiheydeltään TSMC 7 nm = Intelin 10 nm.

Olisi ainakin rehellisempää, kun kaikki valehtelisi yhtä paljon, ja sitä myötä kuluttajalla olisi paremmat mahdollisuudet hahmottaa prosessorien energiatiheys pelkästä nanometrilukemasta.

 

[bladE_666]

Varmaan konesaleihin toi tulee yleistymään jonkin verran, mutta muualla on niin paljon kaikenlaista legacy softaa jonka on pyörittävä että en näe että esim. 2030 toi olisi kaikkialla.

Sinänsä sääli koska tuolla olis mahdollista rakentaa varsin tehokas CPU ainakin JIm Kellerin mielestä:


x86 esim kannetaan mukana kaikenmoista roskaa koska se tuki täytyy säilyttää jollekin kivikautisella softalle.

Tätä tahtia on kohta nopeampaa ja energiatehokkaampaa emuloida sitä x86:sta ARM:lla, kuin ajaa sitä natiivina. Samalla voidaan ajaa taustalla natiivisti sitä RISC-koodia, joka jättää viimeistään menneisyyden katkut taakseen.

 

[ratkakapu]

Olisi ainakin rehellisempää, kun kaikki valehtelisi yhtä paljon, ja sitä myötä kuluttajalla olisi paremmat mahdollisuudet hahmottaa prosessorien energiatiheys pelkästä nanometrilukemasta.

Viivanleveys ei ainakaan suoraan kerro "energiatiheyttä"

Muutenkin kuluttajalle on kyllä ihan sama mitä viivanleveyttä (todellista ja markkinanimeä) mikäkin tuote on. Itse ainakin ostan suorituskykyä enkä nanometrejä. No ehkä joskus 15 kesäsenä oli upeaa kun oli "uusinta 40nm tekniikkaa" koneessa

 

[ratkakapu]

Olisi ainakin rehellisempää, kun kaikki valehtelisi yhtä paljon, ja sitä myötä kuluttajalla olisi paremmat mahdollisuudet hahmottaa prosessorien energiatiheys pelkästä nanometrilukemasta.

Viivanleveys ei ainakaan suoraan kerro "energiatiheyttä"

Muutenkin kuluttajalle on kyllä ihan sama mitä viivanleveyttä (todellista ja markkinanimeä) mikäkin tuote on. Itse ainakin ostan suorituskykyä enkä nanometrejä. No ehkä joskus 15 kesäsenä oli upeaa kun oli "uusinta 40nm tekniikkaa" koneessa

 

[perho92]

Viivanleveys ei ainakaan suoraan kerro "energiatiheyttä"

Muutenkin kuluttajalle on kyllä ihan sama mitä viivanleveyttä (todellista ja markkinanimeä) mikäkin tuote on. Itse ainakin ostan suorituskykyä enkä nanometrejä. No ehkä joskus 15 kesäsenä oli upeaa kun oli "uusinta 40nm tekniikkaa" koneessa

Suurin osa ei mieti hirveesti sen syvällisempiä kulutusroinaa ostaessaan, hyvä jos testivideoita saatikka artikkeleita jaksavat katsoa. Näille 5 nm voi olla vain 5 nm, jos sen enempää ei ymmärretä asiasta kuin, että pienempi on parempi virrankulutuksen suhteen.

Tämän myötä peruskuluttaja usein uskoo puhtaasti, mitä kuuluisimmat testaajat sekä markkinamiehet heille kertovat, tai parhaassa tapauksessa lueskelevat virrankulutuslukemia ja fps lukemia, verraten subjektiivisesti, että mikä sopii omiin tarpeisiin ja budjettiin, päästen hieman pintaa syvemmälle.

Itseoppineet tekniikkanörtit on pieni osa kulutuselektroniikan ostoryhmää.

 

[mopnex]

Saisiko io-techiin vaikka vierailevan kirjoittajan toimesta artikkelin näistä eri mikroarkkitehtuureista? Etenkin RISC-V kattavempi esittely kiinnostaa.

 

[akse]

Viivanleveys ei ainakaan suoraan kerro "energiatiheyttä"

Muutenkin kuluttajalle on kyllä ihan sama mitä viivanleveyttä (todellista ja markkinanimeä) mikäkin tuote on. Itse ainakin ostan suorituskykyä enkä nanometrejä. No ehkä joskus 15 kesäsenä oli upeaa kun oli "uusinta 40nm tekniikkaa" koneessa

Tuohon aikaan ainakin tapahtui suht suuria hyppäyksiä suorituskyvyssä johtuen tiheämmästä prosessista. 90nm -> 45nm jne.
Jopa 65->45nm oli aika kovia lukemia. Esim E6600 2,4Ghz 2core ja tuosta uusi versio 45nm E8600 oli 3,3Ghz about samalla tehonkulutuksella.

 

[hkultala]

Toivottavasti Intel siirtyy pikkuhiljaa pois x86-käskykannasta RISC-V kantaan.

... Kuten siirtyivät x86-käskykannasta i860- käskykantaan, i960-käskykantaan tai IA64-käskykantaan?

Tai kuten Motorola siirtyi 68000-käskykannasta 88000-käskykantaan tai PowerPC:hen?

Lopputulos olisi sama.

RISC-V on monilta osin huonompi käskykanta kuin x86 (mm. vajaat osoitusmuodot), ja Intelillä menee todella kovaa nimenomaan sen takia, että ovat säilyttäneet binääriyhteensopivuuden vanhoihin prossuihinsa.

Siinä, että siirrytään käyttämään uutta käskykantaa, joka ei ole parempi, mutta vaan rikkoo binääriyhteensopivuuden, ei ole mitään järkeä.


Yksi firma voi tehdä prosessoreita monella eri käskykannalla. Toisin kuin Motorola, Intel oli siitä fiksu, että tuodessaan markkinoille i860n, i960n ja Itaniumin, x86n kehitystä ei koskaan lopetettu. i860, i960, 88000k, Itanium ja motorolan mikropiiriosasto kuolivat, PowerPC kuoli työpöydältä ja vain IBMn powerit elää jossain, x86 ja Intel elävät erinomaisesti.


Jos x86sta johonkin siirrytään niin oikea suunta on ARMv(/ARMv9. Se on teknisesti paljon parempi käskykanta kuin RISC-V.

 

[Sami Riitaoja]

Jos x86sta johonkin siirrytään niin oikea suunta on ARMv(/ARMv9. Se on teknisesti paljon parempi käskykanta kuin RISC-V.

Se juna vain taisi mennä Intelin osalta, Intel tuskin haluaa panostaa kilpailevan firman käskykantaan.

Satuitko muuten lukemaan Jim Kellerin haastattelun Anandtechillä:

An AnandTech Interview with Jim Keller: 'The Laziest Person at Tesla'

www.anandtech.com

Kellerin mielipiteellä on väliä sen puolesta että hän ehti Intelilläkin hetken vaikuttaa, ja lähti sisäisten jännitteiden takia. Ja aika suoraan sanoo että RISC-V olisi hänen valintansa nyt suunnitellun nopean prosessorin käskykannaksi ja nimenomaan sen yksinkertaisuuden takia - ja Keller näemmä muutenkin arvostaa RISC-V:tä enemmän kuin sinä.......

 

[JiiPee]

Kellerin mielipiteellä on väliä sen puolesta että hän ehti Intelilläkin hetken vaikuttaa, ja lähti sisäisten jännitteiden takia. Ja aika suoraan sanoo että RISC-V olisi hänen valintansa nyt suunnitellun nopean prosessorin käskykannaksi ja nimenomaan sen yksinkertaisuuden takia - ja Keller näemmä muutenkin arvostaa RISC-V:tä enemmän kuin sinä.......

Meinasin itsekin viitata tuohon. Kellerhän suoraan sanoo että x86 on paljon turhaa roskaa mukana jotka hitastaa vain prosessoria. ARM:lle tapahtumassa samaa. RISC-V vielä pysynyt suht puhtaana jolla saisi hänen mielestään toteutettua nopeimman CPU:n. Vähän sen kuvan sai Kellerin haastattelusta että hänen mielestään Intel tunkee liikaa kaikkea prossuihin, just nää AVX sun muuta, halutaan että se CPU kykenee kaikkeen, mutta on sitten vähän jack of all trades.

 

[moukula]

Se vaan kotikäytössä on tärkeää olla vähän jack of all trades sen sijaan että kykenisi vain ajamaan jotain tietyntyyppistä sovellusta maksimaalisen nopeasti. HPC-käytössä toimii paremmin sellainen erikoisoptimoitu rauta.

 

[Sami Riitaoja]

Meinasin itsekin viitata tuohon. Kellerhän suoraan sanoo että x86 on paljon turhaa roskaa mukana jotka hitastaa vain prosessoria. ARM:lle tapahtumassa samaa. RISC-V vielä pysynyt suht puhtaana jolla saisi hänen mielestään toteutettua nopeimman CPU:n. Vähän sen kuvan sai Kellerin haastattelusta että hänen mielestään Intel tunkee liikaa kaikkea prossuihin, just nää AVX sun muuta, halutaan että se CPU kykenee kaikkeen, mutta on sitten vähän jack of all trades.

Ja se suurin ongelma ei ole nopeushaitta vaan se että x86-prosessoreja ei meinata saada nykyään debugattua yhtään mitenkään. Intel ei enää edes yritä debugata itse vaan varhaiset samplet lähtee kaikille suuremmille asiakkaille debuggausajoon josta saadun palautteen perusteella yritetaan harsia kasaan jotain toimivaa - ko. operaatio kestää kauan ja lopputulos on jäänyt viimevuosina kauas edes suunnilleen bugittomasta lopputuloksesta. Mutta mitä voi odottaa kun prosessorin on ängetty kaikki mitä vain ikinä on satuttu keksimäänkään.....

 

[Sami Riitaoja]

Se vaan kotikäytössä on tärkeää olla vähän jack of all trades sen sijaan että kykenisi vain ajamaan jotain tietyntyyppistä sovellusta maksimaalisen nopeasti. HPC-käytössä toimii paremmin sellainen erikoisoptimoitu rauta.

No erikoiskäskykannat johonkin tiettyyn erikoistilanteeseen on nimenomaan sitä optimointia tietyntyyppisiin sovelluksiin - jos käskykanta on niin karsittu kuin olla voi prosessori toimii joka tilanteessa suhteellisen tasaisella nopeudella.

 

[moukula]

En ole ammattilainen näiden suhteen niin virheellisen käsityksen saa toki korjata, mutta olen ollut siinä uskossa, että MMX/SSE/AVX on aika hyödyllisiä multimedian pyörittämisessä. Kotona ajellaan vähän kaikenlaista softaa, surffataan netissä, tehdään hommia officella, editoidaan videota ja valokuvia, pelataan jne. ja osa softista tarvitsee kovaa yhden säikeen suorituskykyä mutta toisaalta sillä leveydelläkin saattaa tietyissä jutuissa säästää minuutteja. Toki nykyään osataan hyödyntää myös näytönohjainta massiivisesti rinnakkaistuvaan laskentaan, mutta kaiketi se on hyvä olla jonkinlaista SIMD-kykyä myös CPU:lla.

edit: Ja se on minusta kotikäyttäjille arvokas ominaisuus että on sitä taaksepäin yhteensopivuutta.

 

[Sami Riitaoja]

En ole ammattilainen näiden suhteen niin virheellisen käsityksen saa toki korjata, mutta olen ollut siinä uskossa, että MMX/SSE/AVX on aika hyödyllisiä multimedian pyörittämisessä. Kotona ajellaan vähän kaikenlaista softaa, surffataan netissä, tehdään hommia officella, editoidaan videota ja valokuvia, pelataan jne. ja osa softista tarvitsee kovaa yhden säikeen suorituskykyä mutta toisaalta sillä leveydelläkin saattaa tietyissä jutuissa säästää minuutteja. Toki nykyään osataan hyödyntää myös näytönohjainta massiivisesti rinnakkaistuvaan laskentaan, mutta kaiketi se on hyvä olla jonkinlaista SIMD-kykyä myös CPU:lla.

Kaikki erikoiskäskykannat on lähinnä vain sitä varten että teknologia ei ole vielä mahdollistanut muunlaisia ratkaisuja. Eli siis on täysin mahdollista vääntää käskykanta niin että kaikki koodataan skalaarina mutta prosessorin rauta toteuttaa ajossa vektoroinnin aina kulloisenkin prosessorin ominaisuuksien mukaan. Mutta jotta homma saataisiin toimimaan pitää prosessorin käskykannan olla äärimmäisen yksinkertainen - eli mistä Kellerkin tuossa puhuu että kun hardkoodataan jotain käskykantaan mukaan niin se on sitten siellä haittaamassa kaikkia raudan tulevia iteraariota niiden luovimpien ja eniten nopeuttavien ratkaisujen osalta.

RISC-V:ssä on ollut suunnittelussa ajatusta mukana, eli sieltä puuttuu kaikki se toimintojen niputtaminen käskytasolla antaen raudan suunnittelijalle vapaat kädet innovoida käskyjen suoritus myös mahdollisilla muilla toteutustavoilla.

 

[hkultala]

Kaikki erikoiskäskykannat on lähinnä vain sitä varten että teknologia ei ole vielä mahdollistanut muunlaisia ratkaisuja.

Höpöhöpö.

Täysin päin vastoin.

Tekniikka on vuosikymmenet mahdollistanut muita ratkaisuita (kovakoodattu rauta, jolloin sillä tehdään tasan yhtä asiaa) sekä pelkästään yleiskäyttöisiä käskyjä sisältävät prosssorit (huono suorituskyky ja energiatehokkuus). Ja näitä ratkaisuita on käytetty paljon.

Erikoiskäskykannat nyt vaan sattuu olemaan vaan paras tapa tehdä asiat hyvällä suorituskyvyllä ja energiatehokuudella säilyttäen silti ohjelmoitavuus että tehtävää asiaa ei ole lukittu kuten se kiinteällä raudalla on lukittu.

Ja entistä enemmän nimenomaan ollaan nyt menossa siihen suuntaan, että tehdään erikoistuneita prosessoreita, erikoistuneilla käskykannoilla. Koska se nyt sattuu olemaan usein se paras kompromissi sen mukautuvuuden ja tehokkuuden suhteen.

Eli siis on täysin mahdollista vääntää käskykanta niin että kaikki koodataan skalaarina mutta prosessorin rauta toteuttaa ajossa vektoroinnin aina kulloisenkin prosessorin ominaisuuksien mukaan.
Mutta jotta homma saataisiin toimimaan pitää prosessorin käskykannan olla äärimmäisen yksinkertainen

Nyt menee ihan täysin sekaisin vektorointi/SIMD sekä erikoiskäskyt. Nämä on ihan ortogonaalisia asioita keskenään.

Ja muutenkin menee jälleen ihan mutusatuiluksi.

Se, että meillä on vaikka useampioperandisia käskyjä tai jotain bitinnysväyskäskyjä on ihan täysin ortogonaalista vektoroinnin kanssa.


Ja ei, prosessorin rauta ei voi mitenkään "toteuttaa ajossa vektorointia". Se, että spekulatiivisen suorituksen keinoin vähän interleavataan useampaa loopin iteraatiota ei ole mitään vektorointia, ja varsinaista vektorontia taas ei rauta voi järkevästi itse tehdä. Sen käskykannan pitää aina sisältää joku mekanismi jolla sanotaan, että nyt tämä asia tehdään vektorille, monelle data-alkiolle kerrallaan, ja määritellä rajapinta jossa jollain tavalla kerrotaan esim se, kuinka montaa alkoita käsitellään ja millaisella patternilla ne saadaan muistista ladattua ja sinne tallennettua jne. Rauta voi korkeintaan sisältää esim. muuttuvanleveyksisiä vektoreita tms., mutta ne vektorit pitää aina näkyä käskykannassa

- eli mistä Kellerkin tuossa puhuu että kun hardkoodataan jotain käskykantaan mukaan niin se on sitten siellä haittaamassa kaikkia raudan tulevia iteraariota niiden luovimpien ja eniten nopeuttavien ratkaisujen osalta.

Tällä ei ole mitään tekemistä vektoroinin kanssa. Tulkitset nyt taas ihan omiasi siitä mitä keller puhuu/teet authoriteettiin vetoamisen argumentointivirheen nostaessasi Kellerin (tai siis virheellisen tulkinnan Kellerin puheista) tässä esille.

RISC-V:ssä on ollut suunnittelussa ajatusta mukana, eli sieltä puuttuu kaikki se toimintojen niputtaminen käskytasolla antaen raudan suunnittelijalle vapaat kädet innovoida käskyjen suoritus myös mahdollisilla muilla toteutustavoilla.

Ei. Jälleen menee täysin päin vastoin.

Se, että joku käsky on olemassa, mahdollistaisi sille käskylle erilaisia toteutuksia eri prossuille.

Sen sijaan se, että käskyä ei ole, tarkoittaa että kaikkien toteutus on sama - käskyä ei ole, ja kaikki suorittaa samanlaisen hitaan sekventiaalisen monen käskyn käskysekvenssin sen rutiinin toteuttaakseen.

Esim. Base+offsettia parempien osoitusmuotojen tarve on arkipäivää ihan kaikenlaisessa koodissa, mutta RISC-V:stä kaikki tällaiset on jätetty pois.

RISC-V:ssä ainoa ajatus suunnittelussa on ollut, että tehdään siitä käskykannasta mahdollisimman yksinkertainen, jotta se soveltuu mahdollisimnan hyvin opetuskäyttöön, että oppilaiden on mahdollisimman helppo ymmärtää, miten se prossu toimii.

 

[Sami Riitaoja]

Esim. Base+offsettia parempien osoitusmuotojen tarve on arkipäivää ihan kaikenlaisessa koodissa, mutta RISC-V:stä kaikki tällaiset on jätetty pois.

RISC-V:ssä ainoa ajatus suunnittelussa on ollut, että tehdään siitä käskykannasta mahdollisimman yksinkertainen, jotta se soveltuu mahdollisimnan hyvin opetuskäyttöön, että oppilaiden on mahdollisimman helppo ymmärtää, miten se prossu toimii.

Se on sun mielipide, muitakin on. Eli RISC perusajatuksena on pitää operaatiot erillä toisistaan. Ne monimutkaiset osoitusmuodot yhdistävät ALU-operaation muistioperaatioon ja niiden poisjättämiselle on ihan perustellut syynsä. Toki tällähetkellä prosessorit on optimoitu hyvin pitkälle noille ALU+muistioperaatioille eli prosessoreissa on erilliset ALU:t load-store puolella laskemassa osoitteet noista osoitusmuodoista, tehokasta ja helposti toteutettavaa raudalla mutta vastaavasti rajoittaa raudan toteutusta koska muistioperaatio ja osoitteen laskenta on paketoitu. Jos ne pidetään erillään kuten RISC-ideologiaan kuuluukin rauta voidaan paljon helpommin valjastaa vaikka laskemaan tulevat osoitteet etukäteen kun koodissa itsessään on jo osoitteen laskenta ja itse latausoperaatiot eritelty.

 

[Sami Riitaoja]

Ja ei, prosessorin rauta ei voi mitenkään "toteuttaa ajossa vektorointia". Se, että spekulatiivisen suorituksen keinoin vähän interleavataan useampaa loopin iteraatiota ei ole mitään vektorointia, ja varsinaista vektorontia taas ei rauta voi järkevästi itse tehdä. Sen käskykannan pitää aina sisältää joku mekanismi jolla sanotaan, että nyt tämä asia tehdään vektorille, monelle data-alkiolle kerrallaan, ja määritellä rajapinta jossa jollain tavalla kerrotaan esim se, kuinka montaa alkoita käsitellään ja millaisella patternilla ne saadaan muistista ladattua ja sinne tallennettua jne. Rauta voi korkeintaan sisältää esim. muuttuvanleveyksisiä vektoreita tms., mutta ne vektorit pitää aina näkyä käskykannassa

GPU:t eivät selvästikään ole tuttuja...

Joo en takoittanut loopin iteraatioita vaan loopin vektorointia. Nykyprossut ovat VLIW-rakenteisia sisäisesti hyvin pitkälti ja useimmissa on myös loop-bufferit jotka löydettyään toistuvan kaavan voivat optimoida sisäisen datan pyörittelynsä aivan vapaasti. Jos rauta on löytänyt kaavat loopin ajoon se voi optimoida loopin iteraatiot myös samojen käskyjen vektoreiksi - jos ei muusta syystä niin säästääkseen energiaa. Jos käskykanta ja ajettava koodi valjastetaan mahdollistamaan tälläisen tehokas optimointi lopputuloksenaon mahdollista saada tehokasta koodia puhtaalla skalaariohjelmointina - ääripäänä esimerkkinä nykyiset GPU:t