(Nyky)softien hitaus

[mikalep]

Musta tämä väite on niin epämääräinen ja absurdi, että voisitko tarkentaa, että mikä "kaikki hidastuu jatkuvasti". Puhutko sä webbisivuista, joita pyöritetään selaimella ja netin yli, puhutko sovelluksista, jotka hakevat netistä tavaraa, puhutko sovelluksista jota eivät hae netin yli mitään, puhutko graafisista vai komentorivityökaluista, vertaatko sä edes omenoita keskenään, vai vertaatko softaa joka teki 10% siitä mitä nykysofta, jolloin niiden nopeutta ei voi suoraan edes verrata?

Mulla taas kone käynnistyy nopeammin kuin 20v sitten, herää lepotilasta nopeammin kuin 20v sitten, vim avautuu nopeammin kuin 20v sitten, nettisivut avautuvat nopeammin kuin 20v sitten, pelit pyörivät paremmin kuin 20v sitten ja piirtävät monta kertaa enemmän kolmioita ruudulle sekunnissa ja näyttävät paremmilta, 3d-softa rendaa monta kertaluokkaa enemmän valonsäteitä sekunnissa kuin 20v sitten, kone lataa paljon isommat skenet nopeammin kuin 20v sitten, kuvankäsittelyn filtterit ovat paljon nopeampi moninkertaisesti isompiin kuviin kuin 20v sitten. Esimerkkejä on vaikka kuinka. Kaikki ei ole hidastunut, vaikka joku asia onkin hidastunut. Ja sillekin on varmaan syy.

Kuten miljoona kertaa todettu: jos tehoa on tarjolla, se kyllä käytetään.

Juu, webistä lähinnä puhuin.

 

[Paapaa]

Juu, webistä lähinnä puhuin.

No se on taas sitten aivan oma asiansa ja siinä on omat syynsä. JS:n pyörittäminen selaimessa on nopeutunut aivan valtavasti 20 vuodessa ilman rautamuutoksiakin - ja raudan merkittävä nopeutuminen päälle. Paskakin koodi on siis paljon nopeampaa. V8 on paljon älykkäämpi kuin miten jäsää ajettiin 20v sitten. Nettiliittymät ovat myös keskimäärin paljon nopeampia. Itsellänikin 600M valokuitu kun 20v sitten oli joku hikinen parimegainen max ja paljon nykyistä hitaammilla latensseilla koska ADSL jää valokuidun jalkoihin.

Se, mikä tekee vertailusta hankalan on se, että webbipalvelut ovat muuttuneet myös valtavasti. 20v sitten Facebookista ei suurin osa ollut kuullutkaan, webbisivujen interaktiivisuus ja siirretyn datan määrä oli paljon pienempi kuin nykyään. Staattisia sivuja oli paljon enemmän, niiden ylläpito ja sisällöntuotanto oli tehty eri tavalla kuin nyt. Nykyään tyypillinen webbipalvelu saattaa keskustella kymmenien eri rajapintojen kanssa kun dataa aggregoidaan monesta paikasta asiakkaalle näytettäväksi, ja joissa kaikissa on omat viiveensä ja ominaisuutensa. 20v vanhan staattisen sivun vertaaminen johonkin nykyiseen interaktiiviseen palveluun on appelsiinien ja omenoiden vertailua.

Pilvipalvelut ovat yleistyneet. Ne sivut saattavat sijaita jossain eurooppalaisessa konesalissa, eikä samassa kaupungissa missä itse sivuja latailee. Jos välissä ei ole jotain CDN:ää (esim. Cludflare/Cloudfront), niin taas saadaan kymmeniä tai jopa satoja millisekunteja lisää viiveitä. Ja koska se datan luonne on muuttunut, ei kaikkea voida edes hakea CDN:stä, vaan pakko kilauttaa tietokannalle, joka onkin nyt siis Keski-Euroopassa.

Sitten on tietenkin muita hidastavia asioita, kuten juuri laiskuus välittää esim. bundlen tai siirrettävän datan koosta tai niiden lukuisten integraatioiden hitaudesta, ei tehdä kunnon kakutusta (assettien TTL, Redis, CDN:t jne.) vaikka se olisi mahdollista, alimitoitetaan palvelimien resursseja, ei tehdä järkevää skaalausta jne. Webbipuolella harvemmin on kyse mistään algoritmiongelmasta, vaan enemmän arkkitehtuurista. Ei tunnisteta oikein pullonkauloja. Tähän kaikkeen voi olla lukuisia syitä sieltä osaamattomuudesta resurssipulaan (=raha/aika).

Kokeile jotain staattista sivua joka tarjoillaan CDN:stä tai vaikka omasta sisäverkosta tai selaimen kakusta, niin kyllä se on hyvin nopea. Paljon nopeampi kuin 20v sitten.

 

[Paapaa]

Nettisivuista puheen ollen, miksi evästehyväksynnät on usein tehty sellaisella sisään ja ulos feidaavalla animaatiolla jossa on hätäiselle käyttäjälle raivostuttavat viiveet? Vai onko viive todellisuudessa monimutkaisen seurannan latautumisaikaa? Pahimmillaan tämä toimii niin, että menet uudelle sivulle jossa ehdit jo selata valikkoa tai klikata jotain, jonka jälkeen evästehyväksyntä ilmestyy eteen ja keskeyttää toiminnan.

Ei kai tuossa kyse ole muusta kuin turhasta visuaalisesta efektistä. Olen myös hätäinen ja tarpeettoman hitaiksi venytetyt animaatiot kyllä ärsyttävät. Niille harvoin voi itse tehdä yhtään mitään. Sinänsä latausindikaattori on ihan järkevä asia, mutta tuo ei sellaiselta kuulosta.

Nimim. MacBook Pron eri desktopien välillä vaihtamisen hitaus varsinkin jos ProMotion päällä

 

[love_doctor]

Musta tämä väite on niin epämääräinen ja absurdi, että voisitko tarkentaa, että mikä "kaikki hidastuu jatkuvasti". Puhutko sä webbisivuista, joita pyöritetään selaimella ja netin yli, puhutko sovelluksista, jotka hakevat netistä tavaraa, puhutko sovelluksista jota eivät hae netin yli mitään, puhutko graafisista vai komentorivityökaluista, vertaatko sä edes omenoita keskenään, vai vertaatko softaa joka teki 10% siitä mitä nykysofta, jolloin niiden nopeutta ei voi suoraan edes verrata?

Mulla taas kone käynnistyy nopeammin kuin 20v sitten, herää lepotilasta nopeammin kuin 20v sitten, vim avautuu nopeammin kuin 20v sitten, nettisivut avautuvat nopeammin kuin 20v sitten, pelit pyörivät paremmin kuin 20v sitten ja piirtävät monta kertaa enemmän kolmioita ruudulle sekunnissa ja näyttävät paremmilta, 3d-softa rendaa monta kertaluokkaa enemmän valonsäteitä sekunnissa kuin 20v sitten, kone lataa paljon isommat skenet nopeammin kuin 20v sitten, kuvankäsittelyn filtterit ovat paljon nopeampi moninkertaisesti isompiin kuviin kuin 20v sitten. Esimerkkejä on vaikka kuinka. Kaikki ei ole hidastunut, vaikka joku asia onkin hidastunut. Ja sillekin on varmaan syy.

Kuten miljoona kertaa todettu: jos tehoa on tarjolla, se kyllä käytetään.

Jos katsotaan 20 vuoden sijaan vaikka 12 vuotta taaksepäin, ostin 3770k-koneen silloin. Tuon koneen UEFI buuttasi tyyliin 5 sekunnissa, koska siinä Linux aukesi HTPC-käytössä työpöydälle noin 9 sekunnissa 64 gigan halpis-SSD:llä. Minulla oli tuo kone HTPC:nä useamman vuoden sen jälkeen kun vaihdoin Ryzeneihin. Nyt jos katson 5950X Ryzenin vastaavia lukuja esim. systemd:n analysaattorilla, siellä lukee 'Startup finished in 15.206s (firmware)'. Eli pelkkä UEFI vei nyt 15 sekuntia. Tuohon päälle vielä 4-5 sekuntia kerneliä ja userspacea. Käynnistysaika ainakin minulla siis tuplaantunut enkä keksi mitään keinoa nopeuttaa sitä.

Pöytäkoneissa nuo suspend-tilat eivät ole sanottavasti nopeampia. Isoin nopeutus lepotilasta heräämiseen tuli siinä kun vaihdettiin pois kuvaputkista, koska littunäyttöön tulee nopeammin kuva kuin mitä ainakin minulla kuvaputki lämpeni täyteen kirkkauteensa. Läppäreissä suspend on tietysti nopeampi, mutta esim. omassa HP:n Probookissa haittana on sitten ettei S3-tilaa enää ole tuettu ja kone kuluttaa akun tyhjäksi noin 1,5 päivässä kansi kiinni. Tiedän että Apple tekee nämä paremmin, mutta tämä on todellisuutta monelle. "Modern sleep" toi tämän hienouden, että valmistajat estävät S3 Sleepin kokonaan. En usko että tämä sekunnin tai kahden säästö lepotilasta heräämisessä ikinä maksaa minulle takaisin sitä mikä kuluu sähkölaskussa tai akun nopeammassa uusimistahdissa tai siinä, että konetta saa ladata jatkuvasti ja akku on (lähes) loppu kriittisellä hetkellä. Modernisti nukkuva läppäri myös lämpenee laukussa jonkin verran ja koen tulipaloriskiksi.

