Qualcommilla on vankka sija suorituskykyisten mobiilijärjestelmäpiirien rintamalla, mutta nyt yhtiö aikoo tähdätä tosissaan myös tietokonemarkkinoille. Aivan uudesta ideasta ei sinänsä ole kyse, sillä yhtiöllä on jo PC-käyttöön suunnattuja järjestelmäpiirejä, mutta aivan eri teholuokassa kuin uudet suunnitelmat.
Qualcommin mukaan PC-markkinoiden siirtyminen x86-arkkitehtuurista Arm-arkkitehtuuriin on väistämättömissä oleva tulevaisuus. Yhtiön mukaan se aikoo haastaa tulevaisuudessa sekä AMD:n, Applen että Intelin suorituskykyiset järjestelmäpiirit.
Yhtiön suunnitelmien ytimestä löytyy Qualcommin aiemmin tänä vuonna ostama Nuvia ja sen Phoenix-prosessoriytimet tai niiden jatkokehitelmät. Nuvia esitteli suunnitelmiaan täysin puhtaalta pöydältä suunnitellulle Phoenix-ytimelle jo loppukesästä 2020 ja silloin Googlen ja Applen entisten insinöörien perustama yritys kehui ydinten tarjoavan jopa lähes kaksinkertaista yhden säikeen suorituskykyä silloisiin x86-ytimiin verrattuna selvästi pienemmällä tehonkulutuksella. Qualcommin mukaan Nuvian ytimet on suunniteltu nimenomaan PC-käytössä tyypillisille kuormille.
Tulevan PC-järjestelmäpiirin Adreno-grafiikkaohjaimen luvataan tarjoavan tarkemmin määrittelemättä ”erillisnäytönohjainluokan suorituskykyä” ja johtavaa energiatehokkuutta. Myös AI Engine -kiihdyttimen luvataan olevan markkinoiden energiatehokkain päättelylaskuissa (inference). Mukana ovat myös mobiilijärjestelmäpiireistä tutut 5G-modeemit, Wi-Fi- ja Bluetooth-yhteydet, tuki paikannuspalveluille, huippuluokan Spectra-kuvaprosessori sekä kenties hieman hassusti tässä yhteydessä luokassaan parasta Android-kuvanlaatua tarjoava näyttö- ja mediayksiköt.
Qualcommin mukaan se aikoo toimittaa ensimmäiset kannettaviin tietokoneisiin tarkoitetut sampleprosessorit asiakkailleen ensi vuoden elokuussa. Markkinoille uuden sukupolven PC-järjestelmäpiiriin perustuvia laitteita voidaan puolestaan odottaa vuoden 2023 puolella.
Lähteet: Tom’s Hardware, Andreas Schilling @ Twitter
x86:sta ARMiin ja polttomoottoriautoista sähköautoihin.
Mikäs siinä jos yhteemsopivuus taaksepäin on 100% x86 tasolla.
Mikäs siinä, kunhan ovat ostaneet Inteliltä lisenssin x86-tekniikalle.
Uutisessa
Jollain Chromebook rintamalla tuskin tarvii kovasti murehti x86 yhteensopivuudesta.
Micorosoftilla Windowssin osalta ymmärettävästi enemmän kiinnostusta, sillähän on niitä ARM harjoituksia ollut, josta kai viimeiset tuota jotenkin hanskas.
Osassa windows käyttöä ne raskaimmat ohjelmat on noiden harjoutusten myötä ARM tuellisena saatavana (tai mahdollista saattaa), joten x64 tueksi voi riittää se että ne satunnaiset ohjelmat toimii.
Mutta jos Windows puolella jää muutaman vuoden välein tehtävään Microsoft kokeiluun, niin winkkarilla jää tahmeaksi, vaan jää Googlen varaan.
Näissä puheissa varmaan luotetaan siihen, että pilvialustat ja ohjelmat valloittavat tulevaisuudessa. Jos koneen täytyy oikeastaan pyörittää ”vain” selainta, niin silloin rautana voi varmaan olla vaikka mitä.
Mutta onko silloin moninkertaisella suorituskyvyllä paikallisessa laskennassa enää niin paljon väliä? Luultavasti energiatehokkuudesta tulee merkittävämpi homma siinä vaiheessa. Esim. eihän kukaan vertaile rannekellojen tai taskulaskinten tehoja… niiden odotetaan vaan tekevän hommansa ja pysyvän pitkään päällä ilman murheita. Ehkä tulevaisuudessa paikallisilta laitteilta aletaan odottaa samaa.
Heillä edelleen sama uskottavuus-ongelma kuin Intelin näytönohjain-osastolla, show us the beef !
Tehoa ei nyt niin valtavasti tarvitsisi, mutta pientä virrankulutusta ja pientä lämmöntuottoa kyllä. Jos saisi vielä pienemmän ja kevyemmän läppärin jossa akku kestäisi kuitenkin monta päivää ja riittävillä tehoilla niin ostaisin kyllä heti.
Microsoftin osalta odotus sitten edelleen jatkuu, että arm-windows saataisiin oikeasti toimivaksi ja hyväksi. Chromebookit ja linux-koneet kun on kuitenkin niin pieni osa, että niillä ei ihan lähitulevaisuudessa valloiteta maailmaa. Toisaalta MS haluaa varmasti kilpailla lujasti Googlea, Steamia ja muita vastaan ekosysteemien taistossa, niin jos tulee ylivertaista rautaa, MS haluaa saada sille raudalle myös toimivan Windows-ympäristön ettei Windows jää uusien tekijöiden varjoon ja kuihdu vanhojen höyrykoneharrastajien kuriositeetiksi.
No joo, 30 vuotta sitten käännetty binääri on 16-bittistä eikä ne toimi 64-bit Windowseissa. Et ei silleen oikeen Wintel-maailmakaan siihen pysty.
Luetaan mihin vastataan. Freedos ajaa ihan hyvin vanhoja DOS binääreitä nykyisillä raudoilla.
Nyt meni väärin. Windows ja x86 maailmaa hidastaa laaja lupaus taaksepäin yhteensopivuudesta. Applella ei moista ongelmaa ole koskaan ollut.
Kuulostaa hyvältä. Useampi toimija on aina markkinoiden kannalta etu.
Applen etu softakehittäjien näkökulmasta on lupaus yhteynäisestä arkkitehtuurista. Intel saa lähteä ja heidän oma ARM-pohjainen arkkitehtuuri tulee kaikkiin laitteisiin. Softatalot voivat käytännössä alkaa himmailemaan Intel-pohjaisen softan kanssa ja painaa täydellä höyryllä ARM-softaa, koska he tietävät, että se on Applen puolella tulevaisuus.
Microsoft on tehnyt näitä ARM-viritelmiä jo kohta 10v aina Win8 RT:n julkaisusta lähtien. Vaikka tarjolla oleva rauta olisi kuinka hyvää, niin meillä on silti sama epävarmuus, että ottaako kyseinen käyttisversio tuulta siipiensä alle. Tämä näkyy hyvin siinä, miten vähän Winkkarin ARM-versioille löytyy isojen softatalojen tuotteita. ARM-arkkitehtuurin pitäisi myydä itsensä läpi yrityksissä, jotta maksavaa käyttäjämassaa saataisiin tarpeeksi. Yrityksissä Winkkaria taas käytetään juuri sen yhteensopivuuden takia.
30-vuotta vanhaa binääriä voi ajaa ARM-koneessa käskykantaemulaattorilla tai binänäärikääntäjällä, koska se 30 vuotta vanha binääri ei tarvi suurta suorituskykyä.
Ja se 30 vuotta vanha 16-bittinen binääri ei 64-bittisessä windowsissa x86-64-alustallakaan toimi ilman sitä emulaattoria/binäärikääntäjää, koska 16-bittinen v86-moodi ei ole tuettuna 64-bittisen windowsin alla.
Eli esim. kaikki ne steamissa olevat 16-bittiset DOS-pelit (jotka on paketoitu Dosboxiin) toimii ARM-prossulla ihan samalla tavalla kuin modernilla x86-64-prossulla.
Oleellisempi juttu on se 5-10 vuotta vanha binääri kuin se 30 vuotta vanha binääri. Se 5-10 vuotta vanha binääri voi vaatia suorituskykyä, jota emuloimalla/binäärikääntämisellä saavuteta.
Tyypillinen softa ei vaadi välttämättä yhtään riviä muutoksia kun se siirretään x86lta ARMille, se vaatii vaan sen, että kääntäjää ajetaan ARM-alustalla joka defaulttaa tekemään ARM-käännöksen.
Sitten jos tehdään ristikäännöstä, pitää säätää vähän enemmän, ja vasta jos ruvetaan tekemään esim. jotain matalan tason SIMD-optimointeja, tarvii alkaa oikeasti piittaamaan merkittävästi käskykanta-arkkitehtuurista.
Todella paljon suurempi ero softalle on siinä, millä käyttiksellä se tehdään toimimaan kuin siinä, mille käskykannalel se käännetään.
Ongelma on siinä, että mikkisoftan ARM-windowsit on tähän asti olleet kripplattua kuraa joista on tarkoituksella jätetty ominaisuuksia pois. ARM-windows ei ole ollut "tasaveroinen" x86-windowsiin verrattuna vaan lähinnä sellaista "tarjotaan tätä nyt johonkin halpistabletteihin"-puuhastelua.
Mutta sitten hinta on pitänyt saada alas että se tablettivalmistajalle kelpaa, mutta toisaalta ollaan pelätty, että jos tarjotaan siihen halpaan hintaan täyttä windowsia täysillä ominaisuuksilla, ei voida perustella normaalin x86-version paljon kalliimpaa hintaa, joten siitä on sitten kripplattu ominaisuuksia jotta se ei kelpaisi normaalin tietokoneen kunnolliseksi käyttikseksi, vaan ne jatkaisivat suuremman hinnan maksamista siitä x86-versiosta.
Eli markkinapoliittista pelleilyä ja puuhastelua.
Tämähän se tärkein pointti on miksi ARM on ottanut, ja ottaa aina vain isomman, siivun palvelun puolella. Suurin osa uusista pilvipuolen frameworkeistä ja palveluista koodataan kielillä, jotka pyörivät interpreterin kautta jolloin ei ole enää väliä ajataanko serverillä ARM:a vai x86:aa (tai jotain muuta). Esim. omalla työnantajalla ollaan korvattu matalalla tasolla x86 EC2 -instansseja Graviton-pohjaisilla koska pienemmät kulut. Suurin osa palveluista ei kuitenkaan ole suorityskykykriittistä ja kaikki käytetyt fw:t ovat java, python tai js-pohjaisia.
Korkean tason AWS-palveluista todennäköisesti suuri osa pyörii jo muutenkin Gravitoneilla. Joka on sitten toinen pointti, eli minua ei asiakkaana kiinnosta muu kuin palvelun kokonaistehokkkuus, ei se pyörittääkö Amazon noita x86:llä vai ARM:lla. Amazonia se taas kiinnostaa kovasti. Amazonin liikevaihdolla omien piirien suunnittelussa on jo paljon järkeä.
Suurin ongelma binäärikäännöksestä tulee muistioperaatioiden (uudelleen)järjestelysäännöistä, jotka ARMissa ovat erilaiset, löysemmät, kuin x86ssa.
On riski, että softa toimii väärin, jos prossu uudelleenjärjestelee muistiaccesseja tavalla, joka ei ole sallittua, joten binäärikäännöksen yhteydessä voidaan joutua lisäämään ylimääräisiä synkronointikäskyjä jotta ohjelmat varmasti toimivat oikein. Ja näistä synkronointikäskyistä tuleva hidastus voi olla huomattava.
Apple on ratkaissut tämän siten, että Applen M1-prossussa on uusi toimintatila, joka käskyenkoodaukseltaan on ihan normaali ARMv8, mutta jossa muistioperaatioden järjestelysäännöt on samat kuin x86ssa. Kun sillä ajetaan x86-koodista binäärikäännettyä koodia, sitä ajetaan tässä toimintatilassa, eikä suurta määrää ylimääräisiähidastavia synkroknointikäskyjä tarvi lisätä jotta x86sta binäärikännetty koodi toimii kaikissa tilanteissa oikein.
En vielä tiedä, onko Nuvian ytimissä vastaava toimintatila; Nuvian porukastahan huomattava osa on ennen ollut Applella töissä, eli jos tuota on Applella mietitty jo silloin kun tämä porukka oli Applella, voi sama löytyä Nuvialta. TÄmä on kuitenkin standardoinnin kananlta ongelma, koska käsittääkseni tuo Applen toimintatila on ihan epästandardi eikä osa mitään ARMin standardia.
Ilman tätä muistioperaatioden järjestyksen yhtensopivuustilaa binäärikäännöksestä x86-ARM koituu käytännössä huomattava (>2x) hidastus, mutta sen kanssa overhead voi jäädä melko pieneksi (10-30% luokkaan)
Meillä on ainakin ollut ongelmia ARMv7 kanssa siinä että legacy softassa on pack/alignment jotain muuta kuin kahdeksan tavun linjauksella. Hienointa on että koodi toimii toistaiseksi millä tahansa x86 koneella, mutta kaatuu bus error poikkeuksella ARM:llä. Silloin kun on kyse sovellusalasta jossa elinkaari on puoli vuosisataa tai edes kymmenen vuotta niin jatkuvuus on merkittävämpää kuin suorituskyky.
ARMv8 tukee unalignoituja muistiaccesseja.
Kaikki datatyyppien koko- ja alignointisäännöt on 64-bittisellä ARMilla täysin identtisiä x86-64een verrattuna (samalla käyttiksellä), että niistä/mistään datan layouttiin liittyvästä ei 64-bittisellä ARMilla tule mitään yhteensopivuusongelmia. (sen sijaan x86-64n sisälläkin windowsilla on erilainen longin koko kuin muilla järkevämmillä käyttiksillä, että näitä ongelmia voi tulla ihan samalla prossuarkkitehtuurilla kun softaa portataan windowsin ja muiden käyttisten välillä)
Jos aasi -malli on millä mennään, niin tämä pitää täysin paikkansa. Tuotteissa on hankaa esimerkiksi second sourcing kun mikään ei oikein ole enää täysin vaihtokelpoista keskenään.
Puhe oli ARMv7 joka on 32bit. Päteekö muistinosoitustuki ARMv8 Aarch32 myös ja vaatiiko jotain samaa kenkälusikointia kuin interwork tila ARMv7 maailmassa?
Tämä säie puhuu Nuvian ytimistä jotka on kaikki 64-bittisiä ARMv8-ytimiä. Se, että tuodaan esille (väärin konfatun) ihan eri arkkitehtuurin ongelmia jostain 15 vuoden takaa on täysin irrelevanttia tämän säikeen keskustelun kannalta.
Ja ARMv7:ssa unaligned accessien tukeminen tai tukemattomuus on konfiguraatiobitti. Speksi vaatii, että rauta tukee sitä, mutta rautatuki voidaan kytkeä pois päältä, siellä on ominaisuus että voidaan laittaa heittämään poikkeus. Eli kuulostaa siltä, että olet koodannut softaa prossulle, joka on (käyttötarkoituksiisi) väärin konfattu.
Tämä säie puhuu Nuvian ytimistä jotka on kaikki 64-bittisiä ARMv8-ytimiä. Se, että tuodaan esille (väärin konfatun) ihan eri arkkitehtuurin ongelmia jostain 15 vuoden takaa on täysin irrelevanttia tämän säikeen keskustelun kannalta.
Ja ARMv7:ssa unaligned accessien tukeminen tai tukemattomuus on konfiguraatiobitti. Speksi vaatii, että rauta tukee sitä, mutta rautatuki voidaan kytkeä pois päältä, siellä on ominaisuus että voidaan laittaa heittämään poikkeus. Eli kuulostaa siltä, että olet koodannut softaa prossulle, joka on (käyttötarkoituksiisi) väärin konfattu.