Datalähtöinen ajattelu

Korkean tason kielissä, kuten C#, JavaScript tai Python, ohjelmoija opetetetaan ajattelemaan maailmaa olioiden, luokkien ja rajapintojen kautta. Tämä synnyttää mielikuvan, jossa sovelluksen osat ovat itsenäisiä entiteettejä, jotka kommunikoivat keskenään viestien tai metodikutsujen välityksellä. C-ohjelmoinnissa puolestaan koodia kirjoitetaan suorittimen (processor) ja muistin näkökulmasta. Tietokoneelle ei ole olemassa olioita; sille on olemassa suoritusohjeita ja tavuittain järjestettyä muistia.

Kun C#-koodari luo luokan ilmentymän, taustalla tapahtuu paljon sellaista, mikä jää piiloon. Muistiin varataan tilaa olion kentille, mutta samalla luodaan metadataa, kuten viittauksia tyyppitietoihin ja virtuaalifunktiotaulukoihin (vtable). C-kielessä mitään tällaista ei tapahdu salaa. Jos määritellään rakenne, se vie tasan sen verran tilaa kuin sen sisältämät elementit vaativat, kunhan se on kohdistettu oikein.

Muistin kohdistus (alignment) tarkoittaa datan sijoittamista muistiosoitteeseen, joka on jaollinen datatyypin koolla. Laitteisto lukee muistiväylää (reitti muistista suorittimeen) kiinteinä lohkoina. Kun tyypin alkukohta vastaa lohkon koon jaollisuutta, suoritin hakee datan yhdellä rekisterilatauksella. Väärin kohdistettu data jakautuu kahden lohkon alueelle, mikä pakottaa suorittimen tekemään useita muistihakuja, bittisiirtoja ja maskauksia hidastaen suoritusta eteenkin pitkissä silmukoissa radikaalisti.

Esimerkiksi, kun suoritin huomaa, että tarvittava tieto puuttuu välimuistista, se ei hae päämuistista pelkästään pyydettyä neljän tai kahdeksan tavun muuttujaa. Se lataa kerralla kokonaisen 64 \text{ tavun} pituisen lohkon (512 \text{ bittiä}). Tämän operaation tarkoituksena on tuoda silmukan seuraavat alkiot ja muuttujat valmiiksi suorittimen lähelle (L1-välimuistiin), jotta ohjelman ei tarvitse odottaa hidasta päämuistia jokaisen rivin kohdalla. Kun data on saatu ladattua välimuistiin, suoritin alkaa ajaa koodia rivi riviltä. Tällä tasolla x64-suorittimen sisäiset rekisterit ja sähköiset väylät käsittelevät tietoa 64 \text{ bitin} (8 \text{ tavun}) kiinteissä lohkoissa, ei yksi bitti kerrallaan.

Koko tietokoneen muisti voidaan nähdä yhtenä valtavana, peräkkäin indeksoituna tavutaulukkona (lineaarinen osoiteavaruus). Korkean tason kielten viittaukset (references) ovat usein monimutkaisia, virtuaalikoneen hallitsemia kahvoja (handles) tai osoittimia, joiden todellista sijaintia fyysisessä muistissa siivousohjelma (garbage collector) saattaa muuttaa lennosta. C-kielessä osoitin (pointer) on muistiosoite, raaka numero, joka kertoo, mistä kohdasta tätä lineaarista tavujonoa haluttu tieto alkaa.

Tämän eron ymmärtäminen muuttaa tavan ratkaista ongelmia. Korkean tason kielillä rakennetaan usein puumaisia tai verkkomaisia rakenteita, joissa oliot viittaavat toisiin olioihin. C-ohjelmoija puolestaan sijoittelee datan muistiin niin, että suoritin pystyy lukemaan sitä mahdollisimman tehokkaasti peräkkäisistä osoitteista. Tätä kutsutaan datalähtöiseksi suunnitteluksi (DOD, data-oriented design), joka on yleinen ohjelmointiparadigma.

Suorittimen ja päämuistin välinen nopeusero on nykyaikaisissa tietokoneissa valtava. Kun suoritin tarvitsee tietoa muistista, se ei hae yhtä haluttua tavua, vaan se lataa kerralla kokonaisen välimuistirivin (cache line), joka on tyypillisesti 64 tavun pituinen lohko. Jos tarvittava tieto löytyy tästä lohkosta, puhutaan välimuistiosumasta (cache hit). Tietysti operaatiota varten haettu tieto on haetussa lohkossa, mutta varsinainen hyöty tulee siitä, jos myös seuraavan kymmenen operaation tiedot löytyvät sieltä. Jos ohjelma taas hyppii ympäri muistia hakemassa erillisiä oliota, seurauksena on välimuistihuti (cache miss), jolloin suoritin joutuu odottamaan satoja syklejä datan saapumista päämuistista. Tietenkin esimerkiksi 200 sykliä modernilla suorittimella on vain ~50 nanosekuntia, mutta kun käsitellään valtavia määriä dataa, pienikin määrä kertoutuu helposti.

Huom: Tähän liittyy myös termi puskuri (buffer), joka tarkoittaa väliaikaista varastoa muistissa, mikä on olemassa siksi, että pienten datamäärien siirtäminen monta kertaa on niin hidasta verrattuna siihen, että siirretään yksi suuri lohko kerralla.

Historiallisesti 1970-luvulla, kun C-kieli kehitettiin Unix-käyttöjärjestelmän rakentamiseen, muisti oli äärimmäisen kallista ja sitä oli vähän. Silloin koodi oli pakko pitää tiiviinä resurssipulan vuoksi. Nykyään muistia on gigatavuittain, mutta suorittimen ydin pystyy käsittelemään dataa moninkertaisesti nopeammin kuin hidas muistiväylä kykenee sitä toimittamaan. Moderni suoritin yhdistettynä moderniin abstraktoituun koodiin on kuin valtava tehdas, joka hoitaa kaiken työnsä maanantaina ja odottelee lisää raaka-aineita seuraavat kuusi päivää. Datalähtöisellä suunnittelulla pystymme varmistamaan, että tehtaalla on koko ajan töitä ja nopeuttamaan tietokoneen toimintaa valtavasti.

Datarakenteet ja hukkasijoittelu

Korkean tason kielissä muuttujien määrittelyjärjestyksellä luokan sisällä ei ole merkitystä sen viemään tilaan. C-kielessä kääntäjän on noudatettava suorittimen kohdistusvaatimuksia, minkä vuoksi se lisää näkymättömiä tyhjiä tavuja (padding) muuttujien väliin.

Kohdistusvaatimus tulee yksittäisestä jäsenestä, ei rakenteesta kokonaisuutena. Jokainen jäsen pitää alkaa osoitteesta joka on jaollinen kyseisen jäsenen koolla.

typedef struct {
    char activeFlag;      // 1 tavu + 7 täytetavua
    void* contextPointer; // 8 tavua
    int32_t resourceId;   // 4 tavu + 4 täytetavua
} WastefulState;

char on 1 tavun kokoinen, joten se voi alkaa mistä osoitteesta tahansa. Mutta koska contextPoiner onkin 8 tavua, sen on alettava osoitteesta, joka on jaollinen kahdeksalla. Sen vuoksi charin perään lisätään 7 tavua täytettä. Lisäksi rakenteen kokonaiskoko on oltava jaollinen sen suurimman jäsenen kohdistusvaatimuksella, jonka vuoksi int32_t jälkeen laitetaan vielä 4 täytetavua. Tämä WastefulState rakenne vie muistissa 24 tavua, vaikka siinä on todellista dataa pelkästään 13 tavua ja se mahtuisi hyvin 16 tavuun (8 \cdot 2 = 16). C-ohjelmoija järjestää muuttujat aina suurimmasta pienimpään, jolloin täytetavujen tarve minimoituu.

Katsotaanpa sitten, miten peliohjelmoija varaisi muistia peliobjekteilleen.

typedef struct {
    float x;
    float y;
    float z;
} Vector3;

Tässä määritellään kolmiulotteinen vektori. Koska float-tyyppi vie tyypillisesti 4 tavua, tämä rakenne vie muistissa tarkalleen 3 \cdot 4 = 12 tavua.

Seuraavaksi luodaan rakenne, joka kuvaa pelimaailman hahmoa. Huomaa, miten datan sekaan ei ole sotkettu toiminnallisuutta:

typedef struct {
    Vector3 position;
    Vector3 velocity;
    int32_t health;
    int32_t id;
} Entity;

Tässä Entity-rakenne sisältää kaksi aiemmin määriteltyä Vector3-rakennetta ja kaksi kokonaislukua. Muistiin muodostuu peräkkäinen 32 tavun mittainen lohko (12 + 12 + 4 + 4 = 32), joka voidaan kopioida tai lukea yhdellä kertaa.

Kun halutaan käsitellä useita hahmoja, korkean tason kielissä luotaisiin lista olioista. C-ohjelmoija varaa muistista yhtenäisen taulukon:

#define MAX_ENTITIES 1024
Entity entityPool[MAX_ENTITIES];

Tämä varaa pinosta (stack) tai globaalista muistialueesta yhtenäisen lohkon, jonka koko on 1024 \cdot 32 = 32768 tavua (32 kilotavua). Tämä mahtuu kokonaisuudessaan nykyaikaisen suorittimen L1-tason välimuistiin. C-kielessä taulukot, kuten entityPool, ovat käytännössä osoittimia varatunkokoisen muistialueen alkuun.

Kun näitä hahmoja halutaan päivittää, luodaan funktio, joka ottaa vastaan ainoastaan sen datan, jota se tarvitsee:

void updateEntities(Entity* pool, int32_t count, float deltaTime) {
    for (int i = 0; i < count; i++) {
        pool[i].position.x += pool[i].velocity.x * deltaTime;
        pool[i].position.y += pool[i].velocity.y * deltaTime;
        pool[i].position.z += pool[i].velocity.z * deltaTime;
    }
}

Tämä silmukka lukee muistia täysin lineaarisesti alusta loppuun. Kun suoritin käsittelee indeksiä pool[0], laitteistotason esihaku (hardware prefetcher) huomaa säännöllisen muistinkäyttömallin ja lataa valmiiksi seuraavat indeksit välimuistiin ennen kuin silmukka edes ehtii niihin. Suorituskyky on moninkertainen verrattuna siihen, että taulukko sisältäisi viittauksia eri puolelle muistia hajautettuihin olioihin.

Osoittimet ja void*

Moni aloitteleva C-koodari ihmettelee, miksi siinä käytetään osoittimia. Tähän on kaksi syytä.

Ensinnäkin C kopioi kaiken arvona funktiolle. Kun kirjoitat void foo(Entity e), funktio saa kopion koko rakenteesta. On aivan sama kuinka suuri Entity on, se kopioidaan pinoon joka kutsulla. Osoittimella void foo(Entity* e) kopioidaan ainoastaan 8-tavuinen osoite, ei dataa.

Lisäksi joskus data on tarpeeksi pientä, että sen voisi ihan hyvin kopioidakin. Mutta jos funktion pitää muuttaa alkuperäistä arvoa, vaikkapa int32_t, silloin osoitin on oikea valinta. void foo(int32_t x) muuttaa paikallista kopiota. void foo(int32_t* x) puolestaan kirjoittaa kutsujan välittämään muuttujaan.

Mutta korkean tason kielet hoitavat viittaukset itse. Miksei C tee niin? C on kirjoitettu käyttöjärjestelmien rakentamiseen. Silloin ei ole ketään jonka puoleen kääntyä, ei runtimea, ei virtuaalikonetta. Sinä olet alin kerros.

Korkean tason kielten koodaajalle olioiden kantama tyyppitieto (runtime type information) on itsestäänselvyys. C-kielessä tätä turvaverkkoa ei ole, ja sen huipentuma on void* (tyyppitön raaka osoitin). Se on anonyymi muistiosoite, numero lineaarisessa osoiteavaruudessa, vailla mitään tietoa siitä, mitä sen takana on tai kuinka suuri kyseinen muistialue on. C-ohjelmoija käyttää sitä rakentaessaan täysin yleiskäyttöisiä järjestelmiä, kuten muistialueita, joissa datan tyypillä ei ole merkitystä varaushetkellä. Se vaatii aina manuaalisen tyyppimuunnoksen (cast) ennen käyttöä, mikä siirtää vastuun tyyppiturvallisuudesta koodarille.

void* rawMemory = entityPool;
Entity* firstEntity = (Entity*)rawMemory;
int32_t firstId = firstEntity->id;

Tässä rawMemory osoittaa hahmotaulukon entityPool alkuun tietämättä sen sisältöä. Se muunnetaan manuaalisesti Entity*-tyypiksi, jolloin suoritin osaa lukea sen kenttiä oikeilta etäisyyksiltä.

Muistin varaaminen ja malloc

Kun tarvittavan tiedon määrä selviää vasta ohjelman suoritusaikana, muisti on varattava dynaamisesti kekomuistista (heap). C-kielen perustyökalu tähän on malloc (memory allocation), joka pyytää käyttöjärjestelmän muistinhallinnalta halutun kokoisen yhtenäisen tavulohkon. Funktio ei tiedä mitään datatyypeistä; sille annetaan parametrina pyydetty koko tavuina, ja se palauttaa tyypittömän void*-osoittimen varatun alueen alkuun. Jos vapaata muistia ei ole saatavilla, malloc palauttaa NULL-osoittimen. Tämä täytyy aina tarkistaa ennen muistiin koskemista.

Tavallisin tapa käyttää funktiota on laskea tarvittava tila sizeof-operaattorilla:

int32_t count = 100;
int32_t* scoreArray = (int32_t*)malloc(count * sizeof(int32_t));
if (scoreArray == NULL) return;

Tässä varataan yhtenäinen 400 \text{ tavun} lohko sadalle kokonaisluvulle. malloc ei alusta muistia, eli sen sisältö on täynnä sellaista bittiroskaa, mitä kyseisessä muistiosoitteessa sattui aiemmin olemaan.

Kekomuistin varaamiseen on olemassa myös muita standardifunktioita. calloc toimii kuten malloc, mutta se ottaa parametreikseen alkioiden määrän ja yksittäisen alkion koon erikseen, sekä alustaa koko varatun muistialueen nollaksi. Tämä suojaa bugeilta, mutta aiheuttaa pienen suorituskykykuorman alustustyön vuoksi. realloc käytetään olemassa olevan muistivarauksen koon muuttamiseen lennosta. Se yrittää ensisijaisesti laajentaa nykyistä lohkoa sen perästä, mutta jos tilaa ei ole, se etsii uuden riittävän suuren paikan, kopioi vanhan datan sinne ja vapauttaa alkuperäisen alueen automaattisesti.

Kekomuistin ulkopuolella C-kielessä on kaksi muuta tapaa hallita muistia. Paikalliset muuttujat varataan automaattisesti pinoon, kun funktio käynnistyy, ja ne häviävät välittömästi funktiosta poistuttaessa. Pinoon voidaan varata dynaamisesti tilaa myös alloca-funktiolla tai säätyvillä taulukoilla (VLA, Variable-Length Array), mutta suuria varauksia vältetään piron rajallisen koon vuoksi. Ohjelmakoodin ulkopuolella määritellyt globaalit muuttujat ja static-määreellä varustetut muuttujat varataan kiinteästi ohjelman käynnistyessä, ja ne pysyvät samassa muistiosoitteessa ohjelman sulkeutumiseen saakka.

Joustavat taulukkojäsenet

Korkean tason kielissä käytetään usein geneerisiä listarakenteita, jotka kasvattavat kokoaan dynaamisesti taustalla. C-kielessä dynaaminen muistinvaraus on operaatio, joka suorituksessa keskitetään yhteen paikkaan. Datalähtöisessä ohjelmoinnissa globaalit kiinteän kokoiset taulukot ja muistialueet (memory arenas) ovat ensisijainen tapa hallita tietoa.

Kun korkean tason kielessä luodaan luokka, joka sisältää vaihtelevan määrän dataa, luokan sisälle laitetaan viittaus erilliseen listaan tai taulukkoon. Tämä synnyttää muistin hajanaisuutta. C-standardit tarjoavat tähän ratkaisuksi joustavat taulukkojäsenet (flexible array members). Rakenteen viimeiseksi jäseneksi jätetään joustava taulukko (dataBytes[]), joka ei vie yhtään tavua rakenteen koossa. Se on pelkkä nimitunniste joka osoittaa rakenteen loppuun. Kun rakenteelle varataan muistia, sille varataan sen oman koon lisäksi dynaamisesti tarvittava määrä lisätavuja yhtenäisenä lohkona. Näin otsikkotiedot ja itse säätyvä data istuvat samassa välimuistirivissä.