Nettisivuissa avautumisnopeus on aika lailla linjassa koneen ja nettiliittymän nopeuden kanssa. 20 vuotta sitten oli aika paljon jakautumista siinä, että oli ns. kevyesti tehtyjä nettisivuja nörteille ja sitten massoille hirveän bloattia paskaa. Tässä on ehkä päästy nyt siihen, että kaikki js-puolen kehitys frameworkeineen ja bundlereineen poistaa paljon sitä hitautta siitä bloatista, mutta jos katsoo jostain logista, paljonko megatavuja verkossa liikkuu, määrät ovat aika poskettomia varsinkin ekalla latauksella. Toisaalta nettinopeudet ovat kasvaneet niin paljon, että vaikka kokonaisajat ovat nopeutuneet, selvästi jotain optimointeja on jäänyt hyödyntämättä, kun nopeutuminen ei ole ihan suhteessa siihen mitä rauta ja yhteydet ovat nopeutuneet. Esim. liittymissä minulla on pingit pudonneet jopa kymmeniä kertoja. HTTP/2, bundlerit ja vastaavat myös poistavat round-trippejä tuosta kommunikaatiosta. JS on nykyään JIT-optimoitu. Softapinollakin voi olla tässä siis kymmeniä tai jopa satoja kertoja nopeuttava vaikutus. Prosessoritehon osalta en uskalla edes lähteä arvaamaan, paljonko nopeampi joku nykyaikainen 4Ghz 8-core on verrattuna 20 vuotta vanhaan Pentium 4:ään. CPU benchmark -sivu arvioi että ero olisi noin 120-kertainen 16-vuotiaaseen koneeseen verrattuna. Toisaalta grafiikan selaimessa renderöi nykyään GPU. Näitä vasten kun miettii, että sivun latausaika on esim. tippunut muutamasta sekunnista muutamaan sataan millisekuntiin, parannus ei ole mitenkään suhteessa siihen mitä taustalla on optimoitu nopeammaksi. Autoanalogiana, ihmettelisin kovasti jos vaihtaisin polkupyörän formula-autoon ja pääsisin 20 km/h sijaan vain 40 km/h. Kuitenkin satojen hevosvoimien kisamoottorista pitäisi irrota paljon enemmän kuin omista insinöörin tikkujaloista.

Parhaiten nuo optimoinnit ja tehot on saatu käyttöön juuri ammattiohjelmissa ja peleissä ja se on oikein hyvä. Peruskäyttöliittymissä minusta on käynyt jopa niin, että nykyiset mobiilioptimoidut näkymät ovat jopa todella primitiivisiä verrattuna vanhoihin. Se voi olla hyväkin asia UX-mielessä. Mutta jos miettii tehokkuutta, kyllä kaiken järjen mukaan pitäisikin toimia nopeammin jos on vähemmän sisältöä. Mikä sitten on todellisuus, minusta peruskäyttöliittymiin on tullut eniten bloattia. Tässä pitää muistaa, että näitä perusohjelmien ikkunoita ja kliksutteluita näki jo 80-luvulla. Minulla oli ekassa PC:ssä 512 kB RAMia ja GEM Desktop. Siinä toimi grafiikka 640x200 -moodissa ja käyttö oli ihan sulavaa. Koneessa yksi hidas ydin ja 8 megahertsiä. Ohjelmat 16-bittisiä. Nyt minulla on dedikoitu GPU grafiikalle ja prosessorissa 32-kertaa leveämpiä käskyjä, 16 kertaa vanha ydinmäärä, käskyjen suoritusajat kymmeniä kertoja nopeammat sykleissä ja prosessorikin luokkaa 500 kertaa nopeampi kellotaajuudeltaan. Niin vanhassa ei ollut cachejakaan. Framerate ei ole sanottavasti nopeampi. Se voi olla tuplat tai 4x se mitä silloin lähes 40 vuotta sitten.

 

[Karhu III]

Minulla oli ekassa PC:ssä 512 kB RAMia ja GEM Desktop. Siinä toimi grafiikka 640x200 -moodissa ja käyttö oli ihan sulavaa. Koneessa yksi hidas ydin ja 8 megahertsiä. Ohjelmat 16-bittisiä. Nyt minulla on dedikoitu GPU grafiikalle ja prosessorissa 32-kertaa leveämpiä käskyjä, 16 kertaa vanha ydinmäärä, käskyjen suoritusajat kymmeniä kertoja nopeammat sykleissä ja prosessorikin luokkaa 500 kertaa nopeampi kellotaajuudeltaan. Niin vanhassa ei ollut cachejakaan. Framerate ei ole sanottavasti nopeampi. Se voi olla tuplat tai 4x se mitä silloin lähes 40 vuotta sitten.

Datan määrä on kasvanut ja monimutkaistunut. 640x200x16 pärjää pienellä 64kB framebufferilla ja grafiikka oli yksinkertaista bittikarttagrafiikkaa. Piirtokomennotkin olivat yhtälailla yksinkertaisia. Hitain oli ympyrän piirtäminen joka ei tietenkään ollut ympyrä vaan soikio.

Nykyään grafiikkatilat ovat olleet jo pitkään 32-bittisiä, fontit antialiasoituja, ympyrä on helppo piirtää niin että se näyttää ympyrältä eikä siinä ole sahalaitaa, grafiikat voidaan skaalata helposti eri kokoisiksi ym. Paljon on poistunut alkuaikojen rajoitteita joita piti vain kestää. Pelkästään JPEG-kuvan dekoodaaminen veisi 286-tason prosessorilla kymmeniä minuutteja.

 

[JCSH]

Pelkästään JPEG-kuvan dekoodaaminen veisi 286-tason prosessorilla kymmeniä minuutteja.

Minkä kokoinen JPEG-kuva? Meinaan JPEG standardihan on ikivanha. Ei nyt ihan niin ikivanha kuin 286, mutta melkein.

 

[Karhu III]

Minkä kokoinen JPEG-kuva? Meinaan JPEG standardihan on ikivanha. Ei nyt ihan niin ikivanha kuin 286, mutta melkein.

Olisikohan joku 640x480. Aikoinaan Amiga 1200:lla kokeilin miten se avaa JPEG-kuvia ja siinä kesti minuutteja. JPEG vaatii tehokasta liukulukulaskentaa että toimii jouhevasti.

 

[JCSH]

Olisikohan joku 640x480. Aikoinaan Amiga 1200:lla kokeilin miten se avaa JPEG-kuvia ja siinä kesti minuutteja. JPEG vaatii tehokasta liukulukulaskentaa että toimii jouhevasti.

Mihin tuo väite perustuu? En nyt tähän hätään muista miten juurikin JPEG toimi noilta osin (about 20 vuotta aikaa kyseisistä TTY:n kursseista), mutta aikalailla kaikissa koodekeissa on aina pyritty fixed point toteutuksiin ja flotareja käytetään ehkä jossain proof-of-concept vaiheessa. JPEG:issä vaativin laskentatoimitus on DCT ja käänteis-DCT ja kyllä noihin pitäisi löytyä vallan hyvät fixed point versiot.
Sitten kun otetaan huomioon se, että JPEG kehitettiin 80-luvun loppupuolella, niin kuulostaa kyllä aika käsittämättömältä, että sen tehokas toiminta vaatisi liukulukulaskentaa.

*edit*
Näköjään joku kokeillut samaa 286 PC:llä:

About 1min 30 sec, eli hidas, joo. Kymmeniä minuutteja, ei.

 

[Hyrava]

Mihin tuo väite perustuu? En nyt tähän hätään muista miten juurikin JPEG toimi noilta osin (about 20 vuotta aikaa kyseisistä TTY:n kursseista), mutta aikalailla kaikissa koodekeissa on aina pyritty fixed point toteutuksiin ja flotareja käytetään ehkä jossain proof-of-concept vaiheessa. JPEG:issä vaativin laskentatoimitus on DCT ja käänteis-DCT ja kyllä noihin pitäisi löytyä vallan hyvät fixed point versiot.
Sitten kun otetaan huomioon se, että JPEG kehitettiin 80-luvun loppupuolella, niin kuulostaa kyllä aika käsittämättömältä, että sen tehokas toiminta vaatisi liukulukulaskentaa.

Itse ainakin muistan 486/DOS-aikakaudelta että käytin kahta eri kuvankatseluohjelmaa, toisessa JPEG-kuvien katselu oli tuhottoman hidasta mutta softa oli muilta osin parempi ja vastaavasti toinen osasi näyttää JPEG-kuvat järjettömän nopeasti verrattuna tuohon toiseen softaan mutta oli muuten aika rupuinen. Tuon perusteella voisi sanoa että ainakin joskus aikanaan on ollut kovin eritasoisia JPEG-kirjastoja, jotkut olivat erittäin hitaita ja jotkut vastaavasti erittäin nopeita. Sinänsä tuo JPEG-purun nopeus ei ole suoraan konetehosta riippuvainen vaan siitä miten tuo JPEG-rutiini on toteutettu, nykypäivänä tuolla ei enää ole niin suurta merkitystä kun tehoja piisaa.

