Tietoenkäsittelytiede Heinäkuu 2 sivut 2 2 Toimittaa: Ari Korhonen c kiroittaa(t) Supertietokoneiden tehoa anotaan: miten saada enemmän tehoa irti? Jan Westerholm, Mats Aspnäs & Artur Signell Åbo Akademi Informaatioteknologian laitos {awester,mats,asignell}@abo.fi Tausta Supertietokoneiden ilmoitetut laskentatehot ovat vuosi vuodelta kasvaneet. Top 5 -listan [] kärkikoneet ovat parinsadantuhannen laskentaytimen koneita, otka teoreettisesti pystyvät tekemään yli 5 liukulukulaskutoimitusta sekunnissa eli petaflopsea. Gordon Mooren havainnon mukaan transistorien lukumäärä kaupallisissa mikropiireissä kaksinkertaistuu oka toinen vuosi. Näistä transistoreista on ennen rakennettu yhä kehittyneempiä tietokonearkkitehtuurea, mutta viime vuosina niitä on käytetty varsinkin prosessoreiden laskentaytimien lukumäärän kasvattamiseen. Vaativien laskentatehtävien suorittamiselle näyttäisi siis olevan vuosi vuodelta yhä tehokkaampia koneita käytettävissä, a laskentakapasiteetille on atkuvasti kasvava kysyntä. Supertietokoneiden tehoa anotaan a sitä näyttäisi olevan palon, mutta saavatko ohelmat kaiken tehon irti? Tietokoneohelmien rinnakkaistuksella käyttää on pyrkinyt sekä saamaan käyttöönsä suurempia muistimääriä, että lyhentämään pitkiä aoaikoa. Lyhentyneiden aoaikoen ansiosta ohelmia voidaan käytännössä aaa useammin, olloin ohelman toiminta, mahdolliset raoitteet, herkkyys alkuparametreille a ohelman tulokset ymmärretään paremmin. Tässä mielessä voi sanoa, että tieteellisten tulosten laatu paranee rinnakkaistumisen myötä. Jos sama laskenta voidaan aaa samoilla resursseilla nopeammin koodin optimoinnin ansiosta, säästyy energiaa a työaikaa, a laskentaresurssea voidaan hyödyntää paremmin palvelemalla useampia käyttäiä. Artikkelin kiroittaat kuuluvat suurteholaskennan ryhmään, oka viime vuosina on osallistunut useaan supertietokoneohelmien tehokkuutta a skaalautuvuutta parantavaan tutkimusproektiin [2, ]. Yhteistyökumppanit olivat supertietokoneille ohelmiaan tekevistä tutkimusorganisaatioista, mutta myös avointa lähdekoodia kehittävistä organisaatioista esimerkiksi bioinformatiikassa. Mukana oli muun muassa ydinfuusiofyysikoita, oille annetaan satoa tuhansia cpu-tuntea yhteiseurooppalaisissa suurteholaskentakeskuksissa. Kysymys, ohon etsimme vastausta, on seuraava: Miten supertietokoneissa aettavat ohelmat voivat paremmin hyödyntää käytettävissä olevat tehoresurssit? Tekemämme empiiriset havainnot suurtehokoneissa pyörivistä ohelmista perustuvat erityisesti ohelman rinnakkaistukseen, välimuistin käytön optimointiin, sekä vektorilaskentaan. Tarkasteltavat ohelmat olivat osana kolmea tutkimus- OHJE KIRJAPAINOLLE: B5-arkin vasen- a yläreuna kohdistetaan A4-arkin vasempaan a yläreunaan. Näin pitäisi marginaaliksi tulla taitteen puolella noin mm a muualla noin 22 mm.
22 Supertietokoneiden tehoa anotaan kokonaisuutta. Ensimmäisessä tutkittiin oukko kansallisen supertietokeskuksen CSC:n supertietokoneissa aettavia eri tutkimusryhmien kiroittamia ohelmia, sekä yleisessä käytössä olevaa avointa lähdekoodia. Toisessa proektissa saimme EU-yhteistyön kautta käyttöömme eurooppalaisten ydinfuusioryhmien kiroittamia lähdekoodea, a kolmanteen ryhmään laitamme tässä muiden yhteydenottoen kautta tulleita ohelmia. Ohelmointikieliä oli useampia: Fortran, C, C++, Python/C, sekä OCaml/C. Käyttöärestelmiä hallitsi Linux muutaman Windowsohelman lisäksi, a mikroprosessoriarkkitehtuurit olivat x86 a PowerPC. Sovellusalueita olivat pääasiassa fysiikan simulaatiot, kuten ydinfuusioplasmat, virtausmekaniikka, ydinkaskadit eli hiukkassuihkun simulointi mm. kudoksen läpi a konfokaalimikroskopia, sekä bioinformatiikan ohelmistot. Ohelmat olivat kiroittaneet fyysikot, kemistit sekä tietoenkäsitteliät ympäri Suomea, Eurooppaa a USA:ta. Ehkä pienenä yllätyksenä tuli havainto, että oitakin koodea oli kehitelty hyvinkin pitkään, opa 2 vuotta, mikä näkyikin selvästi vanhimmista osista lähdekoodia. Näin vanhoen koodien atkuva kehitys on varmaan ollut haasteellista, varsinkin kun rinnakkaiskoneet yleistyivät vasta noin 5 vuotta sitten. 2 Tavoitteet Alusta asti oli selvää, ettemme oman resurssipulamme takia voineet lähteä rinnakkaistamaan meille lähetettyä sekventiaalisia koodea. Sen siaan keskityimme o kertaalleen rinnakkaistettuen ohelmien parantamiseen a tehostamiseen. Tämän lisäksi suoritimme sekä sekventiaalisten että rinnakkaistettuen koodien optimointia. Jälkimmäisessä tapauksessa tavoitteena on saada sama numeerinen tulos kuin ennen optimointia, mutta nopeammin hyödyntämällä välimuistin käyttöä sekä vektorilaskentaa. Joissakin tapauksissa koodin optimointiin saattaa sisältyä tehtävien laskutoimitusten uudelleenärestelyä, olloin mikroprosessorien äärellisen liukulukulaskentatarkkuuden eiassosiatiivisuudesta seuraa, ettei 5 numeron tarkkuudella välttämättä saada samoa tuloksia kuin ennen. Joillekin koodinomistaille tämä aiheutti onkun verran hermostuneisuutta, koska oli totuttu saamaan tietynnäköisiä numeerisia tuloksia. Meidän mielestämme ei ole syytä huoleen: os lasketaan eri ärestyksessä saadaan usein eri tulos, mutta mikään ei viitannut siihen että alkuperäinen laskuärestys olisi ollut numeerisesti tarkempi tai stabiilimpi. Emme puuttuneet ongelmanasetteluun, eli emme kysyneet miksi tietyt laskut haluttiin suorittaa. Emme myöskään puuttuneet valittuun numeeriseen algoritmiin, ellei kyse ollut tarkasti modularisoidun numeerisen algoritmin korvaamisesta toisella implementaatiolla, tyypillisesti avoimen lähdekoodin kirastorutiinilla. Tässä mielessä voi sanoa että tekemämme koodin optimointi oli lähinnä o tehtyen virheiden paikkaamista: laskettavat suureet a algoritmit oli o valittu a pyrimme pelkästään virtaviivaistamaan laskuen suoritusta olemassa olevalle mikroprosessoriarkkitehtuurille. Metodologia Saatuamme uuden koodin sovelsimme siihen oukon perustyökalua, oiden avulla pyrittiin hahmottamaan potentiaaliset optimointikohteet koodissa. Tämän lisäksi osoittautui hyödylliseksi tarkistaa mahdollisia muistivuotoa, oissa ohelma ohelmointivirheen seurauksena kiroittaa varaamattomalle muistialueelle. Yllättävää oli, että moni käyttää voi elää sen kanssa, että ohelma saattaa muistivuodon takia kaatua epäsäännöllisin väliaoin.
Westerholm, Aspnäs, Signell 2. Koodin katselmus Hyvin monelle tutkimukseemme osallistuneelle koodille oli ominaista, että ohelma aettiin omassa ympäristössä, eikä koskaan ollut ilmennyt tarvetta lähettää koodia ulkopuoliselle taholle. Tilanne oli siis uusi kun pyysimme saada lähdekoodin sekä sopivia lähtöparametrea pienehköä aoa varten, ota käytettäisiin vertailupisteenä koodinoptimoinnin antaman nopeutuksen mittaamiseksi. Se, että ohelmaa nyt käytettäisiin uudessa ympäristössä ilman koodinkehittäien valvovaa silmää, aiheutti todennäköisesti pienen paineen saattaa koodi sellaiseen kuntoon, että se toimisi uudessa paikassa. Yksi merkki tästä oli usein esiintynyt ilmoitus kooditoimituksen viivästymisestä, koska oli ilmennyt ennen esiintymättömiä ongelmia. Saatuamme koodin loimme yleensä pikaisen katseen lähdekoodiin a sen yleiseen rakenteeseen. Tästä ilmeisen yksinkertaisesta toimenpiteestä oli usein hyötyä, sillä uudet silmäparit erottavat koodista toisia asioita kuin kehittäien silmät. Meidän tehtävämme oli keksiä ns. tyhmiä kysymyksiä ohelman rakenteesta a oskus yksityiskohdistakin, a tällä tavalla löysimme usein koodia, oka oli syntaktisesti oikein mutta toiminnallisesti väärin..2 Profilointi Ennen kuin lähdettiin optimoimaan koodea pyrittiin paikallistamaan ne kohdat tai metodit otka potentiaalisesti kannattaisi optimoida. Jos lähtee optimoimaan kaikkea, on aina olemassa riski, että optimointitulos on hyvä metodin suoritusaika lyhenee mutta sillä ei ole uurikaan vaikutusta kokonaissuoritusaikaan. Syynä tähän on yleensä se, että metodia kutsutaan vain muutama kerta suorituksen aikana a/tai kyseisen metodin suorittamiseen menee erittäin pieni osa kokonaissuoritusaasta. Parhaiten optimoinnit purevat kun ne kohdistetaan sellaisiin metodeihin, oihin suuri osa kokonaisaasta uppoaa. Muutamassa tapauksessa koodinomistailla oli näppituntuma mitkä kohdat voisivat olla hyödyllisiä optimoida, kun taas toisissa ei ollut lainkaan tietoa mihin osiin kannattaisi keskittyä. Profilointityökalut, kuten gprof, Crayn craypat sekä Intelin VTune, eivät ota mielipiteitä tai näppituntumia huomioon, vaan antavat raakaa dataa ohelman suoritusaasta a muistinkäytöstä. Perusprofilointiohelma kertoo miten palon aikaa kuluu okaiseen metodiin a miten monta kertaa kyseistä metodia kutsutaan. Kehittyneemmät profilointityökalut osaavat myös kertoa miten hyvä välimuistinkäyttö oli, miten tehokkaasti laskuoperaatioita tehtiin (flops) a rinnakkaisohelmissa miten palon aikaa käytetään kommunikaatioon, odotteluun sekä varsinaiseen laskentaan. Monesta ohelmasta löytyi yksi tai muutama metodi, ossa merkittävä osa kokonaissuoritusaasta vietettiin. Yleensä kyse oli suhteellisen lyhyistä a ytimekkäistä metodeista, oita kutsuttiin ohelmissa erittäin monta kertaa. Jos tällaisesta metodista saa % tai opa 5% suoritusaasta pois, näkyy tämän vaikutus selvästi kokonaissuoritusaassa. Yleensä eniten kiinnostava profilointia optimointikohde on suoritusaika: tuloksia halutaan nopeammin. Muistinkäyttö tulee tyypillisesti kuvioon vasta kun tämä muodostuu ongelmaksi: muisti loppuu kesken tai ohelma kaatuu muistivuodon tai puskuriylivuodon takia. Muistivuodot a puskuriylivuodot löytyvät yleensä muistinkäyttöanalysointityökalulla, kuten Valgrind [8], kunhan oppii tulkitsemaan sen tuloksia. Kokemus kertoo, että muistiongelmat kannattaa korata saman tien kun ne ilmenevät, vaikka ne eivät haittaisikaan ohelman suoritusta. Näin säästytään ongelmilta myöhemmin. Muistivuo-
24 Supertietokoneiden tehoa anotaan toen koraaminen vähentää myös ohelman muistinkäyttöä a voi sallia suurempien ongelmien simulointia. Rinnakkaistetun ohelman muistinkäyttö voidaan kiroittaa yksittäisen prosessorin kannalta muotoon M = S + D, missä M on yhden prosessorin muistinkäyttö, S prosessorin muistinkäyttö, oka ei riipu kokonaisprosessorimäärästä, a D muistinkäyttö, oka on riippuvainen prosessorimäärästä. Jotta ohelmaa voidaan aaa suuremmalla prosessorimäärällä, täytyy muistinkäytön kannalta olla voimassa D >> S. Ideaalitilanteessa S =, olloin muistinkäyttö prosessorissa voidaan puolittaa tuplaamalla käytettyen prosessoreiden määrä. Profilointityökalut kertovat M:n, mutta S:n a D:n suhde selviää vasta kun ohelma profiloidaan eri prosessorimäärillä a/tai parametreilla. Tarkasteltavista ohelmista yksi näytti profiloinnissa, että S D. Tästä ohtuen M oli lähes vakio a melkein riippumaton prosessorimäärästä, eikä rinnakkaistetulla ohelmalla voitu simuloida monimutkaisempaa ongelmaa kuin yhdellä prosessorilla, koska muisti loppui kesken. Syykin selvisi kooditutkiskelun älkeen: käytettiin tiheää matriisia arvoen väliaikaistallennukseen a matriisin koko oli valittu suoraan verrannolliseksi käytettyyn simulaatioavaruuden hilan kokoon. Vaihtamalla matriisi dynaamiseen tietorakenteeseen muistinkäyttö muuttui täysin siten, että D S a hilaa oli mahdollista kasvattaa kunhan käytössä oli tarpeeksi prosessoreita. 4 Rinnakkaistaminen Monen tieteellisen ohelman kehitys on aloitettu yli 5 vuotta sitten, tyypillisesti Fortran77-kielellä. Nykyaikaiset rinnakkaisohelmointikirastot tukevat kyllä Fortran77:ä, mutta ohelmat on alunperin suunniteltu a implementoitu täysin sekventiaalisiksi aikakaudella, olloin rinnakkaiskoneita ei vielä ollut yleisessä käytössä. Vuosien varrella ohelmia on muutettu osittain rinnakkaisiksi pienin askelin rinnakkaistamalla keskeisiä silmukkarakenteita a akamalla simuloitava hila useammalle prosessorille koskematta oleellisesti muihin sekventiaalisiin osiin. Rinnakkaisohelmointiparadigmaa ei siten seurattu, vaan koodia on rinnakkaistettu vain osin. Yleinen ohe rinnakkaisohelmien kiroittaille on suunnitella sekä algoritmit että tietorakenteet (vektorit, matriisit, struktuurit, ne.) siten, että tiedot voidaan luontevalla tavalla akaa pienempiin yksikköihin, otka ovat suureksi osaksi toisistaan riippumattomia. Riippumattomuus tarkoittaa, että kukin prosessori voi ainakin pääsääntöisesti tehdä laskentaa muiden prosessorien datasta riippumatta, kuitenkin siten, että välillä saatetaan lähettää suhteellisen pieniä datamääriä muutamalle toiselle prosessille. Ohelman osittaisenkin rinnakkaistamisen potentiaalinen hyöty on ilmeinen: suurempi laskentatyö aetaan yhä useammalle prosessorille, oten os rinnakkaislaskennassa tehtävä työ on verrannollinen hilapisteiden lukumäärään a rinnakkaistaminen onnistuu hyvin (esim. hilapisteessä tehtävä laskutoimitus tarvitsee vain lähinaapuripisteiden arvoa) voimme arvioida, että rinnakkaislaskenta-aika pysyy liki vakiona mikäli ongelmakoon a prosessorilukumäärän kaksinkertaistaminen tehdään samanaikaisesti. Tässä on oletettu hieman yksinkertaistaen, että kommunikaatio prosessorien välillä ei muodostu pullonkaulaksi. Yksi rinnakkaistamisella periaatteessa saavutettava hyöty on se, että tietty ohelma voidaan nopeuttaa, eli tietyn kokoinen simulointi voidaan laskea nopeammin. Rinnakkaistamisen tuoma nopeutustekiä SpeedUp prosessori-
Westerholm, Aspnäs, Signell 25 määrän funktiona lasketaan kaavasta SpeedU p(n) = RunTime()/RunTime(N) ossa RunTime(N) on ohelman aoaika N:llä prosessorilla. Käytännössä harvaa ohelmaa kuitenkaan aetaan suuremmalla prosessorimäärällä kuin on tarpeen. Jonkinlaista minimaalista aatusmallia edustaa havaitsemamme käytäntö, onka mukaan simuloinnin tarvitsema muistimäärä kiinnittää käytettävien prosessorien lukumäärän. Oletetaan, että meillä on simulointiohelma, onka kokonaisaasta tietty osuus on sekventiaalista, kun aetaan "pientä" ongelmaa ehkä 8 prosessorilla. Halutaan arvioida aoaika, kun ongelman koko kasvaa a prosessorien lukumäärä lisääntyy esimerkiks8:aan ta56:een. Keskeinen kysymys ohelman ns. skaalautuvuuden kannalta on nyt: miten käy sekventiaaliselle osalle kun simulaation koko suurenee? Jos ohelma suunnitellaan alusta asti rinnakkaiseksi, on ainakin periaatteessa mahdollista, että sekventiaalisen osuuden aoaika pysyy vakiona. Harva kohtaamamme ohelma on onnistunut tässä. Sen siaan olemme usein todenneet, että sekventiaalisen aoaan osuus on kasvanut prosessorilukumäärän suhteessa. Tarkempi analyysi kertoo, että tiedostoihin kiroittaminen on usein implementoitu sekventiaalisesti yhden tietyn prosessin kautta: kaikki prosessit lähettävät tuloksensa tälle prosessille, oka kokoaa tiedot oikeaan ärestykseen a kiroittaa välituloksia, diagnostisia arvoa, keskeytyneen ohelmasuorituksen uudelleenkäynnistyksen tietoa tai lopputuloksia kovalevyille. Sekventiaalisen osuuden aoaika kasvaakin suhteessa ongelman kokoon a sitä kautta prosessien lukumäärään. Tästä seuraa, että suuremman prosessorilukumäärän tapauksessa ohelma ei nopeudu vaan hidastuu, koska sekventiaalinen osuus kasvaa prosessorilukumäärän kasvaessa. 4. Triviaalisti rinnakkaistuvat On olemassa laskutehtäviä, oiden rinnakkaistaminen on suoraviivasta a yksinkertaista, a niissä rinnakkaistus on onnistunut hyvin. Näihin tapauksiin kuuluvat yhteen laskentaytimeen mahtuvat ohelmat, otka aetaan monta kertaa eri lähtöparametreilla suorittaen siten parametripyyhkäisyn, tai Monte Carlo -tyyppiset simuloinnit oissa sama ohelma aetaan monta kertaa eri satunnaislukualustuksella statistisen arvion laskemiseksi. Käytännössä yksi prosessi kerää N :n ohelman tulokset a suorittaa älkiprosessoinnin. Ammattislangi kutsuu näitä ohelmia "triviaalisti rinnakkaistuviksi" mikä saattaa kuulostaa hieman halventavalta, mutta meidän mielestämme ne edustavat hyvin tärkeää luokkaa rinnakkaisohelmia, oille on ominaista, että ne voidaan aaa ongelmitta erittäin suurilla prosessorimäärillä. 4.2 Prosessien välinen kommunikaatio Rinnakkaisohelmoinnissa pyritään aina akamaan laskennat eri prosessorien kesken siten, ettei kaikkien prosessien tarvitse simulointiaskelten välillä vaihtaa dataa kaikkien muiden prosessien kanssa. Tällöin nimittäin N prosessia saa aikaan N(N )/2 kommunikaatiota, olloin N:n kasvaessa yhä suurempi osuus kokonaisaasta kuluu kommunikaatioon. Kaikki tähän asti kohtaamamme ohelmat ovat onneksi(?) olleet rakenteeltaan hilaakoon a lähinaapurivuorovaikutukseen perustuvia. Simulointitehtävä on tällöin formuloitu tapahtuvaksi esimerkiksi kolmidimensioisella hilalla, oka on aettu säännöllisesti pienempiin kuutiotyyppisiin osiin, a okainen prosessi laskee oman kuutionsa hilapisteet vaihtaen aina simulointiaskelten välillä dataa lähimpien naapuripro-
26 Supertietokoneiden tehoa anotaan Kuva : Fuusiosimulaatiokoodin skaalautuvuus Cray XT4/5 koneessa sessorien kanssa reuna-alueeseen verrannollisen määrän. Kolmessa dimensiossa lähinaapuriprosessea on vakiomäärä, 26 kappaletta, a kahdessa dimensiossa vain 8. Tästä seuraa että ohelman kommunikaatiossa vaihdettava kokonaistietomäärä kasvaa suhteessa prosessorien lukumäärään eli kommunikaatio skaalautuu, olloin on odotettavissa ettei ohelma huku kommunikaatioon suuremmillakaan prosessorimäärillä (katso kuva ). Erikoisena piirteenä havaitsimme, että kommunikaation suunnittelussa on usein noudatettu ehkä hieman liioiteltuakin varovaisuutta a suunnitelmallisuutta. Periaatteena käytettiin kuviota, ossa prosessori ensin pyyhkäisee oman hilansa yli, onka älkeen se lähettää tiedot laskemistaan reunapisteiden uusista arvoista ensimmäiselle naapurilleen, odottaa kuittausta vastaanottaalta eli sen lähettämää dataa a etenee sen älkeen seuraavalle naapurille. Varmuuden vuoksi ohelmaan liitetään lopuksi globaali puomi (eng. barrier), oka pakottaa kaikki prosessorit odottamaan kunnes okainen prosessori on saavuttanut saman kohdan ohelman suorituksessa. Nykyiset rinnakkaisohelmointikirastot tukevat asynkronista kommunikaatiota, ossa prosessori ei tarvitse naapureilta kuittausta, vaan prosessori pyyhkäisee ensin reunapisteidensä yli, lähettää nämä tiedot naapureilleen odottamatta kuittausta, pyyhkäisee tämän älkeen kaikkien muiden pisteidensä yli a vasta sen älkeen tarkistaa ovatko naapuriprosessien reunapisteet saapuneet. Kaikkien uusien reuna-arvoen saavuttua prosessori voi edetä seuraavalle simulaatioaskeleelle ilman globaalia puomia. 4. Kuormantasaus Tutkimissamme ohelmissa simuloidaan usein aassa eteenpäin siten, että kehitetään kaava, oka mallittaa miten systeemi kehittyy aassa, onka älkeen edetään aanhetkestä t = pienin askelin t eteenpäin. Mikäli prosessorien simulaatio-osuus kokonaistyöstä perustuu edellä kuvattuun hilaakoon, on hilan ta-
Westerholm, Aspnäs, Signell 27 saaolla varmistettu, että okainen prosessi tekee saman verran laskentaa, eikä synny tilannetta, ossa kaikki muut prosessorit odottavat eniten työtä tekevän prosessorin valmistumista. Mikäli simulaatio sisältää stokastisia piirteitä, esimerkiksi os hilapisteiden välissä liikkuu hiukkasia, otka voivat tilapäisesti kasaantua oihinkin hilan osiin a toisaalta harventua muilta osin, on mahdollista että työnako muuttuu epätasaiseksi a useimmat prosessorit outuvat olemaan outilaina odottaessaan työllistettyen prosessoreiden valmistumista. Havaintomme mukaan tällaisia työnaon osalta epätasaisia ohelmia esiintyy melko usein a niiden kohdalla voi olla mielekästä toteuttaa työn uudelleenako tietyin aikavälein. Eräässä tapauksessa nopein prosessori suoriutui työstään sekunnissa hitaimman pyöriessä sekuntia, olloin kokonaisaoaika määräytyi hitaimman prosessin mukaan. Työn uudelleenaon älkeen, sisältäen akoon liittyvän lisätyön, kaikkien prosessoreiden aoaika ol sekuntia. Uudelleenaosta aiheutuva lisälaskenta oli siis pieni verrattuna kokonaisaan pienenemiseen. 4.4 Rinnakkaistiedostot Suurten rinnakkaisaoen käsittelemät tietomäärät on helppo arvioida kertomalla prosessorien lukumäärä prosessorin muistimäärällä. Mikäli käytössä on esimerkiksi 24 prosessoria a okaisella on GB keskusmuistia on lopputulos TB (teratavu). Simuloinnin valmistuttua halutaan mahdollisesti tallettaa tulokset, a oskus on mielekästä esimerkiksi simuloinnin edistymisen valvomiseksi tai simulointivideota varten tallettaa myös välituloksia, esimerkiksi okaista simuloinnin aika-askelta kohden. Sanonnalle "Teraflopsit tuottavat teratavua" löytyy tänään katetta eritoten plasmafuusion simuloinneissa a tilanne mutkistuu tulevaisuudessa yhä suurempien simulointien ollessa mahdollisia. Empiirisesti havaitsimme rinnakkaisohelmien kohdalla, että tiedostosta lukeminen a siihen kiroittaminen usein toteutetaan keräämällä tieto pieninä osina yhteen prosessiin, oka kiroittaa tiedot tiedostoon kovalevylle. Tässä on oiva esimerkki siitä miten rinnakkasiohelmaa ei ole suunniteltu loppuun asti rinnakkaiseksi, vaan siihen on äänyt sekventiaalinen osuus, oka käytännössä määrää aoaan. Eräässä tapauksessa saimme ohelman, ossa itse simulointilaskenta 24 prosessorilla kest sekuntia, mutta (väli)tuloksen kiroittaminen kovalevylle 8 sekuntia, olloin 2 prosessoria oli outilaana 9 % aoaasta. Standardirinnakkaiskirastoissa on o pitkään tuettu tiedostoen rinnakkaislukemista a -kiroittamista, a nämä ovatkin suositeltavia mikäli vain supertietokoneeseen tai laskentaklusteriin on rakennettu rinnakkainen tiedostoärestelmä. Lisäksi on olemassa näiden rutiinien päälle rakennettua kirastoa, kuten esimerkiksi HDF5 (Hierarchical Data Format [9]), otka vielä entisestään yksinkertaistavat rinnakkaista tiedostonkäsittelyä tehden sen melkein normaaliin tiedostonkäsittelyyn verrattavaksi. Esimerkkitapauksessa tiedostoon kiroittaminen lyheni sekuntiin. 4.5 Kirastorutiinien hyödyntäminen Ohelmien rinnakkaistuksen perusrakenteen lisäksi pyrimme myös selvittämään mahdollisuuksia käyttää rinnakkaisohelmointikirastoen taroamaa tukea. Rinnakkaisohelmointistandardi Message Passing Interface MPI [] perustuu laskentanoodien väliseen viestinvälitykseen, ossa tavua lähetetään a vastaanotetaan sovitun kaavan mukaisesti. MPI-kirastoen kehittyessä niihin on rakennettu yhä enemmän toiminnallisuutta erityyppisille rinnakkaisohelmissa usein
28 Supertietokoneiden tehoa anotaan esiintyville algoritmeille, oita on siis turha lähteä rakentamaan itse. Yksi esimerkki on ns. all-reduce operaatio, ossa okaisesta prosessorista kootaan tietty määrä dataa yhteen prosessoriin, a tämä prosessori suorittaa datalle onkun operaation, esimerkiksi ynnää kaikki arvot yhteen, a lopputulos kommunikoidaan takaisin kaikille prosesseille. Sen siaan, että lähdemme rakentamaan rutiinia, ossa kommunikoidaan rinnakkaiskiraston lähetys- a vastaanottokutsuilla, voimme käyttää hyväksi yksinkertaista MPI_All_reduce-tyyppistä kutsua, oka hoitaa kommunikaation mitattavasti tehokkaammin kuin omat rutiinit. Toinen esimerkki liittyy tilanteeseen, ossa esimerkiksi kolmidimensioista hilaakoa halutaan kuvata prosesseille: voimme tietysti itse päätellä miten kannattaa akaa alihilat eri prosesseille, mutta MPI:stä löytyy tukea oka helpottaa tätä työtä. 5 Koodin optimointi Varsinaiset tekniikat oiden avulla pyrittiin nopeuttamaan ohelmia olivat välimuistin tehokas hyödyntäminen sekä SSE-vektorointi. 5. Välimuistin optimointi Välimuistin tarkoitus on luoda prosessorille mielikuva, onka mukaan tietokoneen keskusmuisti on nopea. Jos ohelma tarvitsee tavua, otka voidaan lukea välimuistista, on hakuaika noin kellonaksoa, kun taas keskusmuistista haku kestää pyöreästi kellonaksoa. Tämä mielikuva saadaan aikaiseksi siten, että uusia arvoa ladataan keskusmuistista välimuistiin sillä aikaa kun prosessori tekee laskentaa edellisellä kerralla välimuistiin luettuen arvoen kanssa. Välimuistiin kiroitetaan a sieltä luetaan peräkkäisiä tavua välimuistirivin verran, tyypillisesti 64 tavua eli kahdeksan kaksoistarkkuuden liukuluvun verran. Välimuistin käytön optimointi voidaan nyt tiivistää lauseeseen "Käytä tehokkaasti hyväksesi o välimuistiin luettua arvoa äläkä hyppää mielivaltaisella tavalla ympäri keskusmuistia lukien yksittäisiä arvoa sieltä täältä". Jos kuitenkin tarvittavat tavut ovat kaukana toisistaan skaalalla 64 tavua kannattaa yrittää ärestää tietorakenteet uudelleen siten, että tarvittavat arvot ovat peräkkäin muistissa. Tätä periaatetta käyttäen ryhmämme onnistui nopeuttamaan yleisesti käytössä olevaa proteiinisekvensointiohelmaa PSI-BLAST [4]. Proteiini koostuu pitkästä nauhasta aminohappoa, oita löytyy 2 eri tyyppiä. Sekvensoinnissa pyritään asettamaan kaksi proteiinia rinnakkain siten, että niillä on mahdollisimman monta osumaa eli kaksi samaa tai melkein samaa aminohappoa vierekkäin. PSI-BLAST-ohelmassa proteiinin okaista aminohappoa varten käytettiin 2 tavun kokoista tietuetta, ossa on ensimmäisenä äsenenä yhden tavun pituinen aminohapon tyyppiä edustava kirain letter, toisena äsenenä kahdeksan tavua pitkä aminohapon satunnainen osumatodennäköisyys e_value, ne. Tietueet oli ärestetty muistiin taulukkoon. Kuitenkin suurin osa ohelman aoaasta kului peräkkäisten aminohappotietueiden läpikäymiseen etsien aminohapon tyyppiä. Käytännössä siis välimuistiin luettiin okaisella lukukerralla 64 tavua, mutta niistä käytettiin vain oka 2:s, eli noin tavua, ennen kuin seuraava välimuistirivi piti lukea. Järestimme tietorakenteet uudelleen siten, että tietuetaulukon siaan meillä oli yksi taulukko okaista alkuperäisen tietueen äsentä kohden (katso kuva 2). Lukemalla nyt pelkästään tyyppitietue välimuistiin voidaan käyttää hyväksi okaista luettua tavua, a koko ohelmaa voidaan nopeuttaa opa tekiällä kolme [5].
Westerholm, Aspnäs, Signell 29 Kuva 2: Alkuperäinen (vasen) a optimoitu (oikea) PSIBlast-ohelman tietue. 5.2 Tietorakenteet Välimuistin optimointi on käytännössä sellaisten tietorakenteiden käyttöä, otka ovat sopusoinnussa välimuistin toiminnan kanssa. Tyypilliset ohelmissa esiintyvät tietorakenteet ovat vektori a matriisi, mutta oskus ohelmissa käytetään yksinkertaisia tietueita tai linkitettyä listoa. Suoraviivaisesta rakenteestaan huolimatta matriisit voidaan tietoteknisesti esittää eri tavoin. Esimerkkinä mainittakoon usein vastaan tullut tilanne, ossa kolmidimensioista hilaa (sivun pituus N) on esitetty oikeaoppisesti kolmidimensioisena matriisina, mutta laskennan ossakin vaiheessa muodostetaan hilapisteiden perusteella lineaarinen matriisiyhtälöryhmä, onka matriisi on erittäin harva a kokoa N. Tällöin kannattaa ilman muuta siirtyä käyttämään harvaa matriisia a valita harvaa matriisia hyödyntävä ratkaisualgoritmi. Harvan matriisin esitystapoa on useita, oten esitystavan valinnassa täytyy suunnitella koko laskentaketu etukäteen, otta se menee kivuitta läpi. Toinen maininnan arvoinen tietorakenne liittyy listoihin, oista halutaan etsiä arvoa tietyin ehdoin, esimerkiksi löytyykö annettu arvo listasta tai mikä on lähinnä pienempi arvo. Mikäli lista on hieman pitempi, enemmän kuin kymmeniä elementteä, kannattaa esimerkiksi ärestää listan arvot suuruusärestykseen a käyttää binäärihakua arvoen etsimiseen, tai ryhmitellä listan arvot hash-tyyppisillä avaimilla. 5. Vektorointi Moderneista prosessoreista on o pitkään löytynyt ns. vektoroitua multimediakäskyä, Streaming SIMD Extensions SSE, (SIMD = Single Instruction Multiple Data), oissa käytetään normaalia pitempiä tyypillisest8-bittisiä rekistereitä. Näihin rekistereihin voidaan tuoda kaksi 64-bittistä kaksoistarkkuuden liukulukua tai vaihtoehtoisesti nelä 2-bittistä yksinkertaisen tarkkuuden liukulukua. Laskennallinen etu on saavutettavissa siten, että suoritetaan aritmeettisia toimintoa näiden rekistereiden kesken tätä varten olevilla SSE-käskyillä, olloin yhden käskyn suorittaminen saa aikaan kahden (tai yksinkertaisen tarkkuuden tapauksessa nelän) samanaikaisen liukulukulaskutoimituksen suorittamisen. Teoreettisesti laskien kaksoistarkkuuden aritmetiikka voidaan nopeuttaa tekiällä 2 (katso kuva ). Vastaanottamiemme ohelmien oukossa ei ollut yhtäkään, ossa x86- arkkitehtuurin SSE-multimediarekistereitä olisi käytetty tehokkaasti hyväksi! Ohelmien tehokkuuden kannalta vektorilaskenta SSE-rekistereillä oli täysin käyttämätön resurssi. Lähdekoodeissa esiintyi monesti useampikin silmukka, oi-
Supertietokoneiden tehoa anotaan Kuva : Nelän yksinkertaisen tarkkuuden liukuluvun samanaikainen kertolasku SSEvektoroinnilla. den olisi pitänyt pystyä hyödyntämään SSE-vektorointia, mutta ostakin syystä kääntäät eivät tuottaneet vektoroitua koodia. Myös kääntään tekemän periaatteessa suoraviivaisesti vektoroitavissa olevan silmukan tekemän konekielen läpikäynti osoitti, ettei kääntää tehnyt vektorikäskyä ollenkaan. Tilanteen ymmärtämiseksi kiroitimme plasmasimuloinneissa usein esiintyvälle ns. Arakawamenetelmälle [6] konekieliversion, ossa eksplisiittisesti käytimme pelkästään vektorikäskyä koko SSE-rekisterille. Jo 96-luvulla huomattiin, että virtausmekaniikan simuloinneissa esiintyy numeerista epästabiilisuutta, onka seurauksena pyörteiden kineettinen energia kasvaa raattomasti. Keskeinen laskettava suure on kahden virtauskentän ζ a ψ 2- dimensioinen Jakobiaani J(ζ,ψ) = ζ ψ x y ζ y ψ x () Arakawa osoitti, että ensimmäisen kertaluvun osittaisderivaattoen suoraviivaisessa nelän pisteen diskretoinnissa (lähinaapurit x- a y-suunnassa) systeemin kokonaisenergia ei säily. Sen siaan hän ohti Jakobiaanin diskretoinnille kokonaisenergian säilyttävän muodon, ossa on mukana yhdeksän pistettä kummastakin virtauskentästä muodostaen x matriisin laskettavan Jakobiaanin elementin ympärille. Kuvissa 4 a 5 on esitetty miten paikka-avaruus on diskretoitu a Arakawan menetelmällä pyyhitään virtauskentän 2-dimensioisen matriisin yli, kuvassa 4 ilman SSE-vektorointia a kuvassa 5 SSE-vektoroinnilla. Koodin optimoinnin tulos oli odotettu: ohelma nopeutui tekiällä,8. Mistä syystä sitten kääntää ei suostu vektoroimaan Arakawa-koodia? Tälle on itse asiassa olemassa hyvä syy. Aatellaan tapausta ossa Arakawa-rutiini toteutetaan aliohelmakutsulla, onka lähtöarvoina on kaksi matriisia (ζ i, a ψ i, ) sekä tulosmatriisina Jakobiaani J i, (ζ,ψ). Jos alirutiini kutsutaan siten, että toinen lähtömatriiseista a tulosmatriisi ovatkin sama matriisi(!), tulokset tulevat olemaan aivan erilaiset riippuen siitä onko aliohelma vektoroitu tai ei, olloin kääntää tekee päätöksen olla vektoroimatta aliohelmaa. Jos kuitenkin käyttää ilmoittaa eksplisiittisesti että erinimiset osoittimet, kuten matriisit tai vektorit, varmasti osoittavat eri muistipaikkoihin, onnistuu vektorointi hyvin. Esimerkkinä käyköön Intelin icc-kääntää [7], olle ilmoitetaan
Westerholm, Aspnäs, Signell i= = i= =2 i= = i= =4 i=2 = i=2 =2 i=2 = i=2 =4 Kuva 4: Iterointi 6x4-kokoisen gridin yli käyttäen Arakawan x matriisia. i= = i= = i=2 = i=2 = Kuva 5: Arakawan menetelmän iterointi 6x4-kokoisen gridin yli käyttäen SSE-vektorointia. Yhtenäinen viiva a katkoviiva edustavat kaksoistarkkuuden lukua, otka sioittuvat SSE-rekisterin vasemmalle a oikealle puolelle.
2 Supertietokoneiden tehoa anotaan oko komentoriviltä icc -fno-alias tai restrict avainsanalla parametreille aliohelmakutsussa, että tarkoitamme nimenomaan eri matriisea, olloin kääntää osaa riittävän selkeissä tapauksissa generoida erittäin käyttökelpoista vektoroitua koodia. Muut C-kääntäät, kuten GNU [], Pathscale [2] a Portlandin PGI [], pystyät tuottmaaan yhtä tehokasta vektoroitua koodia vain hyvin yksinkertasille lausekkeille. Lähitulevaisuudessa vektorirekisterien pituus kaksinkertaistuu 256 bittiin, olloin yhteen rekisteriin mahtuu kerralla nelä kaksoistarkkuuden liukulukua avaten siten mahdollisuuden yhä suuremmille nopeutuksille. 6 Tuloksia Mitkä olivat havaintomme rinnakkaisohelmista a sekventiaalisista ohelmista oita aetaan supertietokoneissa ympäri Eurooppaa a myös maailmanlaauisesti nimenomaan rinnakkaisohelmoinnin sekä koodin optimoinnin kannalta? Yleistoteamus on positiivinen: vielä voi parantaa ohelmia käyttämään paremmin hyväksi prosessorien tehoa. Usein sekventiaalinen ohelma voidaan rinnakkaistaa a tällä tavoin ohelma voidaan nopeuttaa tekiällä -. Jo rinnakkaistettuen ohelmien uudelleensuunnittelu merkitsi usein, että ohelmat, otka ennen pyörivät korkeintaan 6 tai 2 prosessorilla, voidaan tarkemmin suunnitellun rinnakkaistamisen älkeen aaa opa 24 ta48 prosessorilla. Rinnakkainen tiedostonkäsittely on mielestämme se osa, ossa voi suhteellisen ärkevällä ohelmointipanostuksella saavuttaa merkittävimmät nopeutukset tapauksissa, oissa ohelma tuottaa palon dataa kovalevylle. Jos ohelmassa on keskeisiä rutiinea, otka voidaan vektorisoida SSE-tyyppisillä käskyillä, voidaan hyöty usein saada irti pienellä muutoksella lähdekoodiin tai kääntään asetuksilla olettaen, että erinimiset tietorakenteet todella ovat eri paikoissa muistissa. Koodin optimointi yleensäkin nopeuttaa aoaat noin tekiällä 2, parhaassa tapauksessa, a mikäli aoaika alunperin on ollut tuntea tai päiviä voi nopeutus tekiällä kaksi olla hyvinkin kouriintuntuva parannus. Viitteet. http://www.top5.org 2. http://www.csc.fi/csc/ulkaisut/oppaat/- pdfs/finhpc.pdf/download. Pär Strand, Bernard Guillerminet, Frederic Imbeaux, Rui Coelho, David Coster, Lars-Göran Eriksson, Francesco Iannone, Gabriele Manduchi, Isabel Campos, Matthieu Haefele, Eric Sonnedrücker, Adrian Jackson, Jan Westerholm, Marcin Plociennik a Michal Owsiak: A European Infrastructure for Fusion Simulations, toim. Marco Danelutto, Julien Bourgeois and Tom Gross: PDP 2 Proceedings of the 8th Euromicro Conference on Parallel, Distributed and Network-Based Processing, Pisa, 7.-9. helmikuuta, 2, s. 46 467. 4. http://blast.ncbi.nlm.nih.gov/blast.cgi 5. Mats Aspnäs, Kimmo Mattila, Kristoffer Osowski a Jan Westerholm, Code Optimization of the Subroutine to Remove Near Identical Matches in the Sequence Database Homology Search Tool PSI- BLAST, Journal of Computational Biology, vol. 7, s. -5, 2. 6. A. Arakawa, Computational design for long-term numerical integration of the equations of fluid motion: twodimensional incompressible flow. Part I, Journal of Computational Physics, Vol., s. 9-4, 966 7. http://software.intel.com/en-us/intelcompilers/ 8. http://valgrind.org 9. http://www.hdfgroup.org. http://www.mpi-forum.org. http://gcc.gnu.org 2. http://www.pathscale.com. http://www.pgroup.com