typedef struct {
    int32_t packetId;
    int32_t payloadLength;
    uint8_t dataBytes[];
} NetworkPacket;

Rakenne ei sisällä osoitinta dataan, vaan dataBytes alkaa muistissa payloadLength-muuttujan jälkeisestä tavusta ilman erillistä muistihakua. Muistia varataan dynaamisesti rakenteen peruskoko plus datan vaatimat lisätavut. Tämä tehdään laskemalla koot yhteen malloc-kutsussa:

int32_t dataSize = 64;
NetworkPacket* packet = malloc(sizeof(NetworkPacket) + dataSize);
packet->packetId = 101;
packet->payloadLength = dataSize;

Nyt muistiin on luotu yksi yhtenäinen 72 tavun lohko. Taulukkoon dataBytes viitataan aivan kuten tavalliseen taulukkoon:

packet->dataBytes[0] = 0xFF;
packet->dataBytes[63] = 0xAA;

Korkean tason kielissä taulukko olisi erillinen olio omassa muistiosoitteessaan, mikä vaatisi osoitinhakuja. C-menetelmässä dataBytes ei ole muistiin tallennettu osoitin. Se ei vie 8 tavua tilaa, eikä sille ole varattu muistipaikkaa. Se on vain kääntäjän tiedossa oleva nimi sille muistiosoitteelle, joka alkaa heti payloadLength-muuttujan jälkeen. Suoritin lukee datan suoraan ilman välikäsiä.

Koska koko 72 tavun paketti on yhtä puuta, kun suoritin lukee muuttujan packetId, se lataa samalla kertaa suorittimen L1-välimuistiin (joka lukee muistia 64 \text{ tavun} lohkoissa) lähes koko datasisällön. Mitään välimuistihutia ei voi tapahtua taulukkoon koskettaessa.

Koska malloc teki yhden varauksen, käyttöjärjestelmälle tarvitsee sanoa ainoastaan kerran free(packet). Ei ole pelkoa siitä, että otsikko vapautetaan mutta sen sisäinen taulukko jäisi roikkumaan muistiin vuotona.

Sijoittava uusi-operaattori ja muistialueet

C#- tai Java-kielissä uusi objekti luodaan aina järjestelmän hallitsemaan kekomuistiin new-avainsanalla. C-ohjelmoija välttää suoritusvaiheen dynaamisia järjestelmäkutsuja ja käyttää tekniikkaa, joka vastaa C++-kielen sijoittavaa uusi-operaattoria (placement new). Ideana on varata yksi suuri raaka muistialue (memory arena), josta ”lohkotaan” pienempiä osia siirtämällä osoitinta eteenpäin ja alustamalla tietorakenteet olemassa olevaan muistiin ilman erillisiä muistinvarauskutsuja.

_Alignas(Entity) uint8_t memoryArena[1024];
Entity* allocatedEntity = (Entity*)&memoryArena[0];
allocatedEntity->id = 99;

Ongelmanratkaisu ilman automaattisia turvaverkkoja

Kun siirrytään C-kieleen, luovutaan kahdesta suuresta korkean tason kielten mukavuudesta: automaattisesta roskienkeruusta ja poikkeustenhallinnasta (exceptions). C-ohjelmoinnissa tämä on mahdollisuus saavuttaa täydellinen determinismi. Ohjelman suoritusajat ovat ennakoitavia, koska taustalla ei koskaan käynnisty yllättäviä prosesseja, jotka pysäyttäisivät suorituksen muistin siivoamisen ajaksi.

Poikkeusten puuttuminen tarkoittaa sitä, että virheenkäsittely on integroitava osaksi koodin normaalia kulkua. Korkean tason kielissä käytettävä try-catch-rakenne aiheuttaa suorituskykykuormaa ja monimutkaistaa ohjelman kulkua, koska virhe voi kelata usean funktiokutsun taaksepäin funktiokutsupinossa (call stack) etsiessään oikeaa käsittelijää. C-kielessä virheet käsitellään välittömästi siellä, missä ne tapahtuvat, palauttamalla statuskoodeja tai muuttamalla virhemuuttujan tilaa.

Resurssien omistajuus on C-ohjelmoinnissa manuaalista. Koska kieli ei tarjoa älykkäitä osoittimia tai automaattisia tuhoajia (destructors), koodarin on tiedettävä tarkkaan, kuka omistaa minkäkin muistialueen ja kuinka pitkään se pysyy voimassa. Modernissa C-filosofiassa tämä ratkaistaan usein muuttamalla elinkaaren ajattelutapaa: yksittäisten pienten muistipalojen sijaan hallitaan suuria kokonaisuuksia.

Ohjelman sulkeutuessa moni aloitteleva koodari käyttää aikaa kaikkien varaamiensa muistipalojen vapauttamiseen free-funktiolla. Mutta kun prosessi päättyy, nykyaikainen käyttöjärjestelmä tuhoaa prosessin osoiteavaruuden ja palauttaa muistin takaisin järjestelmään silmänräpäyksessä. Muistin läpikäynti ja vapauttaminen ohjelman sulkuvaiheessa pidentää lopetusaikaa ja kuluttaa suorittimen syklejä turhaan.

Muistin turvallisuus varmistetaan kehitysvaiheessa ja tuotannossa käyttämällä osoiteavaruuden satunnaistusta ja ajonaikaista valvontaa (AddressSanitizer, ASAN). Se kääntää koodiin mukaan tarkistukset, jotka huomaavat laittomat muistiviittaukset heti kun ne tapahtuvat. Lisäksi koodiin kirjoitetaan manuaalisia ajonikaisia rajatarkistuksia (runtime bounds checking) paikkoihin, joissa käsitellään ulkopuolista dataa.

typedef enum {
    SUCCESS = 0,
    ERROR_INVALID_PARAM = -1,
    ERROR_OUT_OF_BOUNDS = -2
} ResultCode;

Tässä luodaan luettelointityyppi (enum), joka kattaa funktion mahdolliset palautusarvot. On vakiintunut tapa käyttää nollaa onnistumisen merkkinä ja negatiivisia arvoja virheinä.

Seuraavaksi funktio suorittaa rajatarkistuksen ja palauttaa virhekoodin:

ResultCode getEntityAt(Entity* pool, int32_t count, int32_t index, Entity* outEntity) {
    if (index < 0 || index >= count) {
        return ERROR_OUT_OF_BOUNDS;
    }
    *outEntity = pool[index];
    return SUCCESS;
}

Funktio ei heitä poikkeusta, vaan palauttaa tilatiedon. Varsinainen tulos kirjoitetaan osoittimen outEntity kautta kutsujan varaamaan muistiin. Tämä estää tarpeen luoda uutta muistivarausta funktion sisällä.

Kutsuva osapuoli käsittelee tilanteen ehtolauseella:

Entity target;
ResultCode result = getEntityAt(entityPool, 1024, 2000, &target);
if (result != SUCCESS) {
    // Virheen käsittely välittömästi tässä
}

Tämä suoritustapa pitää ohjelman kulun selkeänä ja helposti argumentoitavana. Kääntäjä pystyy generoimaan tästä erittäin tehokasta konekieltä, koska hyppykäskyt ovat ennakoitavia ja paikallisia.

Pino-olion elinkaari ja roikkuvat osoittimet

Korkean tason kielissä muistin elinkaari jatkuu automaattisesti niin kauan kuin johonkin olioon on olemassa yksikin viittaus. C-kielessä paikalliset muuttujat asuvat pinomuistissa (stack), ja niiden elinkaari päättyy välimuistitasolla heti, kun funktiosta poistutaan ja pinonosoitin siirtyy takaisin. Jos funktiosta palautetaan osoite paikalliseen muuttujaan, syntyy roikkuva osoitin (dangling pointer). Kutsuja saa osoitteen pinoalueelle, joka on jo vapautettu ja joka ylikirjoitetaan heti seuraavassa funktiokutsussa, mikä johtaa mystisiin ja vaikeasti jäljitettäviin bugeihin.

int32_t* getDanglingPointer(void) {
    int32_t temporaryLocalData = 42;
    return &temporaryLocalData;
}

Tämä koodi palauttaa osoitteen muistiin, joka lakkaa olemasta voimassa välittömästi return-lauseen jälkeen. Tämän vuoksi C-ohjelmoija välittää muistin aina ylhäältä alaspäin parametreina.

