torstai 18. elokuuta 2011

Von N.


Tietokoneissa on yksi keskeinen piirre, joka on säilynyt periaatteessa ensimmäisten käyttökelpoisten ohjelmoitavien koneiden keksimisestä lähtien, eli ns Von Neumannin arkkitehtuuri. Tämä viittaa siis siihen, että tietokone on periaatteessa laite, jossa on muisti, prosessointiyksikkö, jne. ja näitä yhdistävä(t) väylä(t), ja samassa muistissa esitetään yhtä lailla sekä ohjelmakoodia että dataa.

Tämä arkkitehtuuri tuottaa pullonkaulan ensinnäkin siksi, että prosessori joutuu odottamaan joskus merkittäviäkin aikoja, että muistista noudetaan sille lisää työtä. Tätä helpottamaan on kehitetty kaikenlaisia välimuisti (cache) ratkaisuja, mutta ne eivät ratkaise itse perustavanlaatuista ongelmaa. Siksi nytkin etsitään kuumeisesti vaihtoehtoja tälle arkkitehtuurille. Toisaalta, oman tieteellisen työni näkökulmasta kysymys ei edes ole relevantti, sillä en operoi tällaisilla abstraktioilla tutkimuksessani. Jouduin kuitenkin perehtymään asiaan hieman, koska minulle lätkäisiin yllättäen ja pyytämättä (joskin ei mitenkään epämieluisasti, vaihtoehtoihin verrattuna) ohjelmointikielten periaatteiden kurssi, ja siinä tämä tulee relevantiksi.

Tämä pullonkaula on aikanaan saanut huomiota siten, että kun ohjelmoitaessa on pyritty tehokkuuteen, ohjelmoinnin teknisissä ratkaisuissa ja jopa algoritmisuunnittelussa on pyritty kiinnittämään tähän huomiota. Esimerkiksi 1980- ja 90-luvuilla ns. demoskenessä arkkitehtuuri- ja alustaspesifiset ratkaisut olivat ns. hack- tai kludge-ratkaisuja, eli teoreettisesti epämielenkiintoisia, mutta ehkä vaivaa ja ilman muuta kekseliäisyyttä vaativia "optimointeja", joista puuttui kaikki geneerisyys ja eleganssi, mutta jotka olivat paikoitellen aivan käsittämättömän tehokkaita. Itse en koskaan mitenkään erityisemmin ollut kiinnostunut tämäntapaisesta "häkkäämisestä", vaikka sen tulokset kiintoisia olivatkin. Sen pari kertaa kun johonkin partikulaariseen, sinänsä näyttävän tuloksen saavuttaneeseen ratkaisuun olen perehtynyt, on tullut lopulta tunne, että minua on huijattu hieman samaan tapaan kuin taikurin taikatempussa.

Tämä on muutoin epäolennaista, esitän ylläolevan lähinnä pohjustuksena niille, joilla on (virheellinen) käsitys -- joka minullakin oli jossakin vaiheessa -- että abstraktimpaan suuntaan kehittynyt ohjelmistosuunnittelu jotenkin hävittää kulttuurin, jossa ennen tehtiin "paremmin", kun jouduttiin häkkäämään, ja erityisesti niin, että tämä olisi kokonaan huono asia ja vain laiskuutta.

Ihmisen kyky abstraktioon, jossa aidosti "operationaalinen" (tarkemmin sanottuna, sellaisena pidetty) taso on hyvin syvällä verrattuna siihen, jolla ratkaisuja tietoisesti haetaan, on hyvin rajallinen. Ensinnäkin, jokainen tilanne, jossa joudutaan siirtymään syvemmälle, lähemmäs "konkreettista", on abstraktiovuoto. Niiltä ei voi välttyä täysin, mutta mitä syvemmälle vuoto jatkuu, sitä todennäköisemmin alkuperäinen ajatus hukkuu. Ohjelmointikielten kehitys abstraktimman ilmaisun suuntaan onkin palvellut tätä tarkoitusta, ja se kumpuaa inhimillisten kykyjen rajoitteiden tunnustamisesta.

5 kommenttia:

Ari kirjoitti...

Uskon, että monissa ohjelmistoissa paradigmamuutos on menossa deklaratiiviseen ohjelmointiin kun laskentatehoa riittää. Ja tämä on ohjelmoijalle sinäänsä mukavaa, koska voi saada enemmän aikaan lyhyemmässä ajassa. Transitiot deklaratiivisempaan paradigmaan vaatii kuitenkin hyvin abstraktia käsitystä ohjelman toiminnasta ja toistuvuudesta.

Tämähän tarkoittaa, että ohjelmoijista tulee enemmän suunnittelijiota ja maalareita, ja raskas työ ulkoistetaan tietokonekielille, kääntäjille, tulkeille ja frameworkeille. Tietenkin x86-konekielen tiukimmat viilaukset ja tehokkaimmat algoritmit opetelleet ovat tästä harmissaan, mutta tämä on kehitystä. Aina tosin on sovellusalueita, kuten lyhyitä ja tarkkoja suoritusaikoja vaativat reaaliaikaiset ohjelmistot, missä tälläinen taito on pakollista.

