SIRUT & SOVELLUSKEHITYS

Matti P. Pulkkinen, 29.10.2009, 11:29

Moniytimien pimeä puoli

Suorittimista täytyy tietää oikeastaan vain kaksi asiaa. Ne eivät koskaan pysy samanlaisina eivätkä yksinkertaistu.

in lehdistötiedotteita työkseen seuraava allergisoituu väistämättä fraasille Mooren laki. Yli 40 vuotta vanhaa sääntöä puolijohteen transistorimäärän jatkuvasta kasvusta toistetaan kuin suurta uudistusta. Suoritinarkkitehtuureista ei enää viitsi puhua kukaan.

Niistä ei olekaan paljon puhumista. Tämän vuoden alussa kuoli hiljaa ja huomaamatta pois yksi perinteinen tuotelinja, risc-työasema. Viimeisenä vedettiin markkinoilta IBM:n Power-siruun pohjautuva AIX-työasema. Se teki tilaa Intelin x86-suoritinarkkitehtuurille kuten Sunin perinteiset Sparc-työasemat ja HP:n Pa-risc -koneet jo aiemmin.

Itelin x86-käskykantaan pohjautuva pc-suoritinkanta on pyyhkinyt pöydän. Palvelinpäässä Xeon-suorittimet kilpailevat tehokkaasti kalliimpien risc-laitteiden kanssa. Intelin ja AMD:n suorittimien etuna ovat suuret valmistussarjat. Koska tuotantolinjat ovat erittäin kalliita rakentaa ja niiden riskit ovat suuret, valmistussarjojen suuruus näkyy selvästi suorittimen hinnoissa.

Moniytimisyys oli ratkaisu

Se että sama, käännetty koodi toimii pienestä Intel Atom -suorittimesta raskaan sarjaan Xeoniin, merkitsee tietysti helpotusta sovelluskehittäjälle. Sama Intelin x86-pohjainen käskykanta on sovelluksen käytössä, olipa valmistaja Intel, AMD tai VIA. Pinnalta katsoen laitekanta näyttää yhtenäisemmältä kuin koskaan ennen tietojenkäsittelyn historiassa.

Ohjelmointirajapinnan yhtenäisyys ja viime vuosien mittava tehonlisäys on kuitenkin saavutettu lisäämällä suorittimien sisäistä monimutkaisuutta.

Siksi suoritinvalmistajat ovat kiirehtineet julkistamaan saavutuksiaan viivanleveyden kaventamisessa. Viivanleveys, uusissa suorittimissa 45 nanometriä, tarkoittaa piisirulle etsattujen transistorien johtimen leveyttä. Kuvaavaa on, että 45 nanometriä on pienen viruksen kokoluokka.

Pienemmällä viivanleveydellä piisirulle voidaan pakata enemmän transistoreita. Näin suorittimesta saadaan tehokkaampi. Ja monimutkaisempi, vaikka sen käskykanta pysyisi samana vanhana x86-pohjaisena ratkaisuna.

Kuvaavaa on, että modernissa kuusiytimisessä Xeon-suorittimessa on edelleen rakenteita, jotka Intel määritteli vuonna 1974, kun Urho Kekkonen istui Suomessa tukevasti vallankahvassa.

Transistorimäärän lisäys on käytetty suoritinytimien määrän kasvattamiseen. Yksi suoritin käyttäytyy suurin piirtein samalla tavalla kuin neljä tai kuusi prosessoria.

Arkkitehtuuriratkaisuna rinnakkaisuuden lisääminen on jo vanha keksintö. Sen perustana on smp-arkkitehtuuri (symmetrical multi processing), joka tuotiin palvelimiin 1990-luvun alkupuolella.

Rinnakkaisprosessointi on ratkaisu ongelmiin, jotka estävät suorittimen kellotaajuuden noston rajattomasti. Puhutuin ongelma kellotaajuuden nostossa on virrankulutuksen lisääntyminen.

Tärkeämpi ja perustavampi periaatteellinen ongelma löytyi kuitenkin muistin ja muiden suorittimen lisälaitteiden latenssista. Muisti on hitaampaa eikä pysy suorittimen vauhdin perässä. Jos suorittimen kellosyklit joutuvat pyörimään tyhjää odottaessaan koneen keskusmuistista tulevaa dataa, komeatkaan gigahertsit eivät nopeuta ohjelman suorittamista.

Pakko muuttaa

Ensimmäiseksi moniytimisyydestä hyötyi virtualisointitekniikka. VMware ja Xen sopivat erittäin hyvin moniydinympäristöön. Niissä suoritinytimet valjastettiin enemmän tai vähemmän riippumattomiin erityistehtäviin. Yksi suoritin käyttäytyi kuin monta erillistä suoritinta, ja kuorman hajautus suorittimen eri ytimien välillä oli yksinkertaista.