Nyrkkisääntö on, että kutsuja varaa ja vapauttaa, funktio vain täyttää. Välitä muistiosoite ylhäältä alaspäin argumenttina (out-osoitin) tai varaa tila dynaamisesti malloc-funktiolla, jolloin elinkaari ei lopu funktion päättyessä. Älä koskaan palauta osoitinta funktion sisällä pinoon luotuun paikalliseen muuttujaan.

Määrittelemätön toiminta

Korkean tason kielissä virheellinen operaatio, kuten taulukon yli lukeminen tai nollalla jakaminen, johtaa hallittuun poikkeukseen tai ohjelman kaatumiseen. C-kielessä standardin sääntöjen rikkominen johtaa käsitteeseen nimeltä määrittelemätön toiminta (undefined behavior, UB). Kääntäjä voi siis olettaa, ettei moista toimintaa ikinä tapahdu, koska kääntäjä seuraa tiukasti standardia. Tämän oletuksen pohjalta moderni kääntäjä saattaa optimointivaiheessa poistaa kokonaisia ehtolauseita tai koodilohkoja, joita se pitää mahdottomina, mikä saa ohjelman käyttäytymään täysin arvaamattomasti ilman mitään virheilmoitusta.

void checkBoundsAndCrash(int32_t* array, int32_t index) {
    int32_t next = index + 1;
    if (next <= index) return; // Kääntäjä poistaa tämän kokonaan
    array[next] = 0;
}

Tässä etumerkillinen ylivuoto on UB. Kääntäjä olettaa sen olevan mahdoton. Siksi se päättelee, että (index + 1 > index) on aina totta, ja voi optimoida pois koodin, joka riippuu ylivuodon tapahtumisesta.

Järjestelmäkutsut ja standardikirjasto

Korkean tason koodarille tiedoston avaaminen tai muistin varaaminen on yksi metodi muiden joukossa. C-ohjelmoija erottaa C-standardikirjaston funktiot (kuten printf tai malloc) ja varsinaiset käyttöjärjestelmäytimen järjestelmäkutsut (system calls, kuten Linuxin write tai brk). Standardikirjasto toimii puskuroivana välikerroksena. Jos koodissa kutsutaan printf-funktiota merkki kerrallaan, kirjasto kerää tiedot sisäiseen puskuriinsa (väliaikaisvarasto muistissa) ja tekee kalliin käyttöjärjestelmäkutsun ytimeen vasta kun puskuri on täynnä. Matalalla tasolla tämä puskurointi ohitetaan usein suorituskyvyn nimissä.

#include <unistd.h>
void directWrite(void) {
    write(1, "Moi\n", 4);
}

Tämä koodi ohittaa standardikirjaston puskurit ja tekee järjestelmäkutsun Linux-ytimelle pyytäen sitä kirjoittamaan neljä tavua standarditulosteeseen (argumentti 1).

Eli jos käytät printf-funktiota, se ei vie tekstiä heti ruudulle. Se laittaa "Moi"-tekstin C-standardikirjaston sisäisiin ”kottikärryihin” (RAM-muistiin varattuun puskuriin) odottamaan, että sinne kirjoitetaan lisää tavaraa tai että rivi vaihtuu.

Sen sijaan write-komennolla ohitat kottikärryt kokonaan. Sanot käyttöjärjestelmälle: ”Keskeytä kaikki, avaa portit ja vie tasan nämä 4 tavua ruudulle NYT.”

x86 vs. x64 nykypäivän pelinkehityksessä

x86-arkkitehtuurilla ei ole enää merkitystä uusia pelejä tai suorituskykyisiä sovelluksia rakennettaessa. Kaikki nykyaikaiset työpöytäympäristöt, konsolit ja palvelimet toimivat 64-bittisellä käskykannalla, ja mobiilipuolella ARM64 on vastaava standardi.

Tämä muutos ei vaikuta pelkästään muistin määrään, vaan se muuttaa perustavanlaatuisesti sen, miten C-koodia kirjoitetaan ja miten kääntäjä sen optimoi. Vanhassa x86-arkkitehtuurissa yleiskäyttöisiä rekistereitä oli vähän (8 kappaletta), mikä tarkoitti sitä, että kääntäjä joutui jatkuvasti siirtämään muuttujia rekistereistä pinoon ja takaisin (register spilling). x64-arkkitehtuuri tuplaa yleiskäyttöisten rekistereiden määrän 16:een ja tekee niistä kaikista 64-bittisiä.

Pelinkehittäjälle suurin hyöty x64-arkkitehtuurista on se, että SIMD-käskykannat (kuten SSE2 ja AVX) ovat osa standardia alustavaatimusta. x86-maailmassa liukulukulaskenta tehtiin vanhanaikaisella ja hitaalla x87 FPU -arkkitehtuurilla, joka käytti pinomaista rekisterirakennetta. x64-tilassa kääntäjä tekee kaikki tavallisetkin float– ja double-laskennat SSE/AVX-rekistereillä (XMM- ja YMM-rekisterit).

Tämä tarkoittaa, että C-ohjelmoijan ei tarvitse kirjoittaa inline-konekieltä (assembly) hyödyntääkseen suorittimen rinnakkaislaskentaa. Kun tietorakenteet pidetään lineaarisina ja kohdistettuina, kääntäjä kykenee autovektorointiin, eli se muuttaa tavalliset silmukat SIMD-vektorikäskyiksi, jotka käsittelevät useita datayksiköitä samanaikaisesti yhdessä kellojaksossa.

Osoittimet ovat x64-arkkitehtuurissa 64-bittisiä, eli ne vievät 8 tavua muistia. Tämä on tärkeä ottaa huomioon tietorakenteiden suunnittelussa. Jos rakenne sisältää paljon osoittimia, sen koko kasvaa merkittävästi verrattuna 32-bittiseen järjestelmään, mikä puolestaan kuluttaa enemmän välimuistia. C-ohjelmoijat ratkaisevat tämän usein käyttämällä osoittimien sijaan taulukkoindeksejä (esimerkiksi 16- tai 32-bittisiä kokonaislukuja) viittaamaan muihin alkioihin, jolloin rakenteen koko saadaan puolitettua.

typedef struct {
    void* dataPointer;
    uint32_t dataSize;
} DataBlock;

Tässä dataPointer vie 8 tavua ja dataSize vie 4 tavua. Suoritin vaatii, että 8 tavun osoitin on kohdistettu muistiosoitteeseen, joka on jaollinen 8:lla. Siksi kääntäjä lisää automaattisesti 4 tavua tyhjää täytettä (padding) rakenteen loppuun, jolloin kokonaiskooksi tulee 16 tavua.

C-ohjelmoija optimoi tämän järjestyksellä ja tiivistämisellä:

typedef struct {
    unsigned char* bytes;
    uint32_t length;
    uint32_t flags;
} OptimizedBlock;

Tässä kaksi 4 tavun muuttujaa (length ja flags) asetetaan peräkkäin 8 tavun osoittimen jälkeen. Ne täyttävät täsmälleen 8 tavun tilan, jolloin rakenteen kooksi tulee 16 tavua ilman yhtäkään hukatun täytetavun tarvetta.

Huom: Kääntäjän optimointisäännöt (strict aliasing) kieltävät osoittamasta samaan muistipaikkaan kahdella eri tyyppisellä osoittimella (esim. int* ja float*). char* on standardissa määritelty erikoistapaus, joka saa ohittaa tämän säännön. Sillä on lupa osoittaa mihin tahansa muistiin ja lukea sen raakaa tavubitin sisältöä ilman, että kääntäjän optimoinnit rikkovat koodia. Esimerkiksi uint8_t* ei välttämättä nauti tätä samaa erikoisoikeutta kaikilla alustoilla, jos se on toteutettu muuna tyyppinä.

Kun käsitellään suuria määriä dataa, ero muistinkäytössä on merkittävä.

typedef struct {
    uint16_t targetIndex;
    uint16_t sourceIndex;
} Connection;

Jos tässä käytettäisiin kahta 64-bittistä osoitinta, rakenne vie 16 tavua. Käyttämällä 16-bittisiä indeksivaihtoehtoja koko putoaa 4 tavuun. Tämä mahdollistaa neljä kertaa useamman liitoksen mahtumisen samaan välimuistiriviin, mikä nopeuttaa datan läpikäyntiä huomattavasti.

