Maailmalla tietokoneet ja puhelimet pyörivät pääasiassa Arm- ja x86-arkkitehtuureihin perustuvilla prosessoreilla. Viime vuosina avoin RISC-V on kuitenkin kehittänyt pöhinää ympärilleen etenkin SiFiven johdolla. Jopa x86-jätti Intel on tarttunut arkkitehtuuriin ja tulee tekemään SiFiven RISC-V-ytimiin perustuvia prosessoreita. Huhujen mukaan Intelin huhuttiin yrittäneen jopa ostaa SiFiven, mutta kaupat eivät ikinä realisoituneet.
Nyt SiFive on julkaissut uuden prosessorin, tai pikemminkin prosessori-IP:n integroitavaksi järjestelmäpiireihin. SiFiven uutuus tottelee nimeä Performance P650 ja se rakentuu parhaimmillaan 16 ytimestä. RISC-V-ydinten arkkitehtuuri perustuu vahvasti edeltävään P550-arkkitehtuuriin, mutta kasvattamalla käskyjaon leveyttä (instruction-issue width) ytimet ovat nyt 40 % nopeampia kellolta kellolle ja muiden arkkitehtuurin viilausten myötä käytännössä 50 % nopeampia.
Yhtiön arvioiden mukaan P650-ydin yltää yli 11 pisteeseen per GHz SPECInt2006-testissä, kun P550-ytimellä päästiin 8,65 pisteeseen per GHz. 16 ytimen voimin P650 sopii yhtiön mukaan nyt high-end luokan laskentatehtäviin ja tukee uutta RISC-V Hypervisor -laajennoksia virtualisointiin.
SiFiven mukaan se tulee aloittamaan Architecture Preview -esittelyt suurimmille asiakkailleen ensi vuoden ensimmäisen neljänneksen aikana. Yleisesti lisensoitavaksi ytimet tulevat vuoden puolivälin tienoilla. Yhtiö tulee kertomaan lisää uusista Performance P650 -ytimistä vielä RISC-V Summit 2021 -tapahtumassa 6.-8. joulukuuta.
Lähde: SiFive, Tom’s Hardware
… ja ARM Neoverse N1llä jo melkein 3 vuotta sitten 14 specINT20006/GHz.
Aika pahasti on RISC-V ARMia jäljessä. Eikä tule koskaan saavuttamaan, koska standardista RISC-V-käskykannasta puuttuu oleellisia suorituskyvyn kannalta tärkeitä asioita (mm. kunnolliset muistinosoitusmuodot ja ehdolliset siirrot), ja RISC-V-srandardointikomitea ei näitä suostu lisäämään koska ne on ”monimutkaistavia ja epä-RISCmäisiä”. Ja epästandardeille laajennoksille ei saa kunnollista käntäjätukea.
Ja SiFive itse vertaa tuota mm. yli 4 vuotta vanhaan Cortex A75een ja hypettää kuinka voittaa sen. ARMilta on vaan tullut monta sukupolvea A75sta uudempia ja parempia ytimiä (mm. Cortex A76, A77, A78) jotka eivät kuitenkaan ole merkittävästi isompia.
Kertoo aika paljon siitä kuinka hyvillä pohjilla mennään, kun pitää tehdä näin vinoon meneviä vertailuita.
Tuossa ylempänä @hkultala jo vähän antoi osviittaa siitä kategoriasta mihin nuo menevät.
Mutta rajoittamalla käskykannan kokoa ja kompleksisuutta saadaan pienemmät ytimet. Miten tuo sitten vaikuttaa energiatehokkuuteen, paraneeko vai huononee? Luulisi että tuo on tärkeä kriteeri jos näitä on suunniteltu tietyt sovelluskohteet mielessä. Pintapuolisesti tarkasteltuna minusta vaikuttaa, että näitä on suunnattu kustannustehokkaisiin ja pieniin laitteisiin, ei niinkään taistelemaan suorituskykykuninkuudesta.
Ei saada, paitsi silloin kun tehdään jotain äärimmäisen yksinkertaisia, pieniä ja hitaita ytimiä. Ja niissä esim. tuki RISC-V:n C-moodille (16-bittiä pitkät käskyt) aiheuttaa helposti paljon enemmän monimutkaistusta kuin ARMv8n muuten rikkaampi käskykanta.
Kun halutaan yhtään kunnollista suorituskykyä, jotta päästäisiin edes lähelle ARMia (ei tasoihin), RISC-V:ssä joudutaan tekemään aggressiivisemmin temppuja kuten käskyfuusio, ja se monimutkaisuus mitä näistä tempuista tulee on paljon suurempi kuin se monimutkaisuus, mikä tulisi siitä että se enemmän tekevä käsky löytyisi suoraan käskykannasta.
Osoitteenlaskenta + lataus joka ARMilla vaatii yhden käskyn ja kirjoittaa tuloksen yhteen rekisteriin ja RISC-Vllä vaatii joko 2 tai 3 käskyä ja kirjoittaa 2-3 rekisteriin vie RISC-V:llä aika paljon enemmän virtaa. Ylimääräisistä kirjoituksista kun ei tule pelkästään sitä itse rekisterin kirjoituksen virrankulutusta, vaan suorituskykyisemmällä ytimellä myös virrankulutus rekisterien uudelleennimeämisen kirjanpitotaulukon päivittämisestä, ja lisäksi saman suorituskykyyn tarvitaan suurempi määrä fyysisiä rekistereitä joihin arkkitehtuurillisia rekistereitä voidaan uudelleennimetä.
Tai toisinpäin, saman kokoisella fyysisellä rekisterifileellä ja samalla määrällä rekisterikirjoituksia ja rekisterien uudelleennimeämisiä ARM tekee enemmän hyödyllistä työtä.
Ja ehdollisten siirtojen/select-käskyn puuttuminen. Kun koodissa pitää valita hyvin satunnaisesti kahden arvon väliltä, ja kääntäjä tietää, että valinta on hyvin satunnainen, ARM-kääntäjä tekee siihen select-käskyn ja prosessori odottelee kunnes ehto lasketaan kunnes suorittaa tämän select-käskyn. (tai no, suorittaa ehkä muita, tästä riippumattomia käskyjä, jtoka piti joka tapaukessa suorittaa)
RISC-V-kääntäjä tekee tästä ehdollisen hypyn ja kaksi erillistä siirtokäskyä. ja kun koodia suoritetaan, haarautumisennennustus yrittää arvata, pitääkö hypätä vai ei, ja jos se arvaa oikein, kaikki sujuu kauniisti ja kivasti. Mutta jos arvataan väärin, prosessorin liukuhihnalle on jo ehditty ladata kymmeniä käskyjä väärästä paikasta ja laskea jotain väärällä tuloksella, ja kaikki tämä (joka on jo kuluttanut selvästi virtaa) pitää heittää menemään ja aloittaa koodin suoritus siitä oikeasta haarasta => paljon turhaa virrankulutusta.
Ja mikäli tämä valinta on todella satunnainen, se haarautumisenennustus ennustaa väärin 50% tapauksista.
Molempien ominaisuuksien suhteen virrankulutusetu on aika selvä prossulle, jossa ilmaisuvoimaisempi käskykanta.
RISC-V-käskykanta on suunniteltu yksinkertaiseksi käskykannaksi opetuskäyttöön, ei mihinkään laitteisiin. Se eroaa aiemmista DLXstä yms opetuskäyttöön suunnitelluista lelukäskykannosita lähinnä kahdella tavalla:
1) Se tukee virtuaalimuistia, keskeytyksiä yms. ominaisuuksia että sen päällä voi (lähinnä opetuskäytössä) ajaa todellista käyttöjärjestelmää, sitä voi käyttää muidenkin asioiden opetukseen kuin tietokonearkkitehtuurien perusteiden opetukseen.
2) Siitä on poistettu 1980-luvun RISCien suurimmat typeryydet kuten delay slotit
Koko RISC:in idea on olla mahdollisimman yksinkertainen käskyjoukko. Reduced Instruction Set Computer…. "Pienten lisäysten" jälkeen ollaan jo ensimmäisiä x86-arkkitehtuureja vastaavissa käskyjoukoissa.
Ei. Tällä ei ole oikeasti mitään tekemistä käskyjen määrän vaan monimutkaisuuden kanssa.
RISCin idea on olla helposti liukuhihnoitettava käskykanta.
Tämä tarkoittaa mm. sitä, että
1) Käskydekoooderi on mahdollisimman yksinkertainen
1.1) Rekisterikentät ja opkoodit on käskykanassa aina mahdollisimman samassa paikassa (mahdollisimman vähän eri käskyformaatteja)
1.2) Ei muuttuvanmittaisia käskyjä (arvaa, kumpi tätä rikkoo, RISC-V tyypillisellä konfiguraatiollaan vai ARMv8?)
2) Sama käsky ei sekä laske että käsittele muistía, vaan lataus ja laskenta tehdään erillisillä käskyillä
3) Mitään käskyjä ei tarvi kierrättää liukuhinan perusosien läpi montaa kertaa
Ei todellakaan olla.
Jo alkuperäisessä 8086-käskykannassa on monia kymmeniä eri käskyformaatteja, ja ties mitä desimaaliaritmetiikkaa ja hyvin pitkään ajautuvia erikoskäskyjä muistin kopioinnille tai muistin alustamiselle vakiolla.
Se, että lisätään järkevät osoitusmuodot sekä select- käsky tai ehdollinen siirto tarkoittaa n. kolmea käskyformaattia lisää kokonaislukupuolelle, ja kun laskee liukulukukäskyt mukaan niin kokonaisuudessaan ehkä n. kuutta
Toisaalta, RISC-V:n hyvin yleinen C-moodi lisää n. 12 käskyformaattia lisää, eli luokkaa tuplasti enemmän kuin mitä noista suorituskyvyn kannalta oleellisimmista (mutta RISC-V:stä puuttuvista) tulisi.
Että niiden järkevien osoitusmuotojen ja selectin käskykanta monimutkaistava vaikutus on ziljoona kertaa pienempi kuin x86-käskykannan monimutkaistus ja selvästi pienempi kuin RISC-V:n C-moodin käskykantaa monimutkaistava vaikutus.
..mutta tuli taas semmoinen määrä tekstiä, että pitää tarkemmin katsoa paremmalla ajalla viikonloppuna.
Ehkä vähä höhlä kysymys/ajatus, mutta jotenkin pitänyt teikäläisen (@hkultala) jutuista jo murobbs ajoista ja varsinkin et olet _suomalaista_ insightia piirisuunnitteluun tuonut julki. Ei sillään mitään @Diizzel ja @Kaotik vastaan tai oli tällä viikolla todella hyvä tekniikka podcasti tai mikä se nyt onkaan nimeltään, mutta kun alettiin RISC-V uudesta piiristä höpisee nii aika vähäiseksi jutut jäi. Tai olisiko ihan mahdoton ajatus et hkultala haluaisi youtubes/podcastissa vähä ""blastata"" faktoja uutisiin tai tällästä ku mennään syvällisiin aiheisiin? Vai onko tämä sitte vähä sellasta osa-aluetta ettei massoja kiinnosta ja parempi tästä "foorum-mössöstä" syödä? Toki joo jossei herraa itse kiinnosta missä youtubes höhlistä niin ei
.
Onkos toi nyt järjetön ongelma et RISC-V on jotain ARM high-endiä jäljessä? Tai etkös jossain Alder lake-uutisessa huudellut et Intelin pitäisi enemmän heittää lastulle gracemont-ytimia ku palvelinympäristössä ehkä olis vähä optimaalisimpaa olla paljon pienempi ytimiä. Varsinki jos jotain kubeklusteria joutuu itse pyörittää "microserviceille" ehkä sopeutuu tohon malliin paremmin, että paljon energiatehokkaita ytimiä. Toki jo ARM64/Armv8 tuki ollut vähä jähmeetä monessa high-end kielessä. Et ei ehkä siinä mielessä RISC-V nappaa ollenkaan. Ja toki tietyillä kuormilla kuten tietokantojen, ML, video-pakkaus/purku tai jossai tälläisessä missä halutaan kenties FP-suorituskykyä tai ihan yhdenki ytiminen suorituskykyä mitä RISC-V ei hetkeen tarjoa, mutta tietyissä käyttötapauksissa ei välttämäti ihan lapanen olisi. Tosi Amazonill se verta kova investointi jo omiin armeihin (Graviton 3 taisi juuri tulla ulos), että tuskin kenelläkään oikein on tuohon skeneen resursseja tuoda mitään RISC-V lastuja ihan hetkeen (toki joo jossai azure/gcn/etc yms IO-piireissä tai missä tahansa saattaa olla jtn customia mutta mitä end-userille tarjolla on lähinnä x86 ja ehkä armv8).
RISC-V kuuluu aiheisiin "ei kiinnosta massoja". Puolustuksekseni lisäisin että uskoisin osaavani kertoa hkultalaa syvällisemmin (psykiatrisesta) sairaanhoidosta
Selvä homma
Eiköhän sielläkin kuule kaikenlaista syvällistä tai ehkä en nyt tuollaista tarkoittanut. Ihan kiva silti et uutisissa jaksaa olla vähän teknisempääkin tauhkaa tuotejulkistuksien, huhujen, ajuriuutisisten yms välissä ihan näin etusivullakin. Ja et eräät jaksaa vieläkin sivistää vuosien jälkeen kommenteillaan
no tuo on Von Neumann kone, jonka käskykanta tukee sitä että ihminen ohjelmoi sitä suoraan konekielellä. Suhteellisen kaukaa haettu vertaus.
Itseäni kiinnostaa enemmän arkkitehtuurin aito avoimuus ja räätälöintimahdollisuudet.
Mitä ihmettä nyt oikein sekoilet?
Ymmärrätkö yhtään, mitä sana "käskyformaatti" tarkoittaa?
En puhunut mitään vertauksia vaan ihan suoria faktoja RISC-V- ja x86-käskykantojen eroista.
Vaikea sanoa. Yleensä kun yrittää jotain keskustella menee sinun vastauksesi henkilökohtaisuuksiin. Oletan että haet sitä että konekäskyillä on erilaisia osoitusmuotoja ja eri määriä operaation parametrejä. Ei se muuta sitä että ARM ja RISC-V on tehty korkeamman tason kielet mielessä kun taas alkuperäinen x86 kanta suunniteltiin ihmiselle helpoksi mieltää. Vaikka suoraa yhteyttä RISC ja Harward, CISC ja Von Neumann ei olekaan niin usein ISA sitä heijastelee.
Minulle oleellista RISC-V arkkitehtuurissa on riittävä suorituskyky ja mahdollisimman yksinkertainen SoC rakenne nykyään on hyvin vaikea löytää IoT tai teollisuus/ajoneuvokäyttöön soveltuvia piirejä ilman mitään ylimääräisiä oheispiirejä. Toiveissa olisi että tälle alustalle moisia saisi räätälöityä.
Se, että kysyn, oletko ymmärtänyt teknistä termiä oikein ei ole henkilökohtaisuuksiin menoa, kun lauot aivan käsittämättömia aiheeseen täysin liittymättömiä kommentteja.
Juu, oikein meni.
Tällä käskyformaattien määrällä ei ole mitään tekemistä sen kanssa, miten sitä ohjelmoidaan. Että se, että tuot tähän mukaan jotain "korkeamman tason kieliä" ja "ihmiselle helposti miellettävää" on ihan täyttä sekoilua.
Edes asmia koodaava koodarikaan ei niitä käskyformaatteja näe, koska assembly abstrahoi ne pois, ja asm-koodari joutuu niistä piittaamaan ainoastaan jos alkaa käsin optimoimaan koodin kokoa (eikä suorituskykyä) jolloin se, että siellä on paljon erilaisia käskyformaatteja on vaan hankaloittava tekijä sille asm-koodarille.
Käskyformaatien määrässä kyse ihan täysin siitä,
1) kuinka monimutkainen se prossun käskydekooderi on ja kuinka helpolla tiedetäään mistä seuraavan käskyn dekoodaaminen tai hakeminen pitää aloittaa.
2) kuinka paljon käskymuistia koodi vie.
3) mahdollistaako käskyformaatit tiettyjen käteviä asioita tekevien käskyjen toteutuksen vai joudutaan jotkut kätevät (suorituskykyä parantavat/virrankulutusta pienentävät) käskyt jättämään pois jottei niille tarvi tehdä omaa käskyformaattia.
Verrattuna ARMv8iin, RISC-Vssä on jätetty pois select/cmov sekä järkevät osoitusmuodot ettei niille tarvi tehdä pientä määrää uusia käskyformaatteja, mutta kuitenkin RVC tuo paljon suuremman kasan uusia käskyformaatteja.
Sillä, onko käskykanta RISC-V vai ARM ei ole mitään käytännön vaikutusta siihen, millaisia väyliä sieltä prossulta voidaan vetää ulos, ainakaan RISC-V:lle edulliseen suuntaan. Käytännössä sitten kun mennään debuggauspuoleen jne. niin niille ARMilla on parempi infrastruktuuri kuin RISC-V:lle.
Että se RISC-V CPUna ei ainakaan käytännössä helpota minkään järkevän SoCn tekemistä ARMiin verrattuna. Toki, jos halutaan tehdä kouluprojektina minimibudjetilla joku lelu, eikä haluta maksaa penniäkään lisensimaksuja ARMille, sitten RISC-Vssä on pointtinsa. Rankasti kustomoidun RISC-Vn käyttö pohjana ASIPille onkin sitten jo järkevämpää, mutta silloinkin sinne piirille kannattaa laittaa joku ARM CPU:ksi.
Ja "riittävä suorituskyky" on aika tulkinnavaraista/suhteellista. ARMilla saadaan joko parempi suorituskyky, tai sama suorituskyky pienemmällä virrankulutuksella tai pinta-alalla.
Voi huoh.
Sen SoC-piirin käskykanta ei vaikuta sen SoClle koodia kirjoittavan C-koodarin normaaliin työhön käytännössä millään muulla tavalla kuin sillä, mikä parametri sen ristiinkääntäjän target-flagiksi annetaan (tai siis annetaan configure-scriptille, joka kirjoittaa sen makefileeseen). Koska se kuitenkin kirjoittaa C-koodia, ei mitään asmia.
Ohjelmointimalli siten miten se näkyy Ctä koodaaavalle koodarille on täysin identtinen ARMin kanssa.
Että jos tuo on näkökulmasi, niin sinulla ei pitäisi olla mitään kiinnostusta koko käskykantaa kohtaan.
Sen sijaan se käskykanta oikeasti vaikuttaa sen piirin CPUn suorituskykyyn ja koodin kokoon.
RISC-V on CPU-käskykanta. Se soveltuu siihen, että sille käännetään koodia, ja että suunnitellaan mikroarkkitehtuureita, jotka sen toteuttavat. Se on turing-täydellinen, sillä voi suorittaa ihan mitä tahansa koodia, kunhan vaan muisti riittää. Ratkaisevaa on se, että onko se suorituskyvyn kannalta järkevää.
Jos mietitään korkean tason käyttökohteita(mitä ilmeisesti ajat takaa), eivät ne piittaa siitä, mitä käskykantaa kaukana alla olevassa prossussa käytetään, paitsi että sen alla olevan prossun suorituskyky-pitna-ala-energiankulutus-suhde olisi mahdollisiman htvä. Mitä se RISC-Vllä CPU-käytössä ei ole, eikä siihen vaikuta se, onko se piiri autossa, lentokoneessa, pesukoneessa, puhelimessa, läppärissä vai pöytäkoneessa.
kysyä voi monella tapaa. Alkuperäinen kommentti liittyi siihen että 8086 ISA on suunniteltu aivan eri käyttötapaan kuin mitä nykyään pidetään normina. Kovin paljon en x86 assyä ole kirjoittanut mutta riittävästi että se on ainakin itselleni paljon mukavampaa kuin ARMv7 kirjoittaminen.
8086 käyttäminen vertailukohtana on lähinnä alentuvaa alkuperäisen postauksen kirjoittajaa kohtaan.
Kyllä ja sen takia mielenkiintoisempaa olisi vaikka tietää mitkä RTOS alustaa tukevat ja tuleeko SiFive lisäksi muita piirivalmistuttajia. Itse ainakin pidin siitä että voit käydä ruksimassa sivulta halutut ominaisuudet piiriin ja saada juuri sellaisen SoC kun tarttee.
Uutisen oleellinen anti minulle on että uusin ydin 50% nopeampi kuin lutikka joka tuosta kehityskitistä löytyy. Auttaa siinä että pystyy arvioimaan miten kyseinen piiri soveltuu tuotteisiin joita firma suunnittelee julkaisevansa seuraavan kymmenen vuoden aikana.
Itse olen kirjoittanut jonkin verran sekä 16-bittistä 80286-assyä että 32-bittistä 386+mmx+3dnow(K6-2)-assyä, ja tuijottanut paljon RISC-V-assyä ja omasta mielestäni se RISC-V -assy on kyllä paljon ymmärrettävämpää/helpompaa kuin x86-assy.
Ne muinaiset CISC-käskykannat eivät todellakaan olleet sellaisia mitä ne olivat jonkun "assy-ohjelmoinnin helppouden" takia, vaan ihan tasan sen takia, että säästettiin käskymuistia joka oli kallista.
Ei ole, vaan se on suora vastaus alkuperäsieen kommenttiin:
Että melkoista puolestaloukkaantumista/typerää syytteluä sinulta
Tämä on vain pelkästään hyvä tieto. Kiitoksia tästä. Oma kokemus rajoittuu toistaiseksi RISC-V ohjelmoinnin osalta vain C esimerkkeihin.
mielenkiintoinen kulma, varmasti osatekijä. Sinällään Von Neumann koneissa ei erotella käskyjä datasta, joten tarkempi kuvaus lienee ohjelman viemä tila muistista.
Joskus linkki vastaa tuhatta sanaa IBM100 – RISC Architecture