Itsekin kun joskus opin Von Neumannin arkkitehtuurista, intuitiosta lähti kysymys, onko tehokkaampi tapa tehdä tietokoneita, koska kyseinen arkkitehtuuri on ollut aika kauan olemassa.

Voihan olla, että joku uusi teknologia kuten valopohjaiset logiikkapiirit tekevät muistihauista nykyistä paljon tehokkaampia jolloin arkkitehtuurimuutos ei välttämättä ole tarpeelllista.

Ilkka kirjoitti...

Kappas, tuli tuo Von Neumannin arkkitehtuuri juuri tänään tässä uutisessa esille, muutoksia tulossa tähänkin rintamaan siis, vilkaisepas:

http://www.hardware.fi/uutiset/artikkeli.cfm/2011/08/18/ibm_kehitti_ihmisen_aivoja_matkivan_sirun

Kuntsa kirjoitti...

Neumannin arkkitehtuuria täysillä hyödyntäviä ohjelmakieliä ei kyllä hirveästi käytetä. Lisp on tietty poikkeus, samoiten sen sukuinen Forth, ja ehkä jotain skriptikieliä voi myös pitää von Neumannin arkkitehtuurin mukaisina. Arkkitehtuuri itsessään on voimakas kuin pangalaktinen kurlauspommi.

Vielä pidemmälle menevä abstraktio, jossa piillä olevia transistoreita voidaan käsitellä kuin mitä tahansa muuta dataa tai ohjelmakoodia, olisi kyllä viileä mutta kolea.

Mitäs muuten sielläpäin käytetään nyyään ohjelmointikielten periaatteiden opetukseen? Kultainen kolmikko Java/Haskell/Prolog? Mahtuuko mukaan pari Lisp-makroa, voisit näyttää miten Oikeat Miehet™ tekevät koodia periaatteista välittämättä...

Tiedemies kirjoitti...

En ihan ymmärrä Kuntsan kommenttia. Imperatiiviset kielethän nimenomaan ovat kehittyneet VN arkkitehtuurin rajoitteiden alaisina, tosin abstraktimpaan suuntaan mentäessä yhä vähemmän.

Lispin tapaisissa kielissä taas "operationaalinen" taso on funktioteoriassa tai vaikka lambda-kalkyylissä, josta se sitten mäpätään raudalle.

Meidän opetuksessamme ei ole mitään partikulaarisia kieliä muutoin kuin esimerkkeinä tietyistä suunnitteluperiaatteista ja niiden ilmentyminä.

Kuntsa kirjoitti...

Useimmat imperatiiviset kielet ovat kyllä kehittyneet Harvardin arkkitehtuurin rajoitteiden alaisina: tietokoneessa on keskusyksikkö, datamuisti ja ohjelmamuisti. Wrenit tai muut koodikulit näpsyttelevät koneen paneleissa olevia kytkimiä ja langoittavat koneen uusiksi kun ajettava ohjelma vaihtuu.

Von Neumannin arkkitehtuurissa ohjelma- ja datamuisti on siis yhdistetty, ohjelma on dataa on ohjelmaa. Yritin vähän vilauttaa arkkitehtuurin hyviä puolia, eli vaikka se, että se mahdollistaa reflektioon perustuvan ohjelmoinnin. Reflektion mukana tulee ohjelmointiparadigman lisäksi kaikkea kivaa, niin kuin jit-käännökset, hotspot-optimoinnit jne.

Toinen hyvä puoli, jota Tiedemies näköjään ymmärtää arvostaa, on säännöllisyys ja symmetrisyys. Bitti muistissa on bitti muistissa. Koska bitit ovat bittejä, vanhan kunnon John vonin pullonkaula on pystytty kiertämään luomalla muistihierarkia. Varsinainen keskusmuisti, L1-välimuisti, pyörii samalla nopeudella kuin prosessori. Sitä on yhtä paljon kuin 1960-luvun superkoneessa, 1970-luvun minissä tai 1980-luvun kotimikrossa. Dataa haetaan sitten hitaammin ja isommissa palasissa L2, L3, D"RAM" ja "levyn" flash-muistilta.

Toinen tapa kiertää pullonkaula on hajauttaa laskenta useammalle tietokoneelle rinnakkaistamalla ja klusteroimalla.

Niin kauan kuin Mooren laki pätee, von N. jyrää. Eilispäivän häkki voidan tehdä tänään geneerisellä raudalla. Tuo Modhan BlueMatter-siru on siitä hyvä esimerkki, poikien on pakko juosta Moorea nopeammin. Ainoa rako menestykseen on toivoa, että Mooren laki lakkaa toimimasta.