Merkkijonojen nollaterminaattori

Korkean tason kielissä merkkijono (String) on monimutkainen objekti, joka tietää oman pituutensa tavuina tai merkkeinä. C-kielessä ei ole merkkijonotyyppiä; ne ovat raakoja tavutaulukoita (char). Merkkijonon loppu tunnistetaan nollatavusta (\0, nollaterminaattori). Jos tämä nollatavu puuttuu muistista tai se ylikirjoitetaan vahingossa, kaikki standardit merkkijonofunktiot jatkavat muistin lukemista tai kirjoittamista hamaan ikuisuuteen yli varatun alueen rajojen, kunnes suoritin pysäyttää ohjelman muistivirheeseen.

char shortMessage[4] = {'M', 'o', 'i', '\0'};
int32_t messageLength = strlen(shortMessage);

Funktio strlen ei lue pituusmuuttujaa, vaan se aloittaa osoitteesta shortMessage ja laskee tavuja yksi kerrallaan, kunnes se kohtaa arvon \0.

Tiedon ryhmittely ilman olio-ohjelmointia

Yksi suurimmista virheistä, jonka korkean tason kielistä C-kieleen siirtyvä koodari tekee, on yrittää simuloida olio-ohjelmointia C-kielen rakenteilla. Tämä johtaa usein siihen, että rakenteisiin sijoitetaan funktio-osoittimia kuvaamaan ”metodeja”, tai rakennetaan monimutkaisia tyyppimuunnosketjuja simuloimaan perintää.

Olio-ohjelmointi pyrkii kapseloimaan datan ja toiminnallisuuden yhteen paikkaan. Tämä rikkoo datalähtöisen ajattelun, koska se pakottaa suorittimen käsittelemään dataa yksittäisinä, eristettyinä palasina. C-kielessä data ja toiminnallisuus pidetään erillään. Rakenteet ovat passiivisia tiedon säilyttimiä (dumb data containers), ja funktiot ovat algoritmeja, jotka muokkaavat tätä dataa.

Kun funktiolle halutaan antaa pääsy rakenteen tietoihin, rakenne välitetään funktiolle osoittimen avulla. Tämä vastaa korkean tason kielten this– tai self-viittauksia, mutta se tehdään näkyvästi ja ilman ylimääräistä arvaamista. Jos funktio ei muuta rakenteen tilaa, osoitin määritellään const-määreellä, mikä antaa kääntäjälle mahdollisuuden optimoida muistihaut.

Tämä lähestymistapa tekee koodista helpommin testattavaa ja rinnakkaistettavaa. Koska funktioilla ei ole piilotettua sisäistä tilaa, niiden toiminta riippuu niille annetuista parametreista. Tämä poistaa suuren osan niistä synkronointiongelmista, joita monisäikeisessä ohjelmoinnissa yleensä kohdataan.

Koodiesimerkki pelimoottorin fysiikkajärjestelmästä:

typedef struct {
    Vector3 position;
    Vector3 boundingBoxExtents;
} TransformComponent;

Tässä määritellään erillinen komponentti, joka sisältää paikkaan ja kokoon liittyvän tiedon. Se ei tiedä mitään siitä, mikä objekti on kyseessä.

Seuraavaksi luodaan fysiikkatietojen komponentti:

typedef struct {
    Vector3 linearVelocity;
    float mass;
    float frictionCoefficient;
} PhysicsComponent;

Tämä rakenne pitää sisällään liikkumiseen ja massaan liittyvät arvot. Se on täysin riippumaton TransformComponent-rakenteesta.

Kun näitä tietoja käsitellään, luodaan järjestelmä (system), joka ottaa vastaan molemmat komponentit taulukkoina:

void applyGravity(PhysicsComponent* physicsArray, int32_t count, float gravityConstant, float deltaTime) {
    for (int i = 0; i < count; i++) {
        physicsArray[i].linearVelocity.y -= gravityConstant * deltaTime;
    }
}

Tämä funktio käsittelee ainoastaan fysiikkadataa. Se ei koske paikkatietoon, eikä sen tarvitse tietää mitään pelihahmojen grafiikoista tai tekoälystä. Muisti luetaan peräkkäin, mikä takaa maksimaalisen nopeuden.

Paikan päivittäminen tehdään omassa funktiossaan, joka yhdistää molempien komponenttien tiedot:

void integratePositions(TransformComponent* transformArray, const PhysicsComponent* physicsArray, int32_t count, float deltaTime) {
    for (int i = 0; i < count; i++) {
        transformArray[i].position.x += physicsArray[i].linearVelocity.x * deltaTime;
        transformArray[i].position.y += physicsArray[i].linearVelocity.y * deltaTime;
        transformArray[i].position.z += physicsArray[i].linearVelocity.z * deltaTime;
    }
}

Tässä physicsArray on merkitty const-määreellä, koska funktio pelkästään lukee sen arvoja. Tämä rakenne mahdollistaa sen, että fysiikkalaskenta ja paikkapäivitykset voidaan helposti ajaa eri säikeissä, koska datan rajapinnat ovat selkeät ja eristetyt. Korkean tason kielten oliomallissa tämä vaatisi monimutkaista lukitsemista tai olioiden kopiointia säikeiden välillä.

Osoittimen osoitin