Taustalla kummittelee kuitenkin vanha ongelma. Miten ohjelmakoodi saadaan optimoiduksi usean suorittavan yksikön kesken? Suoritinkuorman hajauttaminen tuo ongelmia, joita vanhanaikaisessa yhden suorittimen arkkitehtuurissa ei tarvinnut murehtia.

Moniprosessoinnin paradoksi on, että 1+1=1,5. Pioneerikauden moniprosessorikoneissa suorittimien lisääminen yli kriittisen rajan hidasti koneen toimintaa nopeuttamisen sijaan.

Kun suoritinkuormaa jaetaan hallitusti useille suoritinytimille, ytimien täytyy jollain tasolla tietää, mitä muut tekevät. Ne käyttävät kuitenkin yhteisiä resursseja, kuten keskusmuistia, levyjä ja tietoliikenneyhteyksiä. Moniytimisyyden tehosta saadaan eniten irti, kun yhteisten resurssien käyttö on hallittua. Nykyaikaisessa moniydinsuorittimessa monet ongelmat voidaan ratkaista suorittimen sisällä, mutta sovelluksen optimointiongelmat eivät ratkea raudalla.

Ratkaisu kääntäjissä

Mooren laki on pohjimmiltaan yhtä tehoton yksinään ratkaisemaan kaikkia tehokysymyksiä kuin mikä muu loitsu tai litania tahansa. On tultu tilanteeseen, jossa sovelluksia on pakko muuttaa, jos niiden halutaan hyötyvän lisääntyvästä rinnakkaisuudesta.

Oireellisesta on, että Intel on tuonut markkinoille oman kääntäjänsä, jonka avulla valmis c- tai fortran-koodi saadaan tukemaan paremmin rinnakkaiskäsittelyä. Ajat, jolloin koodiin upotettiin assembly-kielisiä käskyjä suoraan upotettuna assembly-koodina, ovat jääneet käytännössä taakse. Se oli ennen tapa tehostaa ohjelmaa, mutta assembly-koodaaja ei enää vuosiin ole pystynyt kilpailemaan kääntäjien kanssa tehokkuudesta.

Suorittimen suora ohjelmointi muuttuu suoritinrakenteiden mutkistuessa koko ajan vaikeammaksi, ja moniydinsuorittimen rinnakkaisuuden hallinta assemblyn keinoin on käytännössä ylivoimainen tehtävä. Kääntäjä on koodaajaa älykkäämpi suorien suoritinkomentojen antamisessa.

Entistä harvempi ohjelmoija tuottaa enää suoraa c-koodia, sillä kaupallis-hallinnollisissa ratkaisuissa erilaiset sovelluspalvelimet ja kehittimet poistavat murheet suoritinarkkitehtuurin hienouksista.

SAP- tai WebSphere -ohjelmoijan ei juuri tarvitse vaivata päätään alla olevan prosessorin käskykannasta. Samoin tietokannanhallintajärjestelmät, kuten Oracle ja SQL Server, peittävät suoritinmurheet alleen.

Myös pc-ratkaisujen kehittäjillä on tavallisesti monta välikerrosta koodinsa ja raudan välillä. Näytönohjaimet itsessään sisältävät moniydinsuorittimia, ja normaalisti niiden vaikeus jää näytönohjaimen siistin rajapinnan taakse. Lisäksi tulee grafiikkakirjastojen laaja kirjo.

Tuntemattoman päällä

Sovellusturvallisuuden vaarantuminen on yksi ongelma, jonka on aiheuttanut siirtyminen nykyiseen, hyvin abstraktiin sovelluskehitykseen.

Jokapäiväiset uutiset sovellusten haavoittuvuuksista ja ohjelmistopaikoista ovat jo lähes turruttaneet käyttäjät, mutta ne kertovat vaikeasta ongelmasta. Kun luotetaan kääntäjiin ja ulkopuolisiin kirjastoihin, kontrolli siihen koodiin, jota suoritin varsinaisesti ajaa, menetetään.

Se että kehittäjä ei tunne assembly-tasolla, mitä hänen kirjoittamansa ohjelma sisältää, ei estä jotakuta muuta selvittämästä koodin käyttäytymistä. Käännettyyn koodiin jää kohtia, johon osaava krakkeri voi tarttua.

Tuotteen aktivointikoodin murtaminen on yksi esimerkki assembly-tasolla tapahtuvasta kräkkäämisestä. Yksinkertaistava esimerkki – sillä kukaan tuskin enää tekee näin yksinkertaista aktivointisovellusta – perustuu yhden konekielisen käskyn korvaamiseen toisella.

Itse tuotteen aktivointikoodi voi olla monin tavoin salattu ja erittäin vaikea selvittää ohjelmistokoodista, mutta hyökkääjä käykin itse tarkistusalgoritmin kimppuun. Jos se on muotoa

if INPUT = AKTIVOINTIKOODI then asenna, else error,

murtautuja voi muuttaa vertailuoperaattorin:

if INPUT <> AKTIVOINTIKOODI then asenna, else error.

Tämän jälkeen kaikki muut paitsi oikea aktivointikoodi toimivat tuoteaktivoinnissa. Konekooditasolla tämä on erittäin pieni muutos, joka voidaan tehdä hyvän debuggerin avulla, kunhan oikea ohjelmakohta löydetään.

Ongelma on jo vuosikymmeniä vanha, mutta sovellushaavoittuvuuksia voi löytää sitä enemmän, mitä abstraktimmalla tasolla liikutaan. Tämä selittää osaltaan ohjelmistopaikkojen tulvan.

Sovellushaavoittuvuuksien etsintään – sekä hyviä että pahoja tarkoituksia varten – on olemassa konekoodin takaisin korkean tason kieleksi palauttavia disassemblereita, joista tunnetuin on Ida Pro. Se pystyy palauttamaan käännetyn ohjelman c-pseudokoodiksi.

Tietoturvaongelmien lisäksi eri järjestelmien rajapinnat voivat tuottaa hankaluuksia, kun sovelluksia muutetaan. Vanha laite- tai tietokanta-ajuri ei enää välttämättä toimikaan.

Tiedonsiirrossa saatetaan törmätä ikuisuusongelmaan, merkistökonversioiden epäonnistumiseen. Vaikka vanhan sovelluksen uudelleenkääntäminen paremmalla kääntäjällä voi vaikuttaa yksinkertaiselta, kova kokemus varoittaa. Monissa linux-järjestelmissä on nähty, kuinka sovelluksen vakaus on kärsinyt, kun ytimen uudelleenkääntämisessä optimointi on viety liian pitkälle, esimerkiksi tietyn suoritinsarjan alatyypin tasolle.

Erikoistuneita ytimiä?

Moniytimisyys on tähän asti noudattanut isoista palvelimista alkanutta symmetrisen moniprosessoinnin linjaa. Kaikki suoritinytimet ovat samanlaisia.

Alan teoreetikot eivät ole yksimielisiä siitä, mikä on järkevin kehityssuunta. Symmetrisissä järjestelmissä ohjelmistoarkkitehtuuriin vaadittavat muutokset ovat pieniä, mutta toisaalta saman ratkaisun konemainen monistaminen ei vaikuta kovin älykkäältä.

Jotkut moniydinteoreetikot kehottavat unohtamaan palvelinesikuvat ja ottamaan mallia lähempää, matkapuhelimista. Matkapuhelimissa on useita erikoiskäyttöön suunniteltuja suorittimia, joista jokainen on optimoitu omaan tehtäväänsä. Pc:ssä tämä on niin itsestään selvää, että sitä ei aina tule edes ajatelleeksi. Näytönohjain on oma pieni sulautettu tietokoneensa, joka on optimoitu grafiikan käsittelyyn.

Epäsymmetrisissä suorittimissa, joissa on eri tehtäviin optimoituja ytimiä, yksi voisi toimia esimerkiksi java-virtuaaliskoneen suorittimena, toinen salausprosessorina.

Eri tehtäviin optimoituja suorittimia käytetään jo IBM:n keskuskoneissa. Miksi sama ei voisi toimia suoritinytimien tasolla? Paine yhä pienempiin transistoreihin helpottaisi, jos jokaisen ytimen ei pitäisi esittää täysveristä x86-suoritinta.

Suoritinarkkitehtuurien muuttamisessa jäljet kuitenkin pelottavat. Intelin kunnianhimoinen Itanium-hanke, jonka tarkoituksena oli 64-bittisyyteen siirtymisen myötä muuttaa vanha x86-suoritinarkkiehtuuri, kaatui vanhojen sovellusten painolastiin.

Epäsymmetrisiksi suunnitellut suorittimet kuulostavat teoriassa hienolta. Historia kuitenkin tuskin rohkaisee suoritinvalmistajia ottamaan suuria riskejä, jos uhkana on ohjelmistoyhteensopivuuden menettäminen.

Lähetä

Tulosta

Kommentoi artikkelia

Re: Moniytimien pimeä puoli 29.10.2009 12:55

Hieno artikkeli. Kiitos.

Tv Vastaa

Re: Moniytimien pimeä puoli 29.10.2009 23:14

Jep, pitkästä aikaa laadukasta luettavaa.Kiitos!

Sud Vastaa

Re: Moniytimien pimeä puoli 30.10.2009 23:01

Ensimmäiset vajaat kolme kappaletta ovat hyvä yleisesittely ongelmaan. Loppuosa artikkelista sitten meneekin mielenkiintoiseksi spekulaatioksi, ihan kuin olisi asiantuntemus loppunut paineen alla. Irrallisia faktoja kyllä riitti. Kappale "tuntemattoman päällä" oli jopa hilpeä. Lisää tämmöistä huumoria.

Denise, Paula & Fat Agnus Vastaa

Siirry keskusteluun / Katso kaikki kommentit