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.
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.
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.
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.
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
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, hyvä jos testivideoita saatikka artikkeleita jaksavat katsoa. Ne jotka katsoo, todennäköisesti vertaa speksejä aika 1=1 logiikalla, sen syvemmälle pääsemättä.
Saisiko io-techiin vaikka vierailevan kirjoittajan toimesta artikkelin näistä eri mikroarkkitehtuureista? Etenkin RISC-V kattavempi esittely kiinnostaa.
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.
… 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.
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'
http://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ä…….
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…..
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.
edit: Ja se on minusta kotikäyttäjille arvokas ominaisuus että on sitä taaksepäin yhteensopivuutta.
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.
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ä toteutusta 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.
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 vektoroinia, 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
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 virheellsien tulkinnan Kellerin puheista) tässä esille.
Ei. Jälleen menee täysin päin vastoin.
Base+offsettia paremman osoitusmuodot on arkipäivää ihan kaikenlaisessa koodissa, ja nimenomaan se, että sellaiset käsky olisivat, mahdollistaisi sille paremman osoitusmuodon toteuttavalle käskylle monenlaisia eri 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 käskysekvenssin.
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.
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