Moninkertaiset epäsuorat viittaukset, kuten osoittimen osoitin (T, eli geneerinen type), ovat käsitteellisesti vaikeita koodaajille, jotka ovat tottuneet automaattiseen viittausten hallintaan. C-kielessä tällä rakenteella hallitaan muun muassa dynaamisia taulukkojonoja (vrt. C#-kielen List<T>) tai muutetaan funktion sisällä kutsujan omistaman osoittimen kohdetta. Jos funktiolle välitetään tavallinen osoitin, funktio saa siitä kopion eikä voi muuttaa alkuperäisen osoittimen osoitetta. Välttämällä osoittimen osoitin, funktio voi kirjoittaa uuden muistiosoitteen kutsujan muuttujaan.

Pelimoottoreissa osoittimen osoitinta (T) käytetään, kun funktio luo tai etsii peliobjektin ja sen on puskettava uusi muistiosoite takaisin sinun muuttujallesi. Koska C-kielessä funktioparametrit välitetään aina kopioina, pelkkä T* ei riitä. Jos annat funktiolle osoittimen, funktio saa vain kopion tuosta osoitteesta. Jos funktio varaa uutta muistia sen sisällä, alkuperäinen muuttujasi ulkopuolella ei muutu miksikään (se osoittaa yhä vanhaan paikkaan tai NULL-arvoon). Sinun on annettava osoitteen osoite (&), jotta funktio voi muuttaa itse muuttujaasi.

void LoadTexture(Texture** outTexture) {
    Texture* uusiTekstuuri = malloc(sizeof(Texture)); 
    // Muutetaan alkuperäisen muuttujan sisältöä epäsuorasti
    *outTexture = uusiTekstuuri; 
}

int main() {
    Texture* playerSprite = NULL;
    LoadTexture(&playerSprite);

    // playerSprite osoittaa nyt onnistuneesti varattuun muistiin!
    printf("Tekstuurin osoite muuttui: %p\n", (void*)playerSprite);
    return 0;
}

Kutsuva osapuoli antaa parametrina oman osoittimensa osoitteen muodossa &playerSprite, jolloin funktio pystyy muuttamaan sitä, mihin playerSprite osoittaa. Jos antaisit funktiolle pelkän playerSprite-muuttujan (joka vaatisi funktion tyypiksi Texture*), funktio saisi vain kopion sen sisältämästä osoitteesta (NULL). Kun funktio sisällään muuttaisi tätä kopiota, alkuperäinen playerSprite jäisi silti arvoon NULL, ja juuri varattu tekstuuri hukattaisiin muistivuotona.

Miksi ei luoda alunperinkin Texture-rakennetta? Texture playerSprite; varaisi koko tekstuurin datan (joka voi olla megatavuja kuvadataa)  pinoon, joka on erittäin pieni muistialue. Jos lataat useita isoja tekstuureja näin, pelisi kaatuu heti muistin loppumiseen (stack overflow). Texture* playerSprite = NULL; varaa pinosta ainoastaan 8 tavua tilaa osoitteelle. Itse tekstuuri ladataan malloc-komennolla kekoon.

Texture* tekstuurilista = malloc(100 * sizeof(Texture));

// Nyt jokainen alkio listassa on raakaa tekstuuridataa
Texture playerSprite = tekstuurilista[0];

Unioni datan uudelleentulkinnassa

Korkean tason kielissä ei tunneta rakennetta, jossa useat eri muuttujat alkavat täsmälleen samasta muistiosoitteesta ja jakavat saman fyysisen tilan. C-kielen unioni (union) mielletään usein muistinsäästötyökaluksi menneisyydestä, mutta C-ohjelmoija voi käyttää sitä datan uudelleentulkintaan ilman suorituskykykuormaa. Se mahdollistaa saman tavujonon katsomisen eri näkökulmista riippuen siitä, missä kontekstissa sitä käsitellään.

typedef union {
    uint32_t rawBits;
    struct {
        uint8_t r, g, b, a;
    } channels;
} ColorPixel;

Tämä unioni vie 4 tavua muistia. Väriä voidaan käsitellä yhtenä 32-bittisenä kokonaislukuna (rawBits) nopeaa kopiointia varten, tai yksittäisinä värikanavina (channels.r) ilman matemaattisia bittisiirtoja.

Käännösaikainen ja tyyppitason kontrolli

C-standardi toi kieleen ominaisuuksia, jotka siirtävät monet perinteisesti ajonaikana tehdyt tarkistukset ja tyyppiratkaisut kääntäjän tehtäväksi. Korkean tason kielissä, kuten C#:ssa, käytetään geneerisiä tyyppejä (generics) saavuttamaan tyyppiriippumaton toiminnallisuus. C tarjoaa tähän työkalun nimeltä _Generic-valinta, joka mahdollistaa compile-time polymorfismin ilman suoritusvaiheen ylikuormaa tai dynaamista tyypintunnistusta.

_Generic-avainsana toimii kääntäjälle ohjeena valita tietty lauseke sen mukaan, mikä on annetun muuttujan tyyppi kääntämishetkellä. Tämä on erityisen hyödyllistä matalan tason ohjelmoinnissa, jossa halutaan esimerkiksi tarjota yhteinen rajapinta erikokoisille bittimaskeille tai erisuuruisille liukuluvuille ilman, että koodiin tarvitsee kirjoittaa erillisiä funktioita jokaiselle tyypille manuaalisesti kutsujan toimesta.

Katsotaanpa miten voimme käyttää _Generic-valintaa luomaan yhtenäinen rajapinta vektorien pituuden laskentaan.

float calculateLengthFloat(Vector3 vector) {
    return sqrtf(vector.x * vector.x + vector.y * vector.y + vector.z * vector.z);
}

calculateLengthFloat-funktio käsittelee standardeja float-tyyppisiä vektoreita. Seuraavaksi luodaan vastaava funktio tarkemmille double-vektoreille:

typedef struct {
    double x;
    double y;
    double z;
} Vector3Precise;

double calculateLengthDouble(Vector3Precise vector) {
    return sqrt(vector.x * vector.x + vector.y * vector.y + vector.z * vector.z);
}

Jotta koodaajan ei tarvitse muistaa kahta eri funktion nimeä, luodaan C-makro, joka tekee valinnan automaattisesti tyypin perusteella:

#define calculateLength(V) _Generic((V), \
    Vector3: calculateLengthFloat, \
    Vector3Precise: calculateLengthDouble \
)(V)

Kun koodissa kutsutaan ilmaisua calculateLength(vektori), kääntäjä katsoo muuttujan vektori tyypin ja korvaa makron oikealla funktion nimellä ennen konekielisen koodin generointia. Mitään ajonaikaista tyypintarkistusta ei tapahdu.

Muistin kohdistus (alignment) on toinen alue, johon C:ssä tuotiin standardoidut työkalut: _Alignas ja _Alignof. Jokaisella tietotyypillä on laitteistotason vaatimus siitä, mistä muistiosoitteesta sen lukeminen on suorittimelle optimaalista. Jos data sijoitetaan väärään osoitteeseen, suoritin joutuu tekemään useita muistihakuja yhden sijaan, tai joissain arkkitehtuureissa ohjelma kaatuu välittömästi. Näiden määritteiden avulla C-ohjelmoija pakottaa kääntäjän kohdistamaan tietorakenteet tarkasti esimerkiksi 64 tavun rajoihin, mikä varmistaa, että rakenne istuu täydellisesti välimuistiriville.

typedef _Alignas(64) struct {
    uint64_t executionCounter;
    int32_t threadId;
    char padding[52];
} ThreadWorkerState;

Tässä _Alignas(64) pakottaa kääntäjän sijoittamaan tämän rakenteen aina muistiosoitteeseen, joka on jaollinen 64:llä. Rakenne on täytetty manuaalisesti padding-taulukolla niin, että sen kokonaiskooksi tulee täsmälleen 64 tavua.

Kolmas C-standardin tärkeä työkalu on _Static_assert, joka mahdollistaa loogisten väitteiden tarkistamisen kääntämisen aikana. Korkean tason kielissä ja vanhassa C-koodissa käytetyt ajonikaiset assert-kutsut pysäyttävät ohjelman vasta kun virheellinen koodipolku saavutetaan suorituksessa. _Static_assert estää ohjelman kääntymisen kokonaan, jos esimerkiksi jonkin tietorakenteen koko ei vastaa suorittimen välimuistirivin vaatimuksia tai jos bittimaskin koko on ristiriidassa kohdejärjestelmän kanssa.

Tämän eheyden varmistamiseksi asetetaan käännösaikainen tarkistus:

_Static_assert(sizeof(ThreadWorkerState) == 64, "ThreadWorkerState koon on oltava tasan 64 tavua välimuistirivin vuoksi!");

Jos joku myöhemmin lisää rakenteeseen uuden muuttujan muuttamatta täytetavuja, kääntäjä kieltäytyy kääntämästä ohjelmaa ja tulostaa annetun virheilmoituksen. Tämä takaa, ettei suorituskykyongelmia pääse livahtamaan tuotantoversioon.

Makrolaajennusten sivuvaikutukset

C-kielen esikääntäjä (preprocessor) ei ymmärrä C-kielen syntaksia tai tyyppejä; se tekee pelkkää tyhmää tekstikorvausta ennen varsinaista kääntämistä. Korkean tason koodaajalle, joka on tottunut turvallisiin inline-funktioihin, makrojen toiminta voi aiheuttaa vakavia virheitä. Jos makro määritellään huolimattomasti ilman sulkuja, matemaattiset operaatiojärjestykset rikkoutuvat laajennusvaiheessa. Lisäksi parametrin käyttäminen makron sisällä useasti voi monistaa siihen liittyvät sivuvaikutukset (kuten inkrementoinnin ++).

#define TRIPLE(x) (x + x + x)
int32_t mathResult = TRIPLE(2 * 3); // Laajenee: (2 * 3 + 2 * 3 + 2 * 3)

Tämä toimii oikein, mutta jos kutsutaan muodossa TRIPLE(i++), muuttujaa inkrementoidaan kolme kertaa yhden sijaan, mikä tuhoaa ohjelman loogisen tilan.

Lisäksi moniriviset makrot voivat rikkoa if-lauseiden logiikan ja paikallisten muuttujien käyttö makroissa voi aiheuttaa nimikonflikteja. Kannattaa siis käyttää malttia niiden kanssa.

Kääntäjän sisäiset funktiot

Kun korkean tason kielellä halutaan suorittaa matalan tason bittioperaatio, kuten bittien laskenta (population count), joudutaan usein kirjoittamaan silmukka tai luottamaan korkean tason kirjastofunktioihin. C-ohjelmoijat käyttävät kääntäjän sisäisiä funktioita (intrinsics). Nämä näyttävät tavallisilta C-funktioilta, mutta kääntäjä tunnistaa ne ja korvaa ne yhdellä tietyllä suorittimen konekielisellä käskyllä ilman funktiokutsun ylikuormaa tai pino-operaatioita.

int32_t activeBits = __builtin_popcount(0b1101);

Tämä GCC-kääntäjän (tuki myös Clangilla) tarjoama sisäinen funktio ei käynnistä aliohjelmaa, vaan se kääntyy x64-suorittimen laitteistotason POPCNT-käskyksi, joka suoriutuu yhdessä kellojaksossa.

Matalan tason niksit ja kikat

