Erinomainen postaus. Täydet pisteet siitä. Olennainen ongelma on kuitenkin se, että oli teoria mitä tahansa, niin käytännössä X86 on edelleen nopeampi.
Tällä hetkellä kyllä, >4 watin teholuokassa.
Mutta yritit väittää jotain että "x86 tulee pysymään aina edellä". Sellaiselle väitteelle ei ole mitään teknistä pohjaa/perusteluita.
Kannattaa myös muistaa, että ARM ei ole ensimmäinen X86 arkkitehtuuria haastava. Niitä on ollut monta muutakin vuosien mittaan. Ja ne olivat kehittyneempiä ja osa jopa nopeampia kuin silloiset X86 prosessorit. Osalla niistä oli myös huomattavat taloudelliset resurssit takanaan (esim. Itanium). Kysymys kuuluukin miksi ARM onnistuisi siinä mitä monet muut ovat yrittäneet vuosikymmeniä ja epäonnistuneet?
Mitä niitä sinun mielestäsi on ollut?
Se, että edes mainitset tässä Itaniumin kertoo kyllä melkoisesta pihalla olemisesta arkkitehtuurien suhteen.
Itanium oli yksinkertaisesti todella huono ja CPUksi täysin vääränlainen arkkitehtuuri.
Jo vuosina 1995-1996 oli julkaistu neljä eri OoOE-CPUta (mm. Pentium Pro ja 21264 Alpha) jotka erinomaisella suorituskyvyllään todistivat superskalaarin OoOE:n olevan oikea kehityssuunta ja VLIWin olevan väärä kehityssuunta; Niissä saavutettiin käytännössä kaikki ne hyödyt mitä VLIW/EPIC yritti tuoda ilman VLIWin/EPICin vaatimaa maagista yksisarvikääntäjää ja sen lisäksi ne soveltuivat paljon paremmin odottamattomiin tilanteisiin ja niiden koodinkoko oli selvästi tiheämpi.
Itaniumin hypejuna oli kuitenkin lujassa vauhdissa, kääntäjäporukat lupasivat tekevänsä sen maagisen yksisarvikääntäjän ja näitä uskottiin, ja se saatiinkin toimimaan 10 käskyn koodipätkille joista kirjoiteltiin hienoja tieteellisiä papereita, ja firmojen johtoportaassa oli tyyppejä jotka eivät ymmärtäneet tekniikasta mitään ja tämä meni täydestä, joten itaniumin puskemista jatkettiin. (mutta samalla jatkettiin myös x86n kehitystä). Tosimaailman ohjelmat vaan ovat huomattavasti pidempiä kuin kymmenen käskyn mittaisia.
Ja itaniumilla lähinnä tapettiin noita isoja RISC-prossuja pelkällä pelotevaikutuksella. MIPS ajettiin high endista pois pelkkiin verkkoreitittimiin, ja Alpha ja PA-RISC tapettiin ja ne korvattiin hitaammilla Itanium-prossuilla.
Ja muita x86n haastajia on ollut lähinnä 68k ja PPC, molemmat motorolan projekteja.
68k oli aivan liian CISC, sitä oli hankala liukuhihnoittaa johtuen esim. kaksinkertaisista epäsuorista osoitusmuodoista. X86n kanssa kävi tuuri, siinä ei ollut mitään liukuhihnoituksen kanssa samalla tavalla hankalaa, vaikka sitä alunperin specsatessa liukuhihnoitusta ei oltu otettu huomioon. Tämä mahdollisti 486n, Pentiumin ja P6n helpon kehittämisen, siinä missä motorolalle 68040 oli selvästi ongelmallisempi piiri eikä saavuttanut kovin suuria kellotaajuuksia.
Lisäksi motorola mokasi aivan täysin 68k:n jatkomallien PRn/markkinoinnin. Markkinoilla olisi ollut kysyntää nopeammille 68k-sarjan prosessoreille niin motorola suureen ääneen julisti tappavansa arkkitehtuurin ja korvaavansa sen powerPCllä. Lopulta 68060 kuitenkin saatiin tehtyä, mutta siinä vaiheessa arkkitehtuuri oli jo julistettu kuolleeksi, asiakkaat kadonneet ja 68060stä valmistettiin melko pieniä määriä.
Ja kukaan ei tosissaan yrittänyt tehdä x86->68k-binäärikäännintä. Tekniikka ei ollut vielä valmis tähän, ja arkkitehtuurit käyttivät eri tavujärjestystä(endianness) mikä olisi tehnyt siitä ongelmallisen.
PowerPC sitten taas..
Motorolalla oli valmistusongelmansa, ja Motorola onnistui myymään PPC:tä moneen tutkaan yms. sotilaskäyttöön. Näihin optimaaliset prosessorit olivat kuitenkin selvästi erilaisia ominaisuuksiltaan kuin mitkä olivat optimaalisia CPUksi pöytäkoneeseen, ja motorolan PPC:t alkoivat jäädä intelille suorituskyvyssä jälkeen.
IBMää taas olisi tyrkyttänyt PPC-koneille käyttikseksi Workplace OS:ää ja OS/2sta. Jonkinlaista x86-emulaatiota oli tulossa, mutta tämä oli nopeudeltaan aivan eri tasoa kuin nykyiset binäärikäännöstekniikat, eikä näissä pyörinyt windows 9x.
PowerPC ei siis missään vaiheessa tarjonnut todellista "drop-in-replacementtia" x86lle.
Apple jatkoi vielä jonkin aikaa PPCn käyttöä, mutta IBMää alkoi enemmän kiinnostaa vain omien järeiden PPClle sukua olevien POWER-prosessoreiden tekeminen, ja muutamat IBMn PPC-prosessorit olikin sitten melko tehokkaita "kevytversioita POWER-prosesoreista". Ongelma näissä vaan oli että ne eivät sitten virrankulutukseltaan sopineet kannettaviin, ja apple tarvi suorituskykyisiä prosessoreita kannettaviin, eikä halunnut valita hitaan mutta vähävirtaisen motorolan ja nopean mutta liian virtasyöpön IBMn välillä.
Kaikenlaista x86-emulaatiota PPCllä hidasti ja haittasi myös se, että PPC on natiivisti big endian, ja sen little-endian-tuki oli/on epämääräinen kludge. x86 ja ARM taas ovat luonnollisesti little-endianeita(ARMista tosin löytyy myös big endian-moodi). Eri endiannessia olevan prosessorin emuloiminen tai binäärikääntäminen on todella paljon hankalampaa ja hitaampaa kuin samaa endiannessia olevan.
Ja ARM eroaa näistä kaikista muista arkkitehtuureista myös markkinatilanteeltaan:
Maailmassa on jo olemassa valtava ARM-ekosysteemi. ARM-prosessoreita on jo valmistettu enemmän kuin x86-prosessoreita. ARM on de facto-standardi androidille ja iOS:lle.
Tämä tarkoittaa, että esim. kääntäjien tuki ARMille on erittäin hyvällä mallilla.
Lisäksi se tarkoittaa sitä, että tehokkaan ARM-ytimen tekeminen ei ole "toivehyppy tuntemattomaan" toivoen että softa tulee perässä vaan sitä voi aina kaupata myös tehokkaisiin android-laitteisiin prossuksi. Ja näillä ei ole mitään ongelmia softan suhteen.
Toimii ja toimii ovat kaksi eri asiaa. Jos sen käyttökokemus ei ole samalla tasolla tai parempi kuin X86 PC:llä, niin se oli siinä vaikka olisi miten hieno binäärikäännös takana. Ja kuluttajat antavat vain yhden yrityksen tuon tekemiseen. Eikös Transmeta yrittänyt juuri jotain binäärikäännöksen tapaista, mutta ei tainnut toimia ihan halutusti, koska firma vaikuttaa kadonneen kartalta?
Transmetalla
KAIKKI softat binäärikäännettiin, ja binäärikäännöksen kohde oli VLIW-pohjainen arkkitehtuuri joka vaan sopii huonosti CPU-käyttöön. Lisäksi sen binäärikääntäjän piti varsinaisen x86-koodianalyysin lisäksi tuottaa myös erittäin hyvin skeduloitu VLIW-koodi ulos, koska VLIWin suorituskyky on täysin riippuvainen kääntäjän käskyskedulerista.
VLIWin käskyskeduloinnin vaikeus on asia, jonka kaikki aina aliarvioi. Ajatellaan että kyllähän sellaisen käskyskedulerin nyt helposti tekee ja tieteellisiä papereita "hyvistä" käskyskedulereista on vaikka millä mitalla, mutta niissä tuijotetaan vaan niitä yksinkertaisia tapauksia. Mutta se koodi, mitä tositilanteessa CPUlle tulee eteen, onkin paljon monimutkaisempaa ja hankalampaa sille käskyskedulerille.
(ja olen siis itsekin kirjoittanut pari tieteellistä paperia VLIWille sukua olevan prosessorin käskyskeduloinnista. Mutta minä en edes yritä tunkea prosessoriani CPUksi koska se ei vaan sovellu siihen, käskyskedulerini toimii hyvin vain niille yksinkertaisille tapauksille joita tulee DSP-käytössä eikä prosessorimme muutenkaan sovellu CPUksi)
ARMv8lla vain osa softista tarvii binäärikääntää, ja ytimenä on CPUksi soveltuva OoOE-ydin.
Ja kun sitä koodia ajetaan OoOE-prossulla, sen kääntäjän ei tarvi skeduloida sitä koodia hyvin, kun prossu itse skeduloi käskynsä. Superskalaari OoOE-RISC ei tarvi hyvää käskyskeduleria kääntäjältä.
