Kun oikein kaivellaan niin saadaan Applen etu vain kymmeneksi prosentiksi. Intelin kääntäjä huijaa Spec-testeissä, eli siellä on vartavasten käsin optimoituja polkuja jotka korvaa koodia tehokkaammalla, tämä on ihan tunnettua ja Intelin kääntäjää ei spec-testeissä käytetä jos halutaan edes suurinpiirtein vertailukelpoisia tuloksia.
Kuten varmaan itsekin huomaat, niin siirtelet maalitolppia niin että saat väkisin vängättyä todeksi sen, mikä on tulkinnanvaraista, tapauskohtaista ja vaatisi lopullisen tuloksen arvioimiseksi vielä paljon lisätyötä. Kääntäjissä on mielin määrin sekä automatisoituja että adhoc käsin kirjoitettuja optimointisääntöjä eli jokin tiettyyn ongelmaan benchmarkia varten kirjoitettu optimointi ei varsinaisesti eroa siitä mitä kääntäjässä on muutenkin sisällä. Eikä se ole huijausta, vaan pätee ihan samalla tavalla vastaaviin muihin tilanteisiin, mihin optimointia voi vaan käyttää. Sellainen testi ei vaan ole hyödyllinen, joka nopeutuu suunnattomasti jostain tietystä spesifistä optimoinnista. Paras objektiivisuus mihin päästään on käyttää kääntäjää, joka käyttää optimointeja vain eri prosessorien suurimman yhteisen tekijän mukaan eli ei mitään toiselle edullisia ominaisuuksia. Tai sitten käytetään vaikkapa käsin koodattuna kullekin arkkitehtuurille optimaalisinta koodia. Tämäkin on vaikea kun prosessorit on tuunattu erilaisille kuormille ja käytännössä tilanne voi tasoittua jossain oikean maailman ongelmassa. Myös käyttis, käytönaikainen kirjasto jne. vaikuttavat mahdollisesti. Näistä on ihan typerää spekuloida ennen kuin on vakioitu testiympäristö saatavilla. Sitten on lopulta se, että mitä halutaan mitata - arkkitehtuurisuunnittelua urheilusuorituksena vai jotain todellisen maailman ongelman ratkontaa?
Koko homman pointtihan on että Applen prossu on niin sairaan hyvä että kusinen kännykkä kilpailee ihan tasaveroisesti Intelin parhaan pään serveriprossun kanssa Spec-tuloksissakin, tässä nyt ei kellään voi jäädä epäselväksi että Applen prossu on aivan sairaan hyvä vrt Intelin tuotokset.
Ja mopedi on tuhat kertaa kätevämpi Rooman iltapäiväruuhkissa ahtailla kujilla kuin rynnäkköpanssarivaunu.. tässä ei ole mitään tolkkua. Serveriprosessoreja ei kukaan käytä yksisäikeisesti ja niissä on mitoitus TDP:n osaltakin niin, että kaikki ytimet ovat käytössä. Jopa Intelin prossuja valitessa se kallein ja isoytimisin palvelinprosessori "ei välttämättä" ole paras esim. pelaamiseen tai web-surffailuun. Kannattaa miettiä, että Applen mobiili-cpu on aika lailla optimoitu tyypilliseen käyttöön juuri nyt. Ei välttämättä ole kaukaa haettu, että Applekin joutuu lähivuosina vaihtamaan tuota painotusta, jos ytimiä tulee lisää käyttöön mobiilissakin.
IPC ei nyt tosiaan voi arkkitehtuurien välillä vertailla suoraan mutta epäsuorasti voi esimerkiksi juuri käännettyjen Spec-tulosten kanssa aivan hyvin. Applen prossu taitaa dekoodata ja suorittaa maksimissaan 7 käskyä per kellojakso ja toteutuneetkin on hyvin korkeat, tässä lienee apua paljonkin yksinkertaisesta käskykannasta.
Kannattaa silti muistaa, että IPC on umpikuja ennen pitkää. Käskyvirrassa on aina satunnaisuutta ja epäedullisia riippuvuuksia, joita ei saa tarkasteluikkunan puitteissa sovitettua liukuhihnaan kaikille laskentayksiköitä utilisoivaksi, kun taas esim. ydinten ja vektorirekisterien osalta skaalautuvuutta on moninkerroin enemmän ihan todistetusti, jos katsotaan jo tehtyjä arkkitehtuureja. IPC-kisa on lähinnä relevantti yhdessä pienessä laskentaongelmien erikoistapauksessa, jossa on peräkkäisyyttä suosiva yleiskäyttöinen algoritmi. Muita algoritmeja ja toteutusvaihtoehtojakin on. Jos on tietty laskentakerneli, missä yksi arkkitehtuuri keulii IPC:n avulla, toinen voisi ehkä toteuttaa sen tietyn algoritmin 10 kertaa tehokkaammin DSP:llä tai vastaavalla erikoispiirillä. Mutta voi korkea IPC olla mobiilissa ihan oikeasti oikea ratkaisu, vaikka olisikin skaalautumisen mielessä umpikuja. Mobiilissa ei välttämättä tarvita tietyn rajan yli tehoja. Voi olla että pitäisikin optimoida softaa.