Matalan tason ohjelmoinnissa suorituskyky ja täydellinen kontrolli saavutetaan usein tekniikoilla, jotka korkean tason kielten kääntäjät tai ajonaikaiset ympäristöt kieltävät turvallisuussyistä. Yksi C-ohjelmoijan perustyökaluista on osoitinaritmetiikka (pointer arithmetic). Korkean tason kielissä taulukon alkioihin viitataan aina indeksien kautta, mikä pakottaa ajoympäristön laskemaan joka kerta osoitteen uudelleen kaavalla:

\text{Osoite} = \text{Alkuosoite} + \text{Indeksi} \cdot \text{Alkion koko}

C-kielessä osoitinta voidaan siirtää suoraan eteenpäin muistissa, jolloin koodi kuvaa eksplisiittisesti sitä, mitä laitteistolla tapahtuu: osoitin etenee lineaarisesti muistissa alkio kerrallaan. Moderni kääntäjä tuottaa indeksipohjaisesta ja osoitinaritmeettisesta silmukasta käytännössä identtistä konekieltä, joten suorituskykyero näiden välillä on olematon. Osoitinaritmetiikan arvo on muualla: se pakottaa ohjelmoijan ajattelemaan datan sijaintia muistissa, tekee lineaarisen läpikäynnin intention näkyväksi, ja estää kirjoittamasta vahingossa silmukoita, jotka hyppelevät epälineaarisesti muistissa.

void processDataBlocks(int32_t* dataArray, int32_t count) {
    int32_t* currentPointer = dataArray;
    int32_t* endPointer = dataArray + count;
    
    while (currentPointer < endPointer) {
        *currentPointer *= 2;
        currentPointer++;
    }
}

Tässä silmukassa ei käytetä lainkaan erillistä indeksimuuttujaa. Vertailu currentPointer < endPointer ja osoittimen siirto currentPointer++ kääntyvät suorittimen nopeiksi rekisterioperaatioiksi. Kääntäjän ei tarvitse arvailla muistialueen kokoa, koska rajat on määritelty osoittimilla.

Toinen tehokas kikka on tyyppimuunnos muistitasolla (type punning) unioneita hyödyntäen. C-standardi sallii virallisesti datan lukemisen unionin eri kenttien kautta, kunhan sitä käytetään tyypin uudelleentulkintaan. Tämä mahdollistaa esimerkiksi sen, että liukuluvun (float) bittikuvio voidaan lukea sellaisenaan kokonaislukuna (unsigned int) ilman, että dataa muutetaan matemaattisesti tai kopioidaan uuteen muistipaikkaan. Tätä käytetään paljon pelinkehityksen matemaattisissa optimoinneissa, kuten nopeissa likimääräisissä neliöjuurilaskuissa.

Bittitason manipulointi (bitwise operations) on C-ohjelmoijan arkipäivää. Sen sijaan, että käytettäisiin erillisiä totuusarvomuuttujia (boolean), jotka vievät kukin vähintään yhden tavun (8 bittiä) muistia, tilatiedot pakataan yksittäisiksi biteiksi laitteistorekisterien tavoin. Bittisiirrot (<<, >>) ja loogiset bittioperaatiot (&, |, ^, ~) suoritetaan prosessorin rekistereissä yhdessä kellojaksossa, mikä tekee niistä moninkertaisesti nopeampia kuin korkean tason kielten ehdolliset lausekkeet.

Katsotaanpa miten näitä työkaluja voidaan käyttää koodissa.

typedef union {
    float floatValue;
    uint32_t intValue;
} FloatBits;

Tämä unioni varaa muistista 4 tavua, koska molemmat kentät jakavat saman fyysisen muistipaikan.

Tätä hyödynnetään tekemällä NaN-tarkistus:

int32_t isNaN(float number) {
    FloatBits bits;
    bits.floatValue = number;
    return (bits.intValue & 0x7FFFFFFF) > 0x7F800000;
}

IEEE 754 -standardissa 32-bittinen liukuluku jakautuu kolmeen kenttään: ylin bitti on etumerkki, seuraavat 8 bittiä ovat eksponentti ja loput 23 bittiä ovat mantissa. NaN syntyy kun eksponenttikentän kaikki 8 bittiä ovat ykkösiä (maski 0x7F800000) ja mantissa ei ole nolla. Maskaamalla etumerkki pois & 0x7FFFFFFF ja vertaamalla tulosta 0x7F800000:aan saadaan tarkistus joka toimii sekä positiiviselle että negatiiviselle NaN:lle yhdellä kokonaislukuvertailulla.

number != number tunnistaa NaN:n myös, mutta se on sopimus: luotat siihen että kääntäjä ja FPU noudattavat IEEE 754 -semantiikkaa eikä optimoi vertailua pois. Aggressiivisella -ffast-math-lipulla kääntäjä saa olettaa, että liukulukuarvot eivät koskaan ole NaN tai inf, jolloin se voi poistaa number != number -tarkistuksen kokonaan koska se pitää sitä aina epätotena. Bittitason versio ei riipu liukulukusemantiikasta lainkaan, koska se käsittelee arvoa pelkkänä uint32_t:na, johon -ffast-math ei koske.

Tilakone ja bittimaskit

#define FLAG_ALIVE     (1 << 0)
#define FLAG_GROUNDED  (1 << 1)
#define FLAG_CROUCHING (1 << 2)
#define FLAG_ATTACKING (1 << 3)

Jokainen tila määritellään omana bittipaikkanaan. Seuraavaksi luodaan funktio, joka muuttaa tilaa tehokkaasti:

void updateCharacterState(unsigned char* currentFlags) {
    // Asetetaan hahmo maahan ja poistetaan hyökkäystila yhdellä kertaa
    *currentFlags = (*currentFlags | FLAG_GROUNDED) & ~FLAG_ATTACKING;
}

Tämä koodi käyttää bittitason OR-operaatiota (|) asettamaan FLAG_GROUNDED-bitin arvoon 1.

    0 0 0 0  1 0 0 1  (Alkuperäinen tila)
OR  0 0 0 0  0 0 1 0  (FLAG_GROUNDED maski: 2. bitti on 1)
--------------------
=   0 0 0 0  1 0 1 1  (Nyt hahmo on myös maassa)

Samalla bittitason NOT (~) ja AND (&) nollaavat FLAG_ATTACKING-bitin täysin riippumatta sen aiemmasta arvosta, jolloin arvoksi tulee 00000011. Koko operaatio tapahtuu suorittimessa minimaalisella määrällä käskyjä, ilman ehdollista hyppykäskyä (if), mikä estää suorittimen haaroituksenennustuksen (branch predictor) pettämisen ja pitää suorituskyvyn tasaisena.

Muistin aliasing ja restrict

Kuvittele peliympäristö, jossa käsitellään äänidataa yhdessä suuressa, ympyrän muotoisessa muistipuskurissa (Ring Buffer).

Sinulla on yksi iso taulukko, jossa src osoittaa puskurin kohtaan, josta luetaan uutta dataa sisään ja dst osoittaa kohtaan, johon purettua dataa kirjoitetaan. Koska kyseessä on sama taulukko, nämä kaksi osoitinta (src ja dst) liikkuvat koko ajan eteenpäin pelin pyöriessä. Jos peli kohtaa lagipiikin, kirjoitusosoitin (dst) voi saavuttaa lukuosoittimen (src) ja ne päätyvät hetkellisesti päällekkäin. Kääntäjän on pakko varautua tähän, koska se näkee funktiossa vain kaksi int32_t*-osoitinta, eikä se tiedä, että ne osoittavat saman taulukon sisälle. Sen on oletettava, että ne saattavat osoittaa samaan muistipaikkaan tai limittäisille alueille (pointer aliasing). Tämän vuoksi kääntäjä ei voi pitää arvoja rekistereissä, vaan sen on kirjoitettava jokainen muutos takaisin päämuistiin siltä varalta, että toinen osoitin lukee saman paikan.

void UpdateAudio(int32_t* src, int32_t* dst, int len) {
    for (int i = 0; i < len; i++) {
        dst[i] = src[i] * 2; // Pakotettu hidas muistiluku joka kierroksella
    }
}

void UpdateAudio(int32_t* restrict src, int32_t* restrict dst, int len) {
    for (int i = 0; i < len; i++) {
        dst[i] = src[i] * 2;
    }
}