Toki nykyäänkin olisi hyvä jos asiat tehtäisiin tehokkaasti mutta tosiaan tuo kasvanut suorituskyky on vähän vähentänyt tuota optimointia kun keskivertotapauksessa ei enää juurikaan huomaa eroa keskinkertaisen ja viimeiseen asti optimoidun koodin välillä. Ja nykyäänhän tosiaan suuri osa grafiikan laskemisesta tehdään erillisellä prosessorilla näytönohjaimessa ja siinä on optimoidut käskyt juurikin kaikenlaisten grafiikkaan liittyvien laskutoimitusten tekemiseen.

Itse koodailen harrastukseksi kaikenlaisia mikrokontrollereita ja Commodore 64-koodia sun muita vastaavia ja noissa kyllä huomaa herkästi erot koodin koossa ja tehokkuudessa kun muistia on hyvin rajallinen määrä ja kellotaajuudetkin ovat pieniä (toki mikrokontrollereiden kellotaajuudet ovat pompanneet aika hurjasti viime vuosina, alkaa olla jo satoja megahertsejä parhaimmillaan).

 

[aaaaaa]

Olet varmaan paljon kokeneempi niin olisi mielenkiintoista kuulla, miksi kaikki hidastuu vaikka rauta nopeutuu jatkuvasti. Voiko syy olla se, ettei samanlaista osaamistasoa/intohimoa ole yhtä paljon kuin ennen? Vai onko syy se, että päättäjien mentaliteetti on se, että "koska me voidaan tehdä roskaa ja rahaa tulee silti"

Teknisiä syitä on tässä ketjussa jo ansiokkaasti listattukin, valitettavasti on vain niin, että syyn löytyminen ei vielä poista ongelmaa. Kehittäjät tekevät sitä mitä pyydetään, annetuissa puitteissa, joten en kaataisi ihan kaikkea heidän niskaan. Usein kyse on siitä, että liiketoiminnasta vastaavat eivät joko tunne asiaa tai koe sitä tärkeäksi. Olen työni puolesta ollut aika monessa kehitysprojektissa mukana, enkä muista että liiketoiminnan puolelta olisi kertaakaan tullut kommenttia palvelun nopeudesta. Tosin aika harvoin sitä tulee keneltäkään muulta projektiin osallistuneelta. Mikä on sääli, koska nopeuden vaikutus liiketoimintaan on kiistatonta ja melko helposti mitattavissa:

Amazon study: Every 100ms in Added Page Load Time Cost 1% in Revenue

Amazon did a study that found every 100ms in latency cost 1% of sales.

www.conductor.com

Bloattia on tosiaan nykyverkkosivuissa paljon. Tämän ketjun ensimmäisellä sivulla on tekstisisältöä n. 66 kb, mutta selain lataa silti 1.6 megaa dataa. Sisällön osuus on siis n. 4% siirretystä datasta. Toki jonkinlainen esityskerroskin on luotava. Ylimääräisestä iso osa näyttäisi menevän erilaisten JavaScriptien lataamiseen (isoimpana tämä editori). Ikoneita ladataan 240 kilotavua, lähes 400 erilaista (light/dark modet)! Käyttäjän @root avatar-kuva vie 63 kiloa, eli lähes yhtä paljon kuin tekstisisältö. Kirveellä olisi siis töitä täälläkin. Toisaalta en ole koskaan kokenut TechBBS:ää hitaaksi.

Parikymmentä vuotta sitten ohjelmistojen lataus- ja käynnistysajat olivat pitkiä, mutta kun softa oli lopulta saatu muistiin, niin käyttö oli yleensä viiveetöntä. Ehkä sen takia, että kun muistia oli rajallisesti ja levylle swappaaminen oli hidasta, niin oli pakko optimoida? Nykyään on sitten toisinpäin, mutta jossain se raja tulee silti vastaan.

 

[emagdnim]

Itse ainakin muistan 486/DOS-aikakaudelta että käytin kahta eri kuvankatseluohjelmaa, toisessa JPEG-kuvien katselu oli tuhottoman hidasta mutta softa oli muilta osin parempi ja vastaavasti toinen osasi näyttää JPEG-kuvat järjettömän nopeasti verrattuna tuohon toiseen softaan mutta oli muuten aika rupuinen.

Itsekin muistan, että vanhalla koneella ja windowsilla kuvien selailu oli "tuskaisen" hidasta verrattuna, ku saman teki toisella softalla. Olikoha IrfanView se nopea.

 

[finWeazel]

Paljon on "framework" asioitakin mitä voisi tehdä paremmin. Tyylin softan asennus menee yksinkertaistaen lataus - purku - asennus linjaston läpi. Ihan hyvin voisi toimia käyttöjärjestelmätasolla niin, että ladattu data purettaisiin jo latauksen aikana rinnakkaistetusti ja ehkä jopa (esi?)asennettaisiin latauksen aikana. Lopuksi esiasennettu paketti siirrettäisiin oikeaan sijaintiin. Vaatisi tosin koko asennusasian uudelleenmiettimisen ja toteuttamisen käyttöjärjestelmätasolla.

DirectStorage tyylisen nopeamman rajapinnan soisi yleistyvän koko käyttöjärjestelmätasolla niin ei pienten tiedostojen käpistely esimerkiksi edellämainitussa ohjelmiston asennustapauksessa olisi niin iso pullonkaula.

 

[Paapaa]

Toisaalta en ole koskaan kokenut TechBBS:ää hitaaksi.

En minäkään ja se johtuu osin siitä, että iso osa ladattavasta sisällöstä jää kakkuun. Kun avasin tämän ketjun ensimmäisen sivun, latasi selain 122kB kamaa, ei suinkaan 1,6MB. Itse asiassa ilman kakkuakin ladataan alle 1MB, mutta mainostenesto saattaa vaikuttaa tähän. Kun mene sivulle uudestaan, ladataan paljon vähemmän koska kakutus. Ei tuollaista sadan kilotavun määrää välttämättä kannata lähteä optimoimaan yhtään mihinkään kun se on jo varsin pieni määrä mobiililaitteellekin. Siirretty data on myös paljon pienempi koska se käytännössä aina pakataan ennen siirtoa automaattisesti. Ei vaikuta niinkään kuviin/videoihin, mutta vaikuttaa tekstuaaliseen sisältöön ja esim. js/css-bundleihin.

Olisi toki kiva optimoida kaikki täydellisesti, mutta silloin ei saataisi koskaan mitään valmiiksi ja kaikki maksaisi aivan järkyttävän paljon. Se devaaja kuitenkin laskuttaa aina sen 100e/h, niin pitää kohtuu tarkkaan miettiä, mihin sen käyttää. Siksi optimointi pitää tehdä siellä missä sillä on suurin vaikutus.

 

[love_doctor]

Datan määrä on kasvanut ja monimutkaistunut. 640x200x16 pärjää pienellä 64kB framebufferilla ja grafiikka oli yksinkertaista bittikarttagrafiikkaa. Piirtokomennotkin olivat yhtälailla yksinkertaisia. Hitain oli ympyrän piirtäminen joka ei tietenkään ollut ympyrä vaan soikio.

Nykyään grafiikkatilat ovat olleet jo pitkään 32-bittisiä, fontit antialiasoituja, ympyrä on helppo piirtää niin että se näyttää ympyrältä eikä siinä ole sahalaitaa, grafiikat voidaan skaalata helposti eri kokoisiksi ym. Paljon on poistunut alkuaikojen rajoitteita joita piti vain kestää. Pelkästään JPEG-kuvan dekoodaaminen veisi 286-tason prosessorilla kymmeniä minuutteja.

Joo siis piirtäminen on raskaampaa jo pikselimäärien takia, mutta saatavilla oleva laskentateho on kasvanut ihan eri tahtia kuin pikselimäärät. Esim. 640x200 16 värillä vie 64 kB ja ja 4k-kuva 32-bittisillä väreillä hiukan vajaa 32 MB. Eli noin 500 kertaa enemmän informaatiota ja prosessoitavaa. Samoin voi laskea, että nykyaikainen näyttö voi päivittää esim. 144 Hz ja vanha 50 Hz eli noin kolme kertaa enemmän päivitysnopeutta, yhteensä ero on noin 1493x.

