Tossa on varmaan monta eri tasoa. Mä itse en esim. pidä softan käynnistymisnopeutta yleensä kovin oleellisena asiana. Keskimäärin käynnistän softa kerran per päivä. Esim. itse käytän VSCode -editoria, joka käynnistyy sen 2 sekuntia. Nopeampi ei vaikuttaisi mihinkään, sillä editori onkin sitten tuntikausia sen jälkeen auki. Nopea käynnistys on nice to have, mutta nopea käyttö on oleellisempaa.
Softan käynnistysaikahan kytkeytyy paljon siihen, mitä käynnistyksen yhteydessä tehdään. Näistä toiminnoista voisi laatia työkalulla bootchart-tyylisen kuvaajan ja selvittää, mikä ketju operaatioita jumittaa ja johtaa siitä sitten optimointisuunnitelma. Kaikki suoritus ohjelman alussahan ei kontribuoi tähän jumiin. Yksinkertaisin optimointi olisi siirtää taustalle/myöhempään ajankohtaan sellaista, millä ei ole niin kiire. Graafisissa ohjelmissa voi mennä paljon aikaa sellaiseenkin turhaan, että populoidaan kaikki piilossakin olevat ikkunat jo heti alkuun (ainakin perinteisissä ohjelmissa), vaikka niitä ei avattaisi. Generointi lennossa ei välttämättä aiheuttaisi isoakaan hidastusta.
Kyllä yliopistoissa tietojenkäsittelytieteessä ja tietotekniikassa käydään läpi paljon muutakin kuin taukukot ja loopit. Siellä varmasti opetetaan eri algoritmien kompleksisuutta ja käydään läpi teoriatasolla, millaisia ominaisuuksia eri tietorakenteilla on. Eiköhän jokainen valmistunut osaa vaikkapa lisätä uuden alkion punamustaan puuhun.
Toki tuosta on pitkä matka käytäntöön. Eli teoria on hallussa, mutta softankehityksessä pitää tietää, mikä on todellinen pullonkaula ja mitä kannattaa edes yrittää optimoida. Nykyään ohjelmointikielien standardikirjastot ovat todella optimoituja, eikä lopulta monessa tilanteessa kannata edes yrittää toteuttaa samoja asioita itse jos joku ne on jo toteuttanut. Tällöin ongelma on, ettei tunneta kirjastojen metodien ominaisuuksia ja järkevää käyttötapaa. Mutta tää riippuu niin tapauksesta. Ja tuota ei kyllä koulussa voi kauheasti opettaa.
Kouluissa opetetaan tosiaan tietorakenteiden ja algoritmien kompleksisuusanalyysin perusteita, mutta tätä on diplomi-insinöörin/maisterin tutkinnossakin aika pieni osa. Katsoin että esim. Turun yliopistossa kontaktiopetusta aiheesta on
36 tuntia. Lisäksi harjoitukset kotiläksynä. Tuossa opitaan perusasiat, mutta esim. nykyisissä ohjelmointikielissä on perustietorakenteita, joiden yksityiskohtia ei käsitellä. Otetaan esimerkiksi Javan ArrayList ja HashMap. Nuo ovat jatkokehityksiä klassisista rakenteista. Dataorientoitunut ohjelmointi, alignmentin, boxed-tyyppien jne. vaikutus suorituskykyyn jää melko luultavasti eliittiyliopistoissakin monelle epäselväksi. Algoritmeissa niinkin perusjutut kuin lajittelu pohjautuvat klassisten algoritmien jatkokehitelmiin. Esim. Javassa oletuslajittelu on
dual-pivot quick sort, joka vaihtaa pienillä kokoelmilla lisäyslajitteluun. Aika harvassa koulussa edes ohimennen mainitaan, että pivot-alkioita voi olla quicksortissa kaksi. Tai median-of-X killereistä.
Oikeastaan edellisiä paljon kriittisempi puute opetusohjelmissa on debuggauksen ja profiloinnin vähäinen opetus ja treenaus. Siitä on aika vähän apua, jos osaa ulkoa jonkun perusalgoritmin kompleksisuuden tai laskea sen ruutupaperilla, jos ei ole mitään systemaattista kykyä selvittää ohjelmasta pullonkauloja ja analysoida, mikä niissä jumittaa. Tätä monimutkaistaa vielä se, että joskus ongelmat johtuvat säikeiden huonosta käytöksestä. Perusalgoritmikursseilla ei puhuta säikeistä ja säikeiden tehokas käyttö yhdessä muistin tehokkaan käytön kanssa jää epäselväksi kun kurssien materiaali on vanhaa ja pohjautuu johonkin arkkitehtuureihin ennen Pentiumia. Jos on säieohjelmointia, siellä on jotain Javan raskaita perussäikeitä ja perus notify/wait/async/await-käytäntöjä eikä mitään algoritmiikan patterneja kuten thread pooleja. Pohja on todella heikko. Sitten vielä muotikielissä JS ja Python on suoritus usein aika yksisäikeistä. Pythonista julkaistiin vasta viikon sisään eka yritelmä, jossa on GIL ja säikeistys tarjottu aikuiskäyttäjille.
Mä olen koko ketjun alkuperäisestä väitteestä täysin eri mieltä. Musta osa nykysoftista on todella nopeita, osa "ihan ok" ja osa hitaita. Kuten on aina ennenkin ollut. Keskimäärin kuitenkin kaikki on nopeampaa kuin 20v sitten. Jonnet ei muista kun pelit ladattiin kasetilta. Siinäpä sitä nopeutta ohjelman käynnistymisessä: kesti minuutteja tai jopa yli 10 minuuttia ladata peli.
Tässäkin samaan aikaan on monenlaista kehitystä. Muistan että joitain vuosia sitten uudetkin pelit käynnistyivät nopeasti, mutta nyt esim. Steamissa jos käynnistää jotain vähänkään uudempaa peliä, ihan aluksi saa odotella shaderien kääntämistä ainakin Linux-versiossa. En tiedä miksei se cacheta niitä jonnekin. Omalla 8th gen i7:lla ja samaan aikakauden Geforcella pelien käynnistys kestää mm. tästä syystä puolisen minuuttiakin pidempään, vaikka olisi kyseessä aika simppeli peli. Tällainen odotus on tavallaan uutta.
Mitä levyn käyttöön tulee, koneissa on tehty kolme aika valtavaa hyppyä levyn suorituskyvyn osalta. SATA/SCSI-pohjaisissa levyissä tuli pyöriviin levyihin NCQ-tyylisiä optimointeja, jotka paransivat suorituskykyä ja levyissä myös yleistyi sisäiset cachet verrattuna ensimmäisen sukupolven PC-kiintolevyihin (toki myös kymmenien gigatavujen keskusmuisti cachena tekee paljon). SATA-pohjaisiin SSD-levyihin siirtyminen myös moninkertaisti IOPS-luvut ja levyt alkoivat saturoida 600 MB/s SATA-väylän. Voi sanoa, että kaista noin 10-kertaistui. Nykyisin NVMe-pohjaisissa levyissä ollaan yli 12 000 MB/s nopeuksissa. Taas yksi 20-kertaistuminen. IOPSien kasvu on myös ollut aika hurjaa ja sillä on tilanteesta riippuen isompi vaikutus. Tähän päälle on tullut läpinäkyvä levypakkaus tuplaamaan kaistaa tietyissä tilanteissa. Esim. Linuxit ja vastaavat luetaan pakattuna levyltä. Tälläkin on luku+purku yhteenlaskettuna nopeuden moninkertaistava vaikutus.
Nykyaikainen NVMe SSD on ihan lukuina ilmaistuna luokkaa 100 000 kertaa nopeampi kuin 1,44" korppu. Korppukin oli kasetteihin verrattuna nopea. C-64:llahan kasetteihin oli peräkkäin tallennettu kahteen kertaan ohjelma eli valmista tuli jo puolivälissä, mutta luettiin vielä toistamiseen varmuuden vuoksi. Täysin älyvapaa design nopeuden kannalta. C-64:n kasetti onkin luokkaa puoli miljardia kertaa hitaampi kuin uuden PC:n SSD.