Tietenkin jos tiedät, että muistialueet voivat pelissä mennä päällekkäin (esim. juuri lagipiikin takia ring bufferissa), sinulla on kaksi vaihtoehtoa. Voit antaa koodin olla hidas, jolloin kääntäjä tekee varovaisen koodin, joka lukee ja kirjoittaa muistiin uskollisesti askel kerrallaan. Peli toimii oikein, mutta hitaammin. Jos sinun on pakko kopioida tai muokata dataa päällekkäisten alueiden välillä, et voi käyttää tavallista silmukkaa. C-standardikirjaston memmove on suunniteltu juuri tätä varten. Se osaa sisäisesti tarkistaa, mihin suuntaan päällekkäisyys on, ja kopioi datan turvallisesti (esimerkiksi lopusta alkuun), jotta data ei korruptoidu.

volatile-avainsanan todellinen merkitys

Monet korkean tason koodaajat (erityisesti C#- ja Java-taustaiset) ajattelevat, että myös C-kielessä volatile-avainsana liittyy säikeiden väliseen synkronointiin, mutta sillä on eri merkitys. Se on tiukka käsky kääntäjälle: ”Älä optimoi tätä muuttujaa rekistereihin tai poista sen lukemisia, koska sen arvo voi muuttua koodin ulkopuolisen tekijän toimesta.” C-ohjelmoija käyttää sitä käsitellessään muistikartoitettuja I/O-laitteita (memory-mapped I/O) tai keskeytyskäsittelijöiden (interrupt handler) jakamia globaaleja tilamuuttujia.

volatile int32_t hardwareStatusRegister;
void waitForHardware(void) {
    while (hardwareStatusRegister == 0); // Kääntäjä ei saa optimoida tätä pois
}

Ilman volatile-määrettä kääntäjä huomaisi, ettei silmukan sisällä muuteta muuttujan arvoa, ja muuttaisi koodin ikuiseksi silmukaksi, joka lukee arvon kerran rekisteriin. volatile pakottaa kääntäjän generoimaan muistihaun joka iteraatiolla, jolloin laitteiston kirjoittama arvo näkyy ohjelmalle.

C#:n ja Javan volatile liittyy säikeiden väliseen synkronointiin. C:ssä se ei aseta muistiesteitä (memory barriers) eikä takaa atomisia luku- tai kirjoitusoperaatioita. Jos kaksi säiettä jakaa muuttujan, volatile yksin ei riitä: toinen säie voi lukea osittain kirjoitetun arvon, ja kääntäjä tai suoritin voi silti järjestää muistioperaatioita uudelleen volatile-muuttujan ympärillä. Monisäikeiseen synkronointiin käytetään C:n _Atomic-tyyppiä tai stdatomic.h-kirjaston operaatioita, jotka takaavat sekä atomisuden että muistiesteet. volatile kuuluu sulautettuihin järjestelmiin ja ajurikoodiin, ei sovellustason monisäikeisyyteen.

Muistikartoitetut tiedostot

Suurten tiedostojen käsittely korkean tason kielissä perustuu puskuroituihin virtoihin (Streams), joissa dataa luetaan palasina muistiin. C-ohjelmoija jättää nämä välikerrokset väliin ja kartoittaa tiedoston osaksi prosessin virtuaalista osoiteavaruutta (mmap POSIX-järjestelmissä tai CreateFileMapping Windowsissa). Tämän jälkeen koko kiintolevyllä oleva tiedosto näyttää ohjelmalle yhdeltä valtavalta tavutaulukolta, ja sen lukeminen sekä kirjoittaminen tapahtuu muistiosoitteiden kautta, jolloin käyttöjärjestelmän sivutusjärjestelmä hoitaa datan siirron taustalla välimuistiin.

#include <sys/mman.h>
void* mapLargeFile(int32_t fileDescriptor, size_t fileSize) {
    return mmap(NULL, fileSize, PROT_READ, MAP_SHARED, fileDescriptor, 0);
}

Tämä funktio palauttaa void*-osoittimen tiedoston sisältöön. Tiedoston selaaminen muuttuu osoitinaritmetiikaksi ilman yhtäkään read- tai seek-kutsua.

Haaroituksenennustuksen ohjaaminen

Nykyaikaiset suorittimet yrittävät arvata etukäteen, mihin suuntaan if-lauseen ehto hyppää, jotta ne voivat ladata seuraavat käskyt valmiiksi suoritusputkeen (pipeline). Jos arvaus menee väärin (branch misprediction), suoritusputki joudutaan tyhjentämään, mikä maksaa kymmeniä suoritinsykliä. C-ohjelmoija voi ohjata kääntäjää ja suorittimen haaroituksenennustusta käyttämällä kääntäjäkohtaisia määritteitä (__builtin_expect), joilla kerrotaan, onko jokin ehto tilastollisesti lähes aina totta vai tarua.

#define likely(x)   __builtin_expect(!!(x), 1)
#define unlikely(x) __builtin_expect(!!(x), 0)

void processNetworkData(int32_t isCorrupted) {
    if (unlikely(isCorrupted)) return; // Kääntäjä optimoi tämän epätodennäköiseksi
}

Kääntäjä järjestää konekieliset hyppykäskyt niin, että normaali, virheetön suorituspolku etenee lineaarisesti ilman hyppyjä, mikä pitää suoritusputken täynnä ja maksimoi koodin läpimenonopeuden.

Käytännössä __builtin_expect on perusteltua ainoastaan sisäsilmukassa jossa profilointi on osoittanut branch mispredictionin olevan pullonkaula, ja PGO (Profile Guided Optimization) ei ole käytettävissä. Modernit suorittimet oppivat haaroitusmallit itse erittäin tehokkaasti. Branch predictor kerää tilastoa suorituksen aikana ja oppii nopeasti mitkä haarat ovat todennäköisiä.

Bittikentät rakenteissa

Korkean tason kielissä pienin itsenäinen tietoyksikkö on aina vähintään yhden tavun (8 bittiä) kokoinen byte tai bool. Jos ohjelmassa tarvitaan paljon pieniä lukuarvoja (kuten lukuja väliltä 0-7), ne vievät silti kokonaisen tavun tai kokonaisluvun verran tilaa. C-kieli tarjoaa tähän bittikentät (bit-fields), joiden avulla struct-rakenteen sisällä voidaan määrittää muuttujan kooksi tarkka määrä bittejä. Tämä mahdollistaa useiden pienten muuttujien pakkaamisen laitteistotason tiiviyteen kielen syntaksilla.

typedef struct {
    uint8_t systemStatus : 3; // Vie tasan 3 bittiä (arvot 0-7)
    uint8_t isReady      : 1; // Vie tasan 1 bitin (arvot 0-1)
    uint8_t errorType    : 4; // Vie tasan 4 bittiä (arvot 0-15)
} HardwareBitfield;

Koko tämä rakenne pakataan muistissa yhteen tavuun (8 bittiä). Kääntäjä generoi taustalla tarvittavat bittimaskit ja siirrot, mutta koodaaja voi käyttää muuttujia aivan kuten tavallisia lukuja.

Tiedon kääntyvyys muistissa

Korkean tason koodarin ei tarvitse koskaan välittää siitä, miten monen tavun kokoiset luvut tallennetaan fyysisiin muistiosoitteisiin. C-ohjelmoijan on ymmärrettävä tiedon kääntyvyys (endianness). x64-arkkitehtuuri on Little-Endian, mikä tarkoittaa, että monen tavun kokoisen luvun (kuten 32-bittisen int-luvun) vähiten merkitsevä tavu tallennetaan muistissa ensimmäiseksi (alimpaan osoitteeseen). Monet verkkoprotokollat ja vanhat tiedostoformaatit taas käyttävät Big-Endian-järjestelmää (eniten merkitsevä tavu ensin). Kun dataa luetaan verkosta raakana tavujonona, tavujen järjestys on käännettävä manuaalisesti ennen sen tulkitsemista luvuiksi.

uint32_t swapEndianness(uint32_t value) {
    return ((value >> 24) & 0xff) | ((value << 8) & 0xff0000) |
           ((value >> 8) & 0xff00) | ((value << 24) & 0xff000000);
}

Tämä funktio ottaa 32-bittisen luvun ja kääntää sen tavujärjestyksen täysin ympäri käyttämällä bittisiirtoja ja bittimaskeja, mikä muuttaa Little-Endian-luvun Big-Endian-muotoon tai päinvastoin.