Mutta jos katotaan paljonko koneet on nopeutuneet, esim. muistihakuihin on branch predictorit, cachet ja paljon leveämmät noudot. Ennen vanhaan ei välttämättä päivitetty koko ruutua kerralla vaan vain muuttunut osa, kun pelkkä puskurin kopiointi saattoi syödä parikyt sykliä per pikseli. Ja esim. ikkunoiden koon muuttamisessa piirrettiin animoitaessa vain raamit eikä sisusta. Nyt tehdään tavallaan "typerästi" kun tehoa riittää. Tehoero on ihan murskaava kun miettii että prosessorilla on 4 megahertsin sijaan nopeus 4 gigahertsiä ja käskyjen leveys on tällaisiin massaoperaatioihin jopa 64-kertaistunut. Lisäksi IPC on pudonnut massaoperaatioissa noin yhteen ja ydinmäärä eksponentiaalisesti. Eli helposti ero voi olla kymmeniä tai satoja miljoonia kertoja. Sitä isompi, mitä enemmän tehdään aritmetiikkaa. Mutta kaiken tämän päälle renderöinti on siirretty GPU:lle. Jo 30 vuotta sitten dedikoitu GPU teki ihmeitä Amigan tapaisissa koneissa ja myös PC:llä 2d-kiihdyttimet tehostivat paljon. Hyvä esimerkki nykyään GPU-offloadaamisen hyödyistä on nuo Wavesharen sulautetut näytöt, joissa voi fullhd-kuvaa ohjata 8-bittisellä Arduinolla 115,2k sarjaportin yli.

 

[Karhu III]

Mihin tuo väite perustuu? En nyt tähän hätään muista miten juurikin JPEG toimi noilta osin (about 20 vuotta aikaa kyseisistä TTY:n kursseista), mutta aikalailla kaikissa koodekeissa on aina pyritty fixed point toteutuksiin ja flotareja käytetään ehkä jossain proof-of-concept vaiheessa. JPEG:issä vaativin laskentatoimitus on DCT ja käänteis-DCT ja kyllä noihin pitäisi löytyä vallan hyvät fixed point versiot.
Sitten kun otetaan huomioon se, että JPEG kehitettiin 80-luvun loppupuolella, niin kuulostaa kyllä aika käsittämättömältä, että sen tehokas toiminta vaatisi liukulukulaskentaa.

Fixed point heikentää laatua. Ero riippuu toteutuksesta ja applikaatiosta, mutta flotariversio on aina laadultaan parempi. Nykyään kun FPU löytyy joka laitteesta ja sen tukemat konekielikäskyt on optimoitu tappiin, niin ei ole mitään syytä käyttää enää fixed point versioita. Ehkä joissain sulautetuissa.

*edit*
Näköjään joku kokeillut samaa 286 PC:llä:

About 1min 30 sec, eli hidas, joo. Kymmeniä minuutteja, ei.

Tuossa on flotariyksikkö 80287 mikä nopeuttaa. Se toimii erillään CPU:sta ja voi suorittaa omiaan sillä aikaa kun CPU tekee muuta. Muistaakseni FPU:n ei tarvitse pyöriä edes samalla kellotaajuudella CPU:n kanssa.

 

[JCSH]

Fixed point heikentää laatua. Ero riippuu toteutuksesta ja applikaatiosta, mutta flotariversio on aina laadultaan parempi. Nykyään kun FPU löytyy joka laitteesta ja sen tukemat konekielikäskyt on optimoitu tappiin, niin ei ole mitään syytä käyttää enää fixed point versioita. Ehkä joissain sulautetuissa.

Juu fixed point heikentää laatua. Mutta kun puhutaan jostain JPEG:in DCT:stä, joka lähtökohtaisesti paskoo sitä laatua, niin . Sitten kun niitä koodekkeja halutaan ajaa mahdollisimman virtapihisti mahdollisimman halvalla raudalla, niin ne fixed point toteutukset ovat välttämättömiä noiden koodekkien kehityksessä.
Jos vilkaiset vaikkapa libjpegin, eli se O.G. jpeg koodekki referenssi, niin sieltä löytyy DCT:t ja I-DCT:t niin flotareille kuin fixed pointille. Oikeastaan sieltä löytyy kaksi fixed point toteutusta. Toinen hitaampi (ja tarkempi), toinen nopeampi.
Tai jos et halua kaivella jotain hiton SourceForge zippejä, niin libjpeg-turbo, i.e. nykyinen referenssi, löytyy ihan Gitlabista:

GitHub - libjpeg-turbo/libjpeg-turbo: Main libjpeg-turbo repository

Main libjpeg-turbo repository. Contribute to libjpeg-turbo/libjpeg-turbo development by creating an account on GitHub.

github.com

Siellä sama juttu. Lisäksi turbosta löytyy myös simd toteutukset.

Eli joo, varmasti jos ajat jotain flotariversiota JPEG dekooderista 286:lla, jossa ei ole FPU:ta, niin on hidasta. Mutta se ei estä sitä, ettetkö voisi ajaa sitä reippaasti nopeampaa fixed point versiota.

 

[love_doctor]

Tuossa on flotariyksikkö 80287 mikä nopeuttaa. Se toimii erillään CPU:sta ja voi suorittaa omiaan sillä aikaa kun CPU tekee muuta. Muistaakseni FPU:n ei tarvitse pyöriä edes samalla kellotaajuudella CPU:n kanssa.

90-luvulla peleissä ei käytetty FPU:ta, kun se oli kallis ja harvinainen ja noissa alkupään FPU-toteutuksissa x86:lla arvojen siirtely vaatii muistaakseni jopa keskeytyksen joka FPU-käskyllä ja muutenkin oli varsin hidasta pinomaisen rakenteen takia. x86:lla on myöhemmin toteutettu järkevämmin liukuluvut. Nykyäänhän noita x87-käskyjä ei enää käytetä kun ne on niin paskoja, vaikka laitteet tukisikin.

Jos ei tarvi emuloida x87:n 80-bittisiä flotareita, niin fixed pointilla pystyy tekemään kyllä nopeaa laskentaa esim. Doomin tapaisiin peleihin, joissa on rajattu käyttöalue. Myös jotain kuvia ja ääntä voi prosessoida. Esim. ogg vorbiksesta ja vastaavista on fixed point -koodekkeja noille vanhan ajan mp3-soittimille, joissa ei ollut rautatukea flotareille.

Fixed point heikentää laatua. Ero riippuu toteutuksesta ja applikaatiosta, mutta flotariversio on aina laadultaan parempi. Nykyään kun FPU löytyy joka laitteesta ja sen tukemat konekielikäskyt on optimoitu tappiin, niin ei ole mitään syytä käyttää enää fixed point versioita. Ehkä joissain sulautetuissa.

Fixed point tosiaan voi säästää energiaa sulautetuissa myös.

 

[Karhu III]

Mutta jos katotaan paljonko koneet on nopeutuneet, esim. muistihakuihin on branch predictorit, cachet ja paljon leveämmät noudot. Ennen vanhaan ei välttämättä päivitetty koko ruutua kerralla vaan vain muuttunut osa, kun pelkkä puskurin kopiointi saattoi syödä parikyt sykliä per pikseli. Ja esim. ikkunoiden koon muuttamisessa piirrettiin animoitaessa vain raamit eikä sisusta. Nyt tehdään tavallaan "typerästi" kun tehoa riittää.

Nykyaikaisella desktop managerilla ikkunan sisällön päivittäminen ikkunan kokoa muutettaessa ei ole ollenkaan raskasta. Piirtoeventit täytyy jumpata n-kertaa läpi, mutta varsinaisen työn hoitaa nykyään GPU eikä CPU.

Jo 30 vuotta sitten dedikoitu GPU teki ihmeitä Amigan tapaisissa koneissa ja myös PC:llä 2d-kiihdyttimet tehostivat paljon.

Amigan ikkunointimanageri oli tehoton. Jokainen avattu ikkuna hidasti konetta, ensin vähän, mutta jo yli kymmenen ikkunaa hidasti piirtoa huomattavasti. Ongelma on siis enemmän algoritminen kuin suorituskykyperusteinen. Parjattu Windows 3 toteutti tämänkin paremmin

AIkoinaan tuli käytyä tämä Amigan kehityskaari läpi. Alussa A1200 boottasi Workbenchiin muutamasssa sekunnissa. Sitten piti saada pari apuohjelmaa helpottamaan käyttöä. Boottiaika piteni kymmeneen sekuntiin. Sitten CPU-kiihdytin, myöhemmin parempi CPU-kiihdytin ja grafiikkakortti. Boottiaika oli jo puoli minuuttia ellei enemmän. Alkoi jo harmittaa, mutta bootissa ei ollut mitään sellaista mistä ei olisi halunnut luopua.

 

[root]

Käyttäjän @root avatar-kuva vie 63 kiloa, eli lähes yhtä paljon kuin tekstisisältö. Kirveellä olisi siis töitä täälläkin. Toisaalta en ole koskaan kokenut TechBBS:ää hitaaksi.

Ziisus sentään, minulla on avatarit kokonaan pois päältä juuri tällaisten hönöjen ansiosta Vaihtoon menee avatar, kunhan kerkiän.

 

[love_doctor]

Nykyaikaisella desktop managerilla ikkunan sisällön päivittäminen ikkunan kokoa muutettaessa ei ole ollenkaan raskasta. Piirtoeventit täytyy jumpata n-kertaa läpi, mutta varsinaisen työn hoitaa nykyään GPU eikä CPU.

Joo GPU, kuten tossa lopussa sanoinkin. Siis pointti oli, että koko näytön kopiointi tuplapuskurista näkyviin oli jo operaationa uskomattoman raskas sen ajan koneille. Page flipping tietty auttoi. Olin aika yllättynyt kun joskus tein ekaa peliä mode 13h:lla, miten paljon aikaa oikeasti meni 386:llakin sen 64 000 tavun siirtoon joka frame. Nykyäänhän softarenderöimällä ja tuplapuskuroimalla CPU:lla siirtäisi 4k-resoluutiollakin tuhansia frameja sekunnissa ja se olisi vasta yhden ytimen työ ja 15 ytimelle sitten keksisi muuta.

Amigan ikkunointimanageri oli tehoton. Jokainen avattu ikkuna hidasti konetta, ensin vähän, mutta jo yli kymmenen ikkunaa hidasti piirtoa huomattavasti. Ongelma on siis enemmän algoritminen kuin suorituskykyperusteinen. Parjattu Windows 3 toteutti tämänkin paremmin

Noissa jos rautasuunnittelu menisi käsi kädessä softan tarpeiden kanssa ja olisi järkeviä piirtoalgoritmeja niin homma pelaisi. X:ssäkin on damage extension, mutta sekin taitaa olla uudistuksia vasta 2000-luvun puolivälistä. Toki esim. ikkunoiden siirrossa en ole täysin varma, kuinka kamala olisi tyylillisesti nykyäänkään piirtää vaan reunat kokoa muuttaessa.

 

[takomo]

*edit*
Näköjään joku kokeillut samaa 286 PC:llä:

About 1min 30 sec, eli hidas, joo. Kymmeniä minuutteja, ei.

286 taisi olla vielä aika rupuinen myös kokonaislukuaritmetiikassa. Kerto- ja jakolaskut löytyivät mutta olivat hitaita. 386 sai nopean kertolaskuyksikön, ja mikä parasta, se tuki 32b x 32b = 64b pitkää kertolaskua. 386 taisi tukea myös nopeita shiftejä, mille on käyttöä fixed-point -aritmetiikassa.

Itse koodailen harrastukseksi kaikenlaisia mikrokontrollereita ja Commodore 64-koodia sun muita vastaavia ja noissa kyllä huomaa herkästi erot koodin koossa ja tehokkuudessa kun muistia on hyvin rajallinen määrä ja kellotaajuudetkin ovat pieniä (toki mikrokontrollereiden kellotaajuudet ovat pompanneet aika hurjasti viime vuosina, alkaa olla jo satoja megahertsejä parhaimmillaan).

Sama asennoituminen voi olla hyödyksi myös pöytäkoneprosessoreilla. Jos koodi ja data on kompakteja, ne pysyvät välimuisteissa, jopa nopeimmassa L1-välimuistissa. Keskusmuistista haku on vähän kuin eilispäivän nauha-asema: ottaa aikansa, ennen kuin uusi kela on paikoillaan mutta sitten dataa tulee sitään joutuisasti.

 

[huglo]

Työläppärin Windows 11:n Painttia piti käyttää. Tekstiä piti lisätä kuvaan ja sitä ennen valita väri jota ei löytynyt normaalista listasta. Kummankin työkalun avautuminen kesti sekuntitolkulla. P sarjan thinkpad vuosimallia 2023 taitaa olla. Tämäkin on varmaan koodarien mielestä normaalia/merkityksetöntä/asia joka pitää vain hyväksyä.

Windows XP:ssä jollain single core paskeella paintin työkalut sentään aukesivat heti eikä se itse softakaan juuri sen kauemmin latautunut.

 

[love_doctor]

Nykyään alkaa Zoom tuntua myös hiukan kankealta. Ryzen 5950X 64 gigan muistilla ja PCIe 4.0 -tason NVMe-levyllä rouskuttaa jonkin aikaa käyntiin. Katselin, niin ohjelman koko on kyllä kasvanut kiitettävästi lähikuukausina (kuvakaappaus). Aiemminhan 650 megan CD-levylle mahtui koko käyttöjärjestelmä.

 

[Sompi]

JPEG-formaatin purkamiseen liittyi muinoin paljon softapatentteja, ja nopeimmat tunnetut algoritmit olivat joko patentoituja tai ainakin patenttitrollaus niiden suhteen oli yleistä. Vapaan koodin ohjelmissa käytettiin yleensä varmuuden vuoksi jotain hitaampaa ja huonompaa algoritmia.

HTTP/2, bundlerit ja vastaavat myös poistavat round-trippejä tuosta kommunikaatiosta.

"HTTP/2" (jolla ei itse asiassa ole mitään tekemistä alkuperäisen HTTP-protokollan kanssa) on itse asiassa melkoisen hidas ja bloatti protokolla verrattuna HTTP/1.x-protokollaan. Nykyään HTTP/1.x-protokollaa hidastaa TLS-kättely silloin, kun HTTP/1.x-protokollaa käytetään salattuna. Kysehän on salausagnostisesta protokollasta. Jos TLS-protokollan tilalle kehitettäisiin jokin fiksumpi protokolla, jossa ei tarvitsisi joka yhteyttä varten kättelyä erikseen, niin HTTP/1.x voittaisi kyllä nopeudessa ja yksinkertaisuudessa selvästi nuo Googlen pakottamat uudemmat korvikeprotokollat.

lEEt/OSin piirtorutiinit laskevat aika tarkasti, mitkä osat näytöstä pitää piirtää uusiksi, eivätkä piirrä muuta. Siihen laskeskeluunkin toki menee jonkin verran CPU-syklejä, mutta varsinkin VGA:n ja EGA:n planaaristen näyttötilojen (eli niiden 16-väristen hi-res-tilojen) kanssa se yksittäisten pikselien piirtäminen on tosi hidasta ja vaatii paljon in/out-käskyjä, joiden ajan vieläpä sekä prosessori että koko väylä ovat jumissa eikä mikään tietokoneen osa voi tehdä muuta kuin odottaa sitä näytönohjainta.

Ne EGA:n ja VGA:n planaariset hi-res-tilat ovat ainakin IBM PC-yhteensopivassa raudassa sellainen omaa aikakauttansa edustava poikkeus, ja sekä sitä vanhemmat että sen jälkeen tulleet näyttötilat ovat pääosin huomattavasti nopeampia yksittäisten pikselien piirrossa. Tuskin edes nykyraudalla kannattaa minkään vähänkään korkearesoluutioisemman näyttötilan kanssa alkaa joka framea varten kopioimaan koko näytön sisältöä jostain tuplapuskurista näyttömuistiin, koska siinä on kuitenkin melkoisen paljon kopioitavaa, ja vaikka siihen laskentakapasiteetti riittäisikin, niin siihen kuitenkin kuluisi merkittävä osuus käytettävissä olevasta suoritinajasta.

 

[Karhu III]

PC.ssä oli pakko käyttää planaarigrafiikkaa koska 640x350 ei mahtunut enää yhteen 64 kB segmenttiin. Sen takia myös VGA:lla mentiin sen takia vähän takaperoisesti vaikka siinä oli kunnollinen 8-bit chunky mode.

PC:n ulkopuolella planaarigrafiikkaa käyttivät Atari ST ja Amiga. Näissä taas syyt olivat toisenlaiset: optimointi. Keskusmuisti oli myös näyttömuisti ja bitplanejen määrää säätämällä pystyi optimoimaan muistinkäyttöä ja kaistaa. Muita mainstream 16/32-bittisiä kotitietokoneita ei tainnut ollakaan.

 

[Sompi]

Ei planaarigrafiikalla ole varsinaisesti mitään tekemistä muistisegmentoinnin kanssa. Segmentit liittyvät siihen, miten 8086-yhteensopiva prosessori esittää muistiosoitteet ohjelmoijalle. Näytönohjain taas on kokonaan prosessorista riippumaton oheislaite, joka ei ymmärrä muistisegmenteistä tuon taivaallista. Tuo planaarisuus liittynee pikemminkin IBM PC-yhteensopivien tietokoneiden muistikarttaan, jossa näyttömuistille on varattu vain muistisegmentit väliltä A000-B999, eli vain 128 kilotavua näyttömuistia voi kerrallaan näkyä prosessorille. VGA:n 640x480 pikselin ja 16 värin näyttötilan kaikki pikselit kuitenkin tarvitsevat yhteensä 150 kilotavua muistia, koska jokainen pikseli vaatii neljä bittiä eli puoli tavua. Yksi väriplaani vie 37,5 kilotavua muistia ja näytönohjainmuisti saadaan siis mahtumaan aivan hyvin tuohon 128 kilotavun muisti-ikkunaan, kun siitä mapataan siihen vain se yksi plaani kerrallaan.

EGA:n planaarinen tila (640x350 pikseliä) vaatii vain 109,375 kilotavua muistia (28000 tavua per väriplaani) eli periaatteessa mahtuisi siihen 128 kilotavun muistialueelle, joka perusmuistiavaruudesta on varattu näyttömuistia varten. Kuitenkin MDA:n tekstitilan muisti alkaa segmentistä B000 (eli 64 kilotavun päästä näyttömuistille varatun muistialueen alusta) ja CGA:n, EGA:n ja VGA:n tekstitilan muisti taas alkaa segmentistä B800 (eli 96 kilotavun kohdalta) ja todennäköisesti planaarisuudella on haluttu välttää päällekkäisyyttä tekstitilamuistin ja grafiikkatilamuistin osoitteiden kanssa. Ainakin joissain EGA- ja VGA-korteissa se laitteistokiihdytetyn tekstitilan toiminta taitaa olla riippuvaista siitä, että grafiikka- ja tekstitilojen muistit eivät mene päällekkäin.

 

[Karhu III]

Kuvittelin että CPU:ssa joudutaan vaihtamaan segmenttiä sen mukaan mihin kohtaan näyttömuistia kirjoitetaan. Mutta eipä mulla ole kokemusta matalan tason koodauksesta PC:llä.

Mutta mistä sait tuon 109,375? 4 x 28000 = 112000...

 

[kolistelija]

Mutta mistä sait tuon 109,375? 4 x 28000 = 112000...

109,375 x 1024 = 112000?

 

[Karhu III]

109,375 x 1024 = 112000?

Äh joo, vanhasta tottumuksesta en pitänyt pilkkua pilkkuna

 

[takomo]

Tuo planaarisuus liittynee pikemminkin IBM PC-yhteensopivien tietokoneiden muistikarttaan, jossa näyttömuistille on varattu vain muistisegmentit väliltä A000-B999, eli vain 128 kilotavua näyttömuistia voi kerrallaan näkyä prosessorille. VGA:n 640x480 pikselin ja 16 värin näyttötilan kaikki pikselit kuitenkin tarvitsevat yhteensä 150 kilotavua muistia, koska jokainen pikseli vaatii neljä bittiä eli puoli tavua. Yksi väriplaani vie 37,5 kilotavua muistia ja näytönohjainmuisti saadaan siis mahtumaan aivan hyvin tuohon 128 kilotavun muisti-ikkunaan, kun siitä mapataan siihen vain se yksi plaani kerrallaan.

Iso haaste real-moodissa x[012]86-koodissa on, että muistinosoituksien offset on rajoitettu 16 bittiin eli 64kB. Kaikki mikä menee tästä yli, on hidasta. Alle 64 kB blokeille riittää ladata kerran segmentti (esim. mov es,$b000) ja sen jälkeen voidaan koko 64kB blokkia osoittaa nopeasti; mov di,<index>; mov es:[di], cx - tjsp. Jos ES-segmenttirekisteriä ei käytetä mihinkään muuhun, se voi osoittaa koko ajan näyttömuistiin.

Se, että muistiavaruutta on varattu 128 kB on oikeastaan irrelevanttia, kun vain 64kB blokkia pystytään osoittamaan tehokkaasti. Avain jonkinlaiseen tehokkuuteen on käsitellä muistia plaani kerrallaan eikä pikseli pikseliltä.

 

[Sompi]

Iso haaste real-moodissa x[012]86-koodissa on, että muistinosoituksien offset on rajoitettu 16 bittiin eli 64kB. Kaikki mikä menee tästä yli, on hidasta. Alle 64 kB blokeille riittää ladata kerran segmentti (esim. mov es,$b000) ja sen jälkeen voidaan koko 64kB blokkia osoittaa nopeasti; mov di,<index>; mov es:[di], cx - tjsp. Jos ES-segmenttirekisteriä ei käytetä mihinkään muuhun, se voi osoittaa koko ajan näyttömuistiin.

Se, että muistiavaruutta on varattu 128 kB on oikeastaan irrelevanttia, kun vain 64kB blokkia pystytään osoittamaan tehokkaasti. Avain jonkinlaiseen tehokkuuteen on käsitellä muistia plaani kerrallaan eikä pikseli pikseliltä.

Samoissa fyysisissä osoitteissa se näyttömuisti kuitenkin on prosessorin osoitustilasta riippumatta. Osoitteen esitystapa vain hieman muuttuu.

 

[takomo]

Samoissa fyysisissä osoitteissa se näyttömuisti kuitenkin on prosessorin osoitustilasta riippumatta. Osoitteen esitystapa vain hieman muuttuu.

Pointti onkin siinä, että 16-bittisessä ympäristössä laaja fyysinen osoiteavaruus ei ole eduksi, koska vain 16-bittisesti osoitettavia muistialueita pystyy käsittelemään tehokkaasti.

Ei näitä plaanisivutuksia ole turhan takia tehty vaan siksi, että plaaneja pystyy käsittelemään tehokkaasti.

[EDIT] Käyttikö mikään näytönohjain tavanomaisesti $Axxx -segmenttejä (640-704k)? Osa klooneista taisi tarjota jopa 720k ($0000-$b3ff) DOS-ohjelmien käyttöön.

 

[Bigfoot007]

Kokemukseni ammattiohjelmistoista kärjistäen: Perinteistä koodausta ei enää osata, kaikki rattaat pyörivät monimutkaisen pilvi / serveri farmien kautta sen sijaan, että natiivisofta pyörisi omalla työasemalla, softan ulkoistus Intiaan ja muihin paskamaihin, "halpojen" startup firmojen käyttö joiden toteutus on tasoa rimaa hipoen ja perävalotakuu.

 

[kolistelija]

Kokemukseni ammattiohjelmistoista kärjistäen: Perinteistä koodausta ei enää osata, kaikki rattaat pyörivät monimutkaisen pilvi / serveri farmien kautta sen sijaan, että natiivisofta pyörisi omalla työasemalla, softan ulkoistus Intiaan ja muihin paskamaihin, "halpojen" startup firmojen käyttö joiden toteutus on tasoa rimaa hipoen ja perävalotakuu.

Avaisitko vähän mitä perinteinen koodaus on?

 

[Desgorr]

Kokemukseni ammattiohjelmistoista kärjistäen: Perinteistä koodausta ei enää osata, kaikki rattaat pyörivät monimutkaisen pilvi / serveri farmien kautta sen sijaan, että natiivisofta pyörisi omalla työasemalla, softan ulkoistus Intiaan ja muihin paskamaihin, "halpojen" startup firmojen käyttö joiden toteutus on tasoa rimaa hipoen ja perävalotakuu.

Mistä kulmasta tuota nyt haluaakaan katsoa. Noin IT-tuen kulmasta katsottuna selaimella tarjottava (SaaS) softa on huomattavasti vähemmän työtunteja kuluttava vaihtoehto kun natiivina Windows -ohjelmana tarjottava softa. Natiivissa Windows softassa hommaa tulee kuitenkin ihan eri tavalla mahdollisten ongelmien selvitysten, lisensoinnin, paketoinnin, jakelun ja päivittämisen kannalta. Toki jossain muutaman ihmisen puulaakissa ei niin suurta merkitystä, mutta kun mennään isompiin määriin niin kaikki kuormitus mitä IT-tuelta saadaan pois on vaan plussaa ja jää sitten aikaa johonkin muuhun tekemiseen.

Ja toki kaikkea softaa ei oikein voi selaimella ajaa tai ole työtehon kannalta järkevää, eli natiiville Windows -softallekin on vielä paikkansa.

 

[Bigfoot007]

Avaisitko vähän mitä perinteinen koodaus on?

Ohjelmointikielet kuten C ja Python. Nykyajan softat kasataan valmiista palikoista, joista ainoastaan tweakataan ja tuloksena on raskaita bugikasoja, jotka ovat kiinni useammassa monikansallisissa serverissä. mm. Oracleen on yksi suuri saatana koko toimialalla.

 

[kolistelija]

Ohjelmointikielet kuten C ja Python. Nykyajan softat kasataan valmiista palikoista, joista ainoastaan tweakataan ja tuloksena on raskaita bugikasoja, jotka ovat kiinni useammassa monikansallisissa serverissä. mm. Oracleen on yksi suuri saatana koko toimialalla.

Aika harvat natiiviohjelmat on Pythonilla tehty (ja siinäkin on tarjolla loputon valmiiden palikoiden kirjo). Ei C:täkään kovin usein käytetä natiivisovelluksiin. Lisäksi nekin on tehty valmiista palikoista jo vuosikymmenten ajan.

Siitä on aika pitkä aika kun sovellukset oikeasti koodattiin pitkästä tavarasta C:llä ja Pythonilla kirjoitettu raskas työpöytäsovellus kuulostaa vähintäänkin jännältä.

 

[Karhu III]

OO-tyylinen ohjelmointi tekee projektien hallinnasta helpompaa ja tämähän puuttuu C:stä kokonaan. Voi toki upottaa structeja structin sisään ja käyttää dynaamisia funktiopointtereita, mutta tässä vaiheessa C++-koodaaja ajaa ohi ja lujaa. Ja vastaavasti C#-koodaaja on jo shipannut projektin kun C++-koodaaja vasta testaa (C-koodaaja on edelleen jumissa jossain kaukana).

Eikä C-kieli takaa laatua vaikka olisi vanhakin parta koodaamassa. Olen nähnyt vanhan liiton C-koodareita jotka kopioivat merkkijonoja johonkin 4096 tavun puskuriin käyttäen strncpy() kutsua. Eivät edes ymmärrä kun yrittää selittää että tuo on todella tehotonta

 

[Paapaa]

Eikä C-kieli takaa laatua vaikka olisi vanhakin parta koodaamassa. Olen nähnyt vanhan liiton C-koodareita jotka kopioivat merkkijonoja johonkin 4096 tavun puskuriin käyttäen strncpy() kutsua. Eivät edes ymmärrä kun yrittää selittää että tuo on todella tehotonta

Ei missään nimessä takaa. Ei ole ihme, että Rust on nopeasti saanut suosiota juuri C:n ja C++:n kustannuksella. Sillä saa tehtyä äärimmäisen (=yhtä) nopeaa koodia ilman pelkoa muistivuodoista. Ja se on aika paljon C:tä ilmaisuvoimaisempi kieli, mikä tekee kehittämisestä sujuvampaa. Toisaalta Rust on kohtuullisen vaikea kieli opetella tiukan tyypityksen ja borrow checkerin takia, ja UI-puolella kirjastot vielä hakevat muotojaan.

 

[Sompi]

Ilmaisuvoimainen? Miten Rustilla tehdään kahteen suuntaan linkitetty lista?

Entä milloin siitä rustc:n koodigeneraattorista korjataan ne kaikki porttautuvuutta haittaavat bugit? Eihän se edelleenkään tuota edes virheetöntä i686-koodia, ja niillä kehittäjillä ei ole aikomustakaan korjata sitä.

Sinänsä rust-kieli kyllä sopii hyvin nimenomaan tähän aiheeseen. Kysehän on niin valtavan bloatista systeemistä, että esimerkiksi Firefoxin kääntäminen ei enää onnistu neljän gigatavun muistilla, koska siinä on muutama rustilla kirjoitettu moduuli. Ja monimutkaisuus siinäkin vain lisääntyy jatkuvasti.

Enkä ole vielä nähnyt yhtään ohjelmaa, joka olisi alkanut toimimaan paremmin tai nopeammin sen jälkeen, kun sen koodikantaan on lisätty rust-kieltä.

Käännetyn rust-koodin nopeus on suurin piirtein samalla viivalla C++:n kanssa, mutta C menee kyllä ohi molemmista.

 

[Xiyng]

Miten C:llä kirjoitetaan epätriviaali muistinkäytön osalta tietoturvallinen ohjelma? Vastaus: Ei kirjoiteta. Erittäin kovalla osaamisella ja huolellisella (lue: kalliilla) tekemisellä ongelmat saa lopulta vähiin.

Ja mikä oli pointtini? Kaikilla valinnoilla on hintansa, ja tietoturva tuppaa maksamaan jotain. Rustin tapauksessa se maksaa sen, että joidenkin asioiden ilmaiseminen on hankalaa, ja linkitetty lista on yksi niistä. Onneksi se ei käsittääkseni ole yleensä paras ratkaisu edes silloin, kun sen voisi kuvitella olevan, vaan muut ratkaisut ajavat esim. suorituskyvyssä ohi. Rustin tapauksessa sen sijaan käyttöliittymät taitavat tällä hetkellä olla yksi isoimmista merkittävistä kipukohdista.

 

[Sompi]

Miten C:llä kirjoitetaan epätriviaali muistinkäytön osalta tietoturvallinen ohjelma?

Olemalla tekemättä dynaamisia muistinvarauksia ja antamatta funktioille argumenteiksi pointtereita mihinkään taulukkomuotoisiin pino-objekteihin. Toki tuollainen on sen verran rajoittavaa, ettei se työpöytäohjelmistojen tapauksessa oikein tule kysymykseen, mutta sulautettujen laitteiden laiteohjelmistoissa tuo toimii ja jopa lisää suorituskykyä entisestään.

Ja mikä oli pointtini? Kaikilla valinnoilla on hintansa, ja tietoturva tuppaa maksamaan jotain. Rustin tapauksessa se maksaa sen, että joidenkin asioiden ilmaiseminen on hankalaa, ja linkitetty lista on yksi niistä. Onneksi se ei käsittääkseni ole yleensä paras ratkaisu edes silloin, kun sen voisi kuvitella olevan, vaan muut ratkaisut ajavat esim. suorituskyvyssä ohi. Rustin tapauksessa sen sijaan käyttöliittymät taitavat tällä hetkellä olla yksi isoimmista merkittävistä kipukohdista.

Sekä C:llä että rustilla on akilleen kantapäänsä, eikä rust todellakaan ole mikään ongelmaton ratkaisu olemassa olevien matalan tason kielten korvaajaksi. Rustin ympärillä pyörivän politiikan takia rust tuo projektiin vielä enemmän ongelmia kuin sen olisi teknisesti välttämätöntä tuoda. Rustin ympärille on myös kehittynyt uskonto, jonka teeseihin kuuluu hypettää rust-kieltä jonakin ihmeratkaisuna, joka poistaa kaikki bugit ja tietoturvaongelmat, ja se on ärsyttävää.

Linkitetty lista ei ole mitenkään erityisen tehoton ratkaisu, jos vaihtoehtona on muuttuvapituinen taulukko, jonka kokoa muutetaan usein ja jota saatetaan kokoa kasvatettaessa useinkin joutua siirtämään eri kohtaan muistissa, jos siihen vanhaan paikkaan ei kasvava taulukko enää mahdu. Toki C:llä on mahdollista tehdä molempia. Isojen struktien kanssa se linkitetty lista on parempi.

Linkitetyn listan tehottomuus ei perustu välimuistiepäoptimaalisuuteen, vaan siihen, että niitä pointtereita listan seuraaviin soluihin on hitaampaa seurata kuin vain ynnätä siihen taulukon alkupointteriin joku valmiiksi tunnettu luku. Sen takia linkitetyt listat monissa käyttötapauksissa linkitetään molempiin suuntiin. Isompien listojen kanssa saatetaan myös käyttää edistyneempiä hakualgoritmeja kuten punamustaa puuta, mutta silloin tietysti datan lisääminen listaan hidastuu - onko se sitten ongelma, riippuu käyttötapauksesta.

Itse asiassa taulukko, jota joudutaan siirtelemään muistissa usein eri kohtaan, on välimuistin kannalta paljon linkitettyä listaa epäoptimaalisempi vaihtoehto, ja usein siis myös kokonaisuudessaan hitaampi, koska nykyprosessorit ovat huomattavasti muistia nopeampia.

Väitetysti rustilla ei ole ollenkaan mahdollista tehdä kahteen suuntaan linkitettyä listaa. En osaa rust-kieltä, joten en tiedä, onko se totta. Nykyisellään rustissa kuitenkin on niin paljon ongelmia, että missään omassa projektissani se ei toimisi. Linuxin kaltaisessa portattavaksi tarkoitetussa käyttöjärjestelmäytimessä rustin merkittävin ongelma on portattavuuden puute, jota rustin nykyiset kehittäjät eivät edes haluakaan korjata, ja siksi itse peruskernelin tietokonearkkitehtuuririippumattomia osia ei voidakaan rustilla kirjoittaa miltään osin. Toisiksi merkittävin ongelma on sitten se, että monet asiat rustissa muuttuvat koko ajan toisenlaisiksi eikä mikään ole vakaata - ja tuosta syystä sen käyttö Linuxin moduuleissakin on kovassa vastatuulessa.

 

[Paapaa]

Rustin tapauksessa se maksaa sen, että joidenkin asioiden ilmaiseminen on hankalaa, ja linkitetty lista on yksi niistä. Onneksi se ei käsittääkseni ole yleensä paras ratkaisu edes silloin, kun sen voisi kuvitella olevan, vaan muut ratkaisut ajavat esim. suorituskyvyssä ohi. Rustin tapauksessa sen sijaan käyttöliittymät taitavat tällä hetkellä olla yksi isoimmista merkittävistä kipukohdista.

Juuri näin.

Kaksisuuntaisesta linkitetystä listasta löytyy silti yksi toteutus Rustin standardikirjastosta: LinkedList in std::collections - Rust (ei mikään täydellinen Sveitsin armeijhan linkkari, mutta silti).

Mukana ihan oleellinen huomio:

NOTE: It is almost always better to use Vec or VecDeque because array-based containers are generally faster, more memory efficient, and make better use of CPU cache.

Taas kerran pitää vaan vaivautua siirtymään eteenpäin sieltä kultaiselta 80-luvulta. Vaikka linkitetyt listat ovatkin jokaisen ohjelmoinnin peruskurssin peruskauraa, eivät ne ole lainkaan järkeviä rakenteita suurimpaan osaan käyttötapauksia. Mutta jos haluaa käyttää kieltä typerästi, niin kyllä sekin Rustilla onnistuu. Ja unsafe on ystäväsi jos haluaa jostain ihmeen syystä leikkiä pointereilla.

 

[arcane]

Haluaisin olla kärpäsenä katossa siinä palaverissa jossa joku esittää devitiimille että haluaa latausanimaation ilman että sille on tarvetta (lue: en usko että sellaista oikeasti tapahtuu).

Tervetuloa palaveriimme, jossa ehdotettiin että kaikkia sähköposti-ilmoituksia viivästetään satunnaisesti 4-7 päivää, koska muuten näyttää liian epäilyttävältä kun käyttäjä käyttää uutta sovellusta liian nopeasti eikä paperien pyörittelyssä enää menekään viikkoa.

Eli: kyllä tapahtuu, varmasti.

 

[Sompi]

Juuri näin.

Kaksisuuntaisesta linkitetystä listasta löytyy silti yksi toteutus Rustin standardikirjastosta: LinkedList in std::collections - Rust (ei mikään täydellinen Sveitsin armeijhan linkkari, mutta silti).

Mukana ihan oleellinen huomio:



Taas kerran pitää vaan vaivautua siirtymään eteenpäin sieltä kultaiselta 80-luvulta. Vaikka linkitetyt listat ovatkin jokaisen ohjelmoinnin peruskurssin peruskauraa, eivät ne ole lainkaan järkeviä rakenteita suurimpaan osaan käyttötapauksia. Mutta jos haluaa käyttää kieltä typerästi, niin kyllä sekin Rustilla onnistuu. Ja unsafe on ystäväsi jos haluaa jostain ihmeen syystä leikkiä pointereilla.

Ymmärrätkö nyt, mistä on edes kyse? Tietysti se taulukko on välimuistin kannalta parempi, jos se pysyy muistissa samassa paikassa. Jos taulukon kokoa (solujen määrää) muutellaan, niin silloin koko taulukkoa saatetaan joutua siirtelemään sen kokoa kasvatettaessa, jolloin linkitetty lista on usein välimuistin kannalta se parempi tapa säilöä tietoa, koska linkitettyyn listaan uutta solua lisätessä se vanha olemassa ollut tieto pysyy samassa kohdassa muistia. Jos taas solujen määrä pysyy aina samana, niin silloin tietysti taulukko on itsestäänselvästi parempi ja tehokkaampi, eikä sellaisessa tilanteessa ainakaan toivottavasti tule kenellekään mieleenkään käyttää linkitettyä listaa.

 

[kolistelija]

Tervetuloa palaveriimme, jossa ehdotettiin että kaikkia sähköposti-ilmoituksia viivästetään satunnaisesti 4-7 päivää, koska muuten näyttää liian epäilyttävältä kun käyttäjä käyttää uutta sovellusta liian nopeasti eikä paperien pyörittelyssä enää menekään viikkoa.

Eli: kyllä tapahtuu, varmasti.

Menikö ehdotus läpikin? Se oli ehkä ennemmin se mitä tarkoitin, steikkareilta voi kuulla ties mitä toiveita, mutta toivomuslaarista on matkaa toteutukseen.

 

[arcane]

Menikö ehdotus läpikin? Se oli ehkä ennemmin se mitä tarkoitin, steikkareilta voi kuulla ties mitä toiveita, mutta toivomuslaarista on matkaa toteutukseen.

On se spekseissä yhä kirjattuna, tämän osan toteutusta ei ole vielä aloitettu. On tossa tietynlainen perustelu takana muukin kuin ettei työntekijä saa näyttää liian tehokkaalta. Vaikea sanoa, mutta uskoisin että tällä on ihan potentiaalia päätyä sovellukseen asti.

 

[Karhu III]

Ymmärrätkö nyt, mistä on edes kyse? Tietysti se taulukko on välimuistin kannalta parempi, jos se pysyy muistissa samassa paikassa. Jos taulukon kokoa (solujen määrää) muutellaan, niin silloin koko taulukkoa saatetaan joutua siirtelemään sen kokoa kasvatettaessa, jolloin linkitetty lista on usein välimuistin kannalta se parempi tapa säilöä tietoa, koska linkitettyyn listaan uutta solua lisätessä se vanha olemassa ollut tieto pysyy samassa kohdassa muistia. Jos taas solujen määrä pysyy aina samana, niin silloin tietysti taulukko on itsestäänselvästi parempi ja tehokkaampi, eikä sellaisessa tilanteessa ainakaan toivottavasti tule kenellekään mieleenkään käyttää linkitettyä listaa.

Vaikka taulukkoa voi joutua siirtelemään sen koon kasvaessa, niin on se silti käytännössä nopeampi. Siirtoja isompaan joudutaan tekemään suhteellisen harvoin (jos ollenkaan), alkioiden lisääminen/poistaminen taulukon alussa on hitaampaa, mutta muut toiminnot ovat nopeampia. Erityisesti iterointi on linkitettyyn listaan verrattuna salaman nopeaa.

 

[Sompi]

Vaikka taulukkoa voi joutua siirtelemään sen koon kasvaessa, niin on se silti käytännössä nopeampi. Siirtoja isompaan joudutaan tekemään suhteellisen harvoin (jos ollenkaan), alkioiden lisääminen/poistaminen taulukon alussa on hitaampaa, mutta muut toiminnot ovat nopeampia. Erityisesti iterointi on linkitettyyn listaan verrattuna salaman nopeaa.

Tuohan nyt edelleenkin riippuu ihan käyttötapauksesta.

 

[Xiyng]

Sekä C:llä että rustilla on akilleen kantapäänsä, eikä rust todellakaan ole mikään ongelmaton ratkaisu olemassa olevien matalan tason kielten korvaajaksi. Rustin ympärillä pyörivän politiikan takia rust tuo projektiin vielä enemmän ongelmia kuin sen olisi teknisesti välttämätöntä tuoda. Rustin ympärille on myös kehittynyt uskonto, jonka teeseihin kuuluu hypettää rust-kieltä jonakin ihmeratkaisuna, joka poistaa kaikki bugit ja tietoturvaongelmat, ja se on ärsyttävää.

Linkitetty lista ei ole mitenkään erityisen tehoton ratkaisu, jos vaihtoehtona on muuttuvapituinen taulukko, jonka kokoa muutetaan usein ja jota saatetaan kokoa kasvatettaessa useinkin joutua siirtämään eri kohtaan muistissa, jos siihen vanhaan paikkaan ei kasvava taulukko enää mahdu. Toki C:llä on mahdollista tehdä molempia. Isojen struktien kanssa se linkitetty lista on parempi.

Linkitetyn listan tehottomuus ei perustu välimuistiepäoptimaalisuuteen, vaan siihen, että niitä pointtereita listan seuraaviin soluihin on hitaampaa seurata kuin vain ynnätä siihen taulukon alkupointteriin joku valmiiksi tunnettu luku. Sen takia linkitetyt listat monissa käyttötapauksissa linkitetään molempiin suuntiin. Isompien listojen kanssa saatetaan myös käyttää edistyneempiä hakualgoritmeja kuten punamustaa puuta, mutta silloin tietysti datan lisääminen listaan hidastuu - onko se sitten ongelma, riippuu käyttötapauksesta.

Itse asiassa taulukko, jota joudutaan siirtelemään muistissa usein eri kohtaan, on välimuistin kannalta paljon linkitettyä listaa epäoptimaalisempi vaihtoehto, ja usein siis myös kokonaisuudessaan hitaampi, koska nykyprosessorit ovat huomattavasti muistia nopeampia.

Väitetysti rustilla ei ole ollenkaan mahdollista tehdä kahteen suuntaan linkitettyä listaa. En osaa rust-kieltä, joten en tiedä, onko se totta. Nykyisellään rustissa kuitenkin on niin paljon ongelmia, että missään omassa projektissani se ei toimisi. Linuxin kaltaisessa portattavaksi tarkoitetussa käyttöjärjestelmäytimessä rustin merkittävin ongelma on portattavuuden puute, jota rustin nykyiset kehittäjät eivät edes haluakaan korjata, ja siksi itse peruskernelin tietokonearkkitehtuuririippumattomia osia ei voidakaan rustilla kirjoittaa miltään osin. Toisiksi merkittävin ongelma on sitten se, että monet asiat rustissa muuttuvat koko ajan toisenlaisiksi eikä mikään ole vakaata - ja tuosta syystä sen käyttö Linuxin moduuleissakin on kovassa vastatuulessa.

Perustan väitteeni muiden ratkaisujen paremmuudesta todennäköisesti jo vuosia sitten näkemiini mittauksiin tms., jotka varmaankin yrittivät parhaansa mukaan myös olla todenmukaisia. Toki todenmukaisia ja vertailukelpoisia mittauksia on usein vaikea suorittaa. Joka tapauksessa muut tuossa jo käsittelivätkin asiaa tarkemmin.

Kaksisuuntainen linkitetty lista Rustissa tulikin tuossa yllä jo käsiteltyä. Portattavuusongelmiin taas en ota kantaa, kun en niistä ole sen kummemmin perillä etkä itsekään anna hirveästi tarttumapintaa. Sitä taas en tiedä, mitä meinaat sillä, että Rustissa asiat muuttuvat jatkuvasti, koska aika vakaallehan tuo on minusta vaikuttanut. Uutta toki tulee eri tahtiin kuin C++:an, mutta käsittääkseni vanhaan ei kosketa varsinaisesti mitenkään suurella innolla juuri siksi, että ei rikottaisi muutoksilla mitään.