(Nyky)softien hitaus

[RandomUser859]

Ei tullut tämmöistä ketjua vielä vastaan, mutta olenko ainoa ketä häiritsee varsinkin modernien ohelmien/ohjelmistojen hitaus? Tuntuu, että mitä enemmän itse oppii ohjelmoimista ja prosessorien/koneiden sielunelämästä, niin sitä vähemmän sietää ohjelmia, jotka eivät käynnisty välittömästi, pitävät turhan päiväisiä taukoja kun klikkaat jotain yms. tai vaan syövät suhteettoman paljon RAM:ia/resursseja toimintaansa nähden?

Nykyprossut on niin tuhottoman nopeita, niin miksi ihmeessä esim, koodieditorin käynnistymisessä voi mennä se ~10s ja on mahdollista kirjoittaa nopeammin kuin editori kerkeää maalata fontteja näkyviin/pieni mutta havaittava viive jokaisen näppäinpainalluksella?? Mobiiliohjelmat/käyttiksen on sitten asia erikseen, jotka häiritsevät ihan jatkuvasti joka sekunti kun käyttää kännykkää mihin asiaan tahansa.

 

[root]

Electron-sovellukset nyt ainakin. On kerran jos toisenkin tuntunut, että resursseja imaistaan paljon. Toisaalta VS Code taitaa olla yksi näistä sovelluksista ja sitähän käyttää suuri joukko. Löytyy omaltakin koneelta.

 

[RandomUser859]

VS Code mulla olikin mielenpäällä kun aloituspostausta kirjoittelin, joskin moni ihan natiivisoftakin häiritsee. Paljon, paljon harvemmassa tuntuu olevan ohjelmat joita voisi kehua kuin haukkua tän asian suhteen.

 

[Paapaa]

Ei tullut tämmöistä ketjua vielä vastaan, mutta olenko ainoa ketä häiritsee varsinkin modernien ohelmien/ohjelmistojen hitaus? Tuntuu, että mitä enemmän itse oppii ohjelmoimista ja prosessorien/koneiden sielunelämästä, niin sitä vähemmän sietää ohjelmia, jotka eivät käynnisty välittömästi, pitävät turhan päiväisiä taukoja kun klikkaat jotain yms. tai vaan syövät suhteettoman paljon RAM:ia/resursseja toimintaansa nähden?

Nykyprossut on niin tuhottoman nopeita, niin miksi ihmeessä esim, koodieditorin käynnistymisessä voi mennä se ~10s ja on mahdollista kirjoittaa nopeammin kuin editori kerkeää maalata fontteja näkyviin/pieni mutta havaittava viive jokaisen näppäinpainalluksella?? Mobiiliohjelmat/käyttiksen on sitten asia erikseen, jotka häiritsevät ihan jatkuvasti joka sekunti kun käyttää kännykkää mihin asiaan tahansa.

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.

Jotta saataisiin tästä kunnon editorisota, niin mikä editori sinulla käynnistyy 10s ja joka piirtää kirjaimia hitaammin kuin kirjoitat? Varmaan hitaalla koneella tuokin on mahdollista. VSCode näköjään. Eli onko sinulla sitten todella hidas kone? Omalla M1 Prolla käyttö on salamannopeaa. Myöskään resurssien käyttö ei ole ongelma, sillä joka tapauksessa 32G:stä jää vaikka muille jakaa.

Tuottavuuden näköulmasta pidän joskus vähän outona tuota nopeuden tavoittelua. Suurimmassa osassa tapauksista se hidastava tekijä ei ole editorin perffi vaan joko se, että 1. käyttäjän aika menee ajatustyöhön eikä tekstin tuottamiseen (tämä kaikkein yleisintä itsellä, mutta riippuu mitä sillä editorilla tekee) tai 2. käyttäjä ei osaa käyttää editointia nopeuttavia komentoja. Väitän, että suurimmassa osassa se perffi on enemmän fiiliskysymys kuin että se oikeasti hidastaisi kenenkään tekstintuottamista. Tai koodaamista.

Mutta softakehityksen kannalta se perffi voi olla kompromissi. VSCode on esimerkiksi loistava esimerkki todella nopeasta Electron-softasta. Vastaesimerkki voisi olla Atom, joka oli kaikella tavalla tahmeampi käyttää. Itselläni VSCode on ns. täydellisen nopea eli suurin osa asioista tapahtuu ilman havaittavia viiveitä. Electron EI siis tarkoita automaattisesti hidasta, se voi olla myös todella nopea.

Miksi sitten Electron eikä natiivi? Siksi, että 1. Kehitystyö on nopeampaa 2. Taitavia kehittäjiä on paljon enemmän tarjolla, 3. mahdollistaa helpomman ja nopeamman UI:n toteuttamisen (korkean tason kieli, tutut webtekit käytössä). 4. Helppo tehdä alustariippumaton softa. 5. Aikaa jää enemmän itse softan ominaisuuksien kehittämiseen. Eli kehitystyö on halvempaa. Jne.

Jos tuon tekee ajatuksella, on lopputulos todella nopea kuten VSC. Ja toisaalta, kaiken voi tehdä paskasti. Myös sen natiivin.

 

[RandomUser859]

Ei nyt mikään maailman surkein kokoonpano (3950X, SATA2 SSD, 32GB RAM), mut kylmiltään (ei valmiina välimuistissa) kun tuplaklikkaa käyntiin niin helposti on se 10s tai enemmän ennenkuin workspace, syntax highlight, linteri yms toiminnassa ja editori responsiivinen sille, että jotain voi tehdä.

Eipä se mullakaan montaa kertaa päivässä käynnisty, ja ei ehkä ollut paras esimerkki aiheesta. *Kaikki* hitaus ärsyttää suunnattomasti, eritoten mainitsemasi käytönaikainen, ohjelmasta riippumatta. Ja juurikin tuo "1GB RAM tekstieditorilta on ihan ok" ajattelu on mun mielestä isona syynä siihen että mikään softa ei tunnu toimivan nopeasti vaikka kuinka päivittäis koneen kokoonpanoa (Wirth's law).

 

[tuskis]

Itse en voi kuin pelipuolen softia kommentoida, mutta siellä vaivaa sellainen tauti että hyvin vähän viitsitään yrittää optimoida mitään enää nykyaikana. Tuntuu että pelit vain lähinnä ns. brute forcetetaan toimimaan kera välillä järjettömän tuntuisten laitevaatimusten kautta, kyllähän pelaajilla tehoa piisaa varmaan miettivät. Vaan sitten kun ei coreja löydykkään 8 tai näytönohjaimessa giga tai kaksi liian vähän muistia niin mudassa juostaan.

Kenties sama vaivaa käyttösoftapuolta.

 

[Xiyng]

Harvaa varmaan kiinnostaa panostaa nopeuteen niin kauan kuin käyttäjät eivät valita liikaa. Työpanoksen voi käyttää muihinkin asioihin, joista voi olla paljon enemmän hyötyä ainakin jostakin näkökulmasta katsottuna. Valitettava tilannehan tämä on, mutta useimmat ohjelmistot toimivat silti riittävän nopeasti (eli silti laitteiden tehoon nähden turhauttavan hitaasti).

 

[Moilaps]

Softa puoli varmasti panostaisi perffiin jos se näkyisi liikevaihdossa. Mutta käyttäjät usein vaativat sovellukset ilmaiseksi ja vielä avoimella koodilla.

Hyvät optimoijat on todella harvassa työvoimasta, joten heidän työpanos kannattaa laittaa asioihin joissa suorituskyky näkyy liikevaihdossa eikä laittaa vscoden arkkitehtuuria kirjoittamaan uudestaan.

Vs code on minusta ihan riittävän nopea paitsi watch window debugatessa on ihan tuskaisen hidas joten sitä ei viitsi edes käyttää.

 

[Ctzn_no7]

VSCodessa varmaan se JS-pohjanen malli hidastaa, mutta se onkin varmaan valittu yhteensopivuuden takaamiseksi useammalla käyttiksellä.

Ohjelmistoissa yleensä paistaa se tehottomuus kun aletaan paljon tavaraa latoa taustalla, Eihän junnuille koulussa opeteta mitään fiinimpejä datan varastointimenetelmiä kuin "laita taulukkoon ja lue/etsi loopilla"

 

[Xiyng]

Ohjelmistoissa yleensä paistaa se tehottomuus kun aletaan paljon tavaraa latoa taustalla, Eihän junnuille koulussa opeteta mitään fiinimpejä datan varastointimenetelmiä kuin "laita taulukkoon ja lue/etsi loopilla"

Ehkä riippuu oppilaitoksestakin, mutta kyllä vain minulla on tullut opinnoissa vastaan runsaasti hienompiakin tietorakenteita. Itse syyttäisin pikemminkin aikataulupaineita, sillä välttävän hyvä on varmaan moneen hätään ihan riittävän hyvä, jos optimoinnin sijaan voi valita jonkin muun osa-alueen kehittämisen.

 

[Paapaa]

VSCodessa varmaan se JS-pohjanen malli hidastaa

VSCode on varsin huono esimerkki siitä, että "JS hidastaa". Musta se on esimerkki, että "JS ei hidasta kun sen tekee oikein". VSCode ei olisi niin suosittu editori niin harrastajien kuin ammattilaisten keskuudessa kuin se on, jos se olisi tahmainen editori.

Eihän junnuille koulussa opeteta mitään fiinimpejä datan varastointimenetelmiä kuin "laita taulukkoon ja lue/etsi loopilla"

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.

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.

 

[Ctzn_no7]

VSCode on varsin huono esimerkki siitä, että "JS hidastaa". Musta se on esimerkki, että "JS ei hidasta kun sen tekee oikein".

eihän se varmaan ole paperilla kuin nanosekuntin hitaampi per operaatio, mutta niistäkin saa nopeasti sekunnin tai kaksi aikaiseksi viivettä

Toki tuosta on pitkä matka käytäntöön.

Nimenomaan, koodin benchmarkkaus on pitkälti ns. "turhaa työtä" pelikehityksen ulkopuolella, eli ei mitään intressiä pistää sitä opittua tietoa koskaan käytäntöön.

osa nykysoftista on todella nopeita, osa "ihan ok" ja osa hitaita. Kuten on aina ennenkin ollut.

Hyvä noteeraus, sanotaan esim android kameraohjelman avaus onnistui 2-ydin lastulla 5 sekunnissa 10 vuotta sitten, miksi se kestää vieläkin 5 sekuntia vaikka on ydinmäärät ja kellotaajuudet ova nousseet moninkertaisiksi?
(Tätähän ketjussa luultavasti haettiin)

 

[Paapaa]

eihän se varmaan ole paperilla kuin nanosekuntin hitaampi per operaatio, mutta niistäkin saa nopeasti sekunnin tai kaksi aikaiseksi viivettä

Ei saa jos se softa on tehty järkevästi kuten VSCode. Tai saa jos se tehdään huonosti kuten Atom. Ja sitten kun se softa on tarpeeksi nopea, alkaa muut asiat painaa. VSCoden tapauksessa saadaan hämmentäviä hyötyjä siitä Electronista. Mene GitHubiin ja paina pistettä. Voila, siinä on editori selaimessa ja toimii aivan kuten työpöytäsovellus. Eipä onnistu Sublimella. Samoin saadaan helposti cross platform -softa.

(Ellei sitten puhuttu siitä käynnistysnopeudesta, jota kommentoin jo aiemmin. Mutta siinäkin VSCode käynnistyy 2 sekunnissa ja avaan sen tyypillisesti kerran päivässä. Tuo ei ole koskaan ongelma.)

Nimenomaan, koodin benchmarkkaus on pitkälti ns. "turhaa työtä" pelikehityksen ulkopuolella, eli ei mitään intressiä pistää sitä opittua tietoa koskaan käytäntöön.

Tuota en tarkoittanut. Benchmarkkaus voi olla hyvin järkevää pelinkehityksen ulkopuolella ja joskus saadaan valtava parannus perffiin napsimalla vain matalalla roikkuvat omenat. Mutta se vaatii sen, että joku pysähtyy hetkeksi siinä softatiimissä ja antaa aikaa sille perffille. Kartoitetaan ne hitaimmat asiat ja katsotaan mitä niille voi tai kannattaa tehdä. Ja toisaalta ei ole järkeä optimoida asioita, joita tehdään harvoin tai jotka jo ovat nopeita.

Hyvä noteeraus, sanotaan esim android kameraohjelman avaus onnistui 2-ydin lastulla 5 sekunnissa 10 vuotta sitten, miksi se kestää vieläkin 5 sekuntia vaikka on ydinmäärät ja kellotaajuudet ova nousseet moninkertaisiksi?
(Tätähän ketjussa luultavasti haettiin)

Aika huono esimerkki, sillä omalla Samsungin Android-luurilla kamera avautuu 0,5 sekunnissa siitä kun painan ikonia. Ei välitön, mutta 90% lyhyempi aika kuin mainitsemasi 5s. Ja tuo on niin nopea, että se ei enää haittaa käyttöä.

Eli musta näitä väitteitä ei voi heittää ihan hatusta, vaan kertoa tarkasti, mikä softa, millä laitteella jne.

 

[Griffin]

Onhan se täysin selvää, kun tehdään ohjelmisto epämääräisellä, pöhöttyneellä, tulkkaavalla kielellä, niin lopputulos on hidas
Toki jos piistä ja nykyisistä valmistusmenetelmistä ei päästä eroon, niin voipi olla ,että prossujen kehitys pikkuhiljaa ottaa ja pysähtyy, mitä tulee suorituskykyyn.
Se tosin ei ole mikään ongelma. Ohjelmistot on pöhöttyneet ja hidastuneet yli 30 vuotta, opetellaan vain uudestaan ohjelmoimaan tai tehdään homma tulevaisuudessa tarpeeksi fiksulla teköälyllä, niin suorituskyky on taas käytössä.

Kun katsoo kaikkia laitteita, niin jotenkin tuntuu, että insinöörien yleinen ongelmanratkaisukyky on kärsinyt pahaa eroosiota..

 

[JRan]

Onhan se täysin selvää, kun tehdään ohjelmisto epämääräisellä, pöhöttyneellä, tulkkaavalla kielellä, niin lopputulos on hidas

Juuri näin, tämä on se oikea syy hitauteen.

Ja juurikin tuo "1GB RAM tekstieditorilta on ihan ok" ajattelu on mun mielestä isona syynä siihen että mikään softa ei tunnu toimivan nopeasti vaikka kuinka päivittäis koneen kokoonpanoa (Wirth's law).

Toisaalta myöskin ajattelu, että RAMmia ei saisi käyttää on jotenkin erikoinen. Ilmeisesti iskostettu Windows käyttäjien johonkin aivolohkoon, että RAMmin käyttö on suorastaan vaarallista. Ja jos RAMmia on käytössä niin siitä pitää huolestua.

Kuulostaa siis erikoiselta, että sinulla on koneessa 32Gb RAMmia ja haluat, että sitä ei käytetä. Kuulostaa yhtä näppärältä kuin se että olet hankkinut 1Gb verkkokortin, mutta toivot, että data liikkuu vain 1Mb:n nopeudella. Tai omistat 8 ytimisen prossun ja haluat, että vain yksi ydin on käytössä. Tätä varten se RAM muisti on kehitetty, siis käytettäväksi ja nopeuttamaan asioita. Kuitenkin seuraavaksi nopein muisti prossun omien muistien jälkeen.

 

[Paapaa]

Juuri näin, tämä on se oikea syy hitauteen.

Veikkaan, että aika isossa osassa tapauksista valittu kieli ei ole se perimmäinen syy hitauteen. Tulkatut kielet ovat parhaimmillaan hämmentävän nopeita ja esim. V8 engine on todella tehokas optimoimaan suoritusta. Samoin ne kirjastot, jotka olisivat hitaita, koodataan osin jollain nopeammalla kielellä, kuten Numpy. Numpy on hyvin käytetty Python-kirjasto numeronmurskaamiseen ja ne paikat, jotka vaativat nopeutta on koodattu C:llä/C++:lla. Eli vaikka käytät näennäisesti pelkkää Pythonia, saatat käyttää samalla myös jotain muuta.

Isompi ongelma on se, miten ne ohjelmat koodataan. Esimerkiksi simppelin React Native -softan voi koodata hyvin helposti todella hitaaksi softaksi joka päivittää UI:n jokaisen mahdollisen komponentin jokaisessa tilamuutoksessa, vaikkei tarvitse. Tuossa ongelma ei ole kieli, vaan se, miten sitä Reactia käytetään. Eli ongelma ei ole työkalu, vaan se miten sitä heilutetaan. Tästä taas osoituksena Electron-pohjaiset softat, joista osa tuskaisen hitaita ja osa todella nopeita.

Toisaalta tämän koko keskustelun ongelma on täydellinen epämääräisyys. Heitetään ympäripyöreitä väitteitä softan hitaudesta niin, ettei kukaan tiedä mistä puhutaan tai mitä mitataan. Puhutaanko latausnopeudesta, käytönaikaisesta hitaudesta (mikä operaatio, missä tilanteessa), muistintarpeesta? Mitä laitetta ja ohjelmaa tarkoitetaan? Ja mitä tarkoittaa että joku on "hidas". Täysin mahdoton edes tunnustaa ongelmaa kun kukaan ei vaivaudu määrittelemään sitä. Selvästi ongelma EI koske kaikkia softia ja tilanteita, joten vähän toivoisi yritystä kuvailla niitä ongelmia.

Tuossa yllä joku heitti että kameran avaaminen kestää 5s Androidilla ja itse voin osoittaa että se kestää omalla Samppa-Androidillani n. 0.5s. Eli täysin tuulesta temmattu väite joka ei pitänyt paikkaansa yleisesti. Sitten näiden paikkansa pitämättömien väitteiden perusteella tehdään johtopäätöksiä että on kyllä helvetin hidasta... Vaikka ei edes ole.

 

[Griffin]

Kyllähän silloin, kun joku koodieditori tuntuu tahmaiselta tai käynnistyy hitaasti, jotain on todella pahasti vialla. Kyseessä on kuitenkin lopulta hyvinkin yksinkertainen ohjelma jonka ei pitäisi viedä juuri mitään resursseja siihen, että se käynnistetään tilaan, jossa voi aloittaa työskentelyn.

Se on suorastaan ihmeellistä, miten tietokoneiden suorituskyky on noussut kokoajan, 50 vuotta.. Silti aina saadaan kehitettyä paskempaa koodia ja perusasioitakin tekevät softat tahmovat vähäsen tai vievät esim naurettavan paljon muistia..

 

[█ █ █ █ █]

Musta on naurettavaa puhua softan nopeudesta/hitaudesta ja samalla mainita, että käytössä on yksi nopeimpia prosessoreita markkinoilla... Meillä ainakaan duunissa ei kaikille jaeta mitään M2 Macceja, vaan pitää pärjätä sillä i3/i5 8Gb ruoskaliisarilla. VSCode ja Teams ovat sellaisia ohjelmia, joiden tulisi pyöriä hyvin 15 vuotta vanhoilla ensimmäisen Core-sarjan Inteleillä...

Onneksi itse sain perusteltua Macin, vaikka vihaan itse platformia muuten yli kaiken. Mieluiten ottaisin toki nopean Windowslaitteen. En kirjoita koodia, mutta esimerkiksi Teamssia joutuu sietämään ja tällä se toimii edes siedettävästi. Kaipaan vanhaa Skypeä, kun se hoiti ne perustoiminnallisuudet helvetisti paljon paremmin.

 

[Paapaa]

Kyllähän silloin, kun joku koodieditori tuntuu tahmaiselta tai käynnistyy hitaasti, jotain on todella pahasti vialla. Kyseessä on kuitenkin lopulta hyvinkin yksinkertainen ohjelma jonka ei pitäisi viedä juuri mitään resursseja siihen, että se käynnistetään tilaan, jossa voi aloittaa työskentelyn.

Mikä editori siis on hidas ja millä tavalla ja millä laitteella? Mainittu VSC on mielestäni käytössä todella nopea ja avautuu itselläni 1-2 sekunnissa kuten mainitsin. En osaa kuvitella tarvetta 0,5 sekunnille kun tosiaan avaan sen editorin 0-1krt/päivä. Eli en luopuisi ominaisuuksista jotta tuota saisi lyhennettyä. Etänä terminaalissa sitten käytössä vim.

Ja millä perusteella "on kuitenkin lopulta hyvinkin yksinkertainen ohjelma"? Koodieditori on kaikkea muuta kuin yksinkertainen ohjelma, jos siltä haluaa muutakin kuin että voi lisäillä merkkejä tekstitiedostoon ja avata ja tallentaa tiedostoja. Ja yleensä haluaa.

• Tuki eri kielille LSP:n kautta
  • Auto completion
  • syntax highlight + teemoittaminen
  • goto definition
  • Viittausten listaaminen
  • Taju tyypeistä/luokista/metodeista
  • lintterituki
• Debuggeri
• Git-integraatio
• Integroitu terminaali
• Etäkäyttö/parikoodausominaisuudet
• Editointiominaisuudet (no shit...)
• Nopea haku- ja korvaustoiminnot (myös regex)
• Mahdollisuus kirjoittaa editoriin lisäpalikoita, kuten:
  • Prettier
  • SSH
  • GitLens
• Saavutettavuus
• Alustariippumattomuus
• Helppo kehitettävyys
• Jne.

Kaikki tämä ja silti tosiaan se 1-2 sekuntia ja yleensä nopea käyttö.

Se on suorastaan ihmeellistä, miten tietokoneiden suorituskyky on noussut kokoajan, 50 vuotta.. Silti aina saadaan kehitettyä paskempaa koodia ja perusasioitakin tekevät softat tahmovat vähäsen tai vievät esim naurettavan paljon muistia..

Mulla ainakin softat käynnistyvät nykyään nopeammin kuin 10v sitten, tekevät samassa ajassa enemmän ja toimivat huomattavasti nopeammin. Ehkä suurin yksittäinen harppaus oli SSD-joka romahdutti latausajat ja nopeuttu kirjoitusoperaatioita.

Nykyinen läppäri on siis valovuosia nopeampi ja käyttämäni softat myös. Sama koskee kännykkää, kaikki avautuu nopeammin, näytön käpistely on ripeämpää ja latenssit pienempiä. Toki esim. kodin netin nopeus on parantunut ja uudessa luurissa on 120Hz ruudunpäivitys joka lisää nopeudentuntua.

Joten en oikein osaa sanoa tarkemmin, mistä voi olla kyse. Ehkä käytämme ihan eri softia. Ja olisi parempi jos nimeäisit ne softat ja laitteet ja sitten voisi verrata, millaista kaikki oli 10-20v sitten ja kuinka kaikki oli paremmin.

 

[Paapaa]

Musta on naurettavaa puhua softan nopeudesta/hitaudesta ja samalla mainita, että käytössä on yksi nopeimpia prosessoreita markkinoilla...

Tämä oli varmaan mulle osoitettu? Käsitin, että juuri tästä oli kyse: nykyrauta on nopeampaa mutta väitetysti softa olisi hitaampaa ja paskempaa ja ennen kaikki oli paremmin kun kaikki tehtiin assemblyllä by tietäjät. Mulla näin ei ole, vaan softa tuntuu yleensä nopeammalta ja paremmalta - toki varmaan on poikkeuksia. M2-läppäriä ei ole, mutta M1 on kuten kirjoitin aiemmin.

 

[JRan]

Veikkaan, että aika isossa osassa tapauksista valittu kieli ei ole se perimmäinen syy hitauteen. Tulkatut kielet ovat parhaimmillaan hämmentävän nopeita ja esim. V8 engine on todella tehokas optimoimaan suoritusta. Samoin ne kirjastot, jotka olisivat hitaita, koodataan osin jollain nopeammalla kielellä, kuten Numpy. Numpy on hyvin käytetty Python-kirjasto numeronmurskaamiseen ja ne paikat, jotka vaativat nopeutta on koodattu C:llä/C++:lla. Eli vaikka käytät näennäisesti pelkkää Pythonia, saatat käyttää samalla myös jotain muuta.

Isompi ongelma on se, miten ne ohjelmat koodataan. Esimerkiksi simppelin React Native -softan voi koodata hyvin helposti todella hitaaksi softaksi joka päivittää UI:n jokaisen mahdollisen komponentin jokaisessa tilamuutoksessa, vaikkei tarvitse. Tuossa ongelma ei ole kieli, vaan se, miten sitä Reactia käytetään. Eli ongelma ei ole työkalu, vaan se miten sitä heilutetaan. Tästä taas osoituksena Electron-pohjaiset softat, joista osa tuskaisen hitaita ja osa todella nopeita.

Toisaalta tämän koko keskustelun ongelma on täydellinen epämääräisyys. Heitetään ympäripyöreitä väitteitä softan hitaudesta niin, ettei kukaan tiedä mistä puhutaan tai mitä mitataan. Puhutaanko latausnopeudesta, käytönaikaisesta hitaudesta (mikä operaatio, missä tilanteessa), muistintarpeesta? Mitä laitetta ja ohjelmaa tarkoitetaan? Ja mitä tarkoittaa että joku on "hidas". Täysin mahdoton edes tunnustaa ongelmaa kun kukaan ei vaivaudu määrittelemään sitä. Selvästi ongelma EI koske kaikkia softia ja tilanteita, joten vähän toivoisi yritystä kuvailla niitä ongelmia.

Tuossa yllä joku heitti että kameran avaaminen kestää 5s Androidilla ja itse voin osoittaa että se kestää omalla Samppa-Androidillani n. 0.5s. Eli täysin tuulesta temmattu väite joka ei pitänyt paikkaansa yleisesti. Sitten näiden paikkansa pitämättömien väitteiden perusteella tehdään johtopäätöksiä että on kyllä helvetin hidasta... Vaikka ei edes ole.

Kyllähän silloin, kun joku koodieditori tuntuu tahmaiselta tai käynnistyy hitaasti, jotain on todella pahasti vialla. Kyseessä on kuitenkin lopulta hyvinkin yksinkertainen ohjelma jonka ei pitäisi viedä juuri mitään resursseja siihen, että se käynnistetään tilaan, jossa voi aloittaa työskentelyn.

Latasin ihan testimielessä VSCoden ja jos käynnistän sen M2 Pro prossulla, niin onhan se oikeasti "hidas" käynnistymään verrattuna esimerkiksi VIM:iin, jota itse tulee käytettyä. Toisaalta ei sillä nyt oikeasti ole mitään merkitystä, jos editorin avaaminen ensimmäisen kerran kestää pari sekuntia vs se aukeaa välittömästi.

Mietin, että miten tätä hitautta voisi demonstroida ihan komentorivillä, mutta puhtailla tulkattavilla scripti-kielillä se on kohtuu vaikeaa nyky raudalla. Eli Perl, Python, PHP jne. Printtaa sen "Hello Worldin" näennäisesti yhtä nopeasti kuin käännetty C-koodi. Tämän "hitauden" pystyy ehkä osoittamaan jos printtaa Javalla "Hello world" vs C:llä "Hello world". Eli se hetki mikä menee siihen runtimen lataamiseen tuntuu yllättävän pitkältä. Toki jos teet tämän loopilla miljoona kertaa, niin eroa ei ole, kuin se hetki alussa.

Eli oikeasti tämä on turha keskustelu, ongelma on tosiaan täysin epämääräinen. Silti jokainen tulkattava kieli kärsii tästä vähän tai paljon, huonosti koodattu softa kärsii aina paljon. Saattaa kuitenkin olla kiva, että samaa koodia pystyy ajamaan useammilla alustoilla.

 

[pappatech]

Latasin ihan testimielessä VSCoden ja jos käynnistän sen M2 Pro prossulla, niin onhan se oikeasti "hidas" käynnistymään verrattuna esimerkiksi VIM:iin, jota itse tulee käytettyä. Toisaalta ei sillä nyt oikeasti ole mitään merkitystä, jos editorin avaaminen ensimmäisen kerran kestää pari sekuntia vs se aukeaa välittömästi.

VSCode on vielä kevyt johonkin Visual Studioon tai IntelliJ IDEA:an verrattuna, mutta kuten tuossa lainatussakin todettu, niin sillä ei tosiaan ole yhtään mitään merkitystä kauan se editori aamulla työpäivää startatessa kestää aueta, kun noi modernit editorit helpottaa ja nopeuttaa niin älyttömästi työskentelyä pitkässä juoksussa.

Henk. koht en vi:tä käytä kuin hyvin pieniin (skripti-, konfiguraatiotemplaatti yms.) muutoksiin ja useimmiten jonkun terminaaliyhteyden päästä. Aika sekaisin pitää olla, että tuommoisia isoja Java-projekteja, joiden parissa puuhaamisesta minäkin palkkani tällä hetkellä saan, alkais jollain vi:llä tai notepadilla pyörittelemään

 

[JRan]

Henk. koht en vi:tä käytä kuin hyvin pieniin (skripti-, konfiguraatiotemplaatti yms.) muutoksiin ja useimmiten jonkun terminaaliyhteyden päästä. Aika sekaisin pitää olla, että tuommoisia isoja Java-projekteja, joiden parissa puuhaamisesta minäkin palkkani tällä hetkellä saan, alkais jollain vi:llä tai notepadilla pyörittelemään

Itse kirjoittelen VI(M):llä pääasiassa PL/Perl:iä, PL/pgSQL:ää, SQL kyselyitä, erinäisiä shelli scriptejä, conffeja jne. Itse en ole 10 vuoteen Javaa käyttänyt mihinkään, mutta toki VIM myös taipuu Java IDE:ksikin. Vaatii toki vähän enemmän harrastuneisuutta (lue pakkomielteisyyttä).

 

[kolistelija]

Kuten tässä onkin jo mainittu, niin VSC on tosiaan jopa nopea kun vertaa muilla kielillä tehtyihin yhtä kattaviin editoreihin. Suurin osa Electron sovellusten hitaudesta tulee ihan yksinkertaisesti siitä että tehdään jotain tarpeettoman raskasta joka ei suoraan liity alustaan.

Esim. IDEA vetää välillä koodimuutoksen päälle mukavan indeksointikierroksen joka voi kestää minuutteja. Aina välillä koodaillaan ihan vain tyhmänä tekstieditorina koska indeksoinnin aikana kaikki avut ja jopa värit ovat pois päältä. Käynnistyskin on VSC:llä usein valmis siinä ajassa kun IDEA vielä piilottelee hitauttaan splash screenillä.

 

[vetten äärelle istutettu]

Olen miettinyt samaa.

Esim vuoden 2010 pc ssd:llä ja win7:lla. Kone käynnistyy jossain kolmessa sekunnissa käyttökuntoon, steamit ja muut auki myös välittömästi.

Vuosi 2017 kun viimeisen koneen ostin, meni samaan jo joku 30s mikä on sama verran kun aikama ennen ssd:tä. Tuo samainen n. 30s menee varmaan edelleeen, en koskaan sulje konetta nykyään.

Eli koodarit laiskoja paskoja kun ihmisillä on koneissaan resursseja käytettäväksi. Tämä samahan heijastuu kaikkeen softaan, myös peleihin. Kun ei tarvitse miettiä mitään niin luovassa jengissä on laiskojen lisäksi idiootteja.


Tässä tulos.

 

[Paapaa]

Eli koodarit laiskoja paskoja kun ihmisillä on resursseja käytettäväksi.

Laiskat paskat koodarit nopeuttivat Windows 8:a 7:aan verrattuna. Ja hidastivat Win 10:ä. Vertailukelpoisessa testissä kaikkien käynnistysajat olivat 4-6. Eli taas kerran: ei mitään käytännön eroa jos sen koneen käynnistää esim. kerran päivässä.

Laiskat ja paskat koodarit nopeuttivat Sleepiä 17s:stä 10s:iin kun verrataan Win 10:ä Win 7:aan. Eli noin 7s lyhyempi aika uudella laiskasti ja paskasti koodatulla Windowsilla. Hibernatessa sama suunta: uudempi oli nopeampi. Näiden merkitys sitten riippuu siitä, miten usein sitä konetta nukuttaa ja avaa. Läppärissä nopea Sleepistä herääminen on tärkeämpää kuin nopea käynnistys.

Windows 10 vs. Windows 8.1 vs. Windows 7 Performance

Windows 10 is put to the test to find out how it fares compared to Windows 7 and Windows 8.1 in various aspects of the operating system...

www.techspot.com

Ehkä on parempi jättää kommentoimatta ohjelmistotuotantoa jos kuvittelee että ainoa syy jonkun softan hidastumiselle on "laiskuus" ja "paskuus"

 

[vetten äärelle istutettu]

Laiskat paskat koodarit nopeuttivat Windows 8:a 7:aan verrattuna. Ja hidastivat Win 10:ä. Vertailukelpoisessa testissä kaikkien käynnistysajat olivat 4-6. Eli taas kerran: ei mitään käytännön eroa jos sen koneen käynnistää esim. kerran päivässä.

Laiskat ja paskat koodarit nopeuttivat Sleepiä 17s:stä 10s:iin kun verrataan Win 10:ä Win 7:aan. Eli noin 7s lyhyempi aika uudella laiskasti ja paskasti koodatulla Windowsilla. Hibernatessa sama suunta: uudempi oli nopeampi. Näiden merkitys sitten riippuu siitä, miten usein sitä konetta nukuttaa ja avaa. Läppärissä nopea Sleepistä herääminen on tärkeämpää kuin nopea käynnistys.

Windows 10 vs. Windows 8.1 vs. Windows 7 Performance

Windows 10 is put to the test to find out how it fares compared to Windows 7 and Windows 8.1 in various aspects of the operating system...

www.techspot.com

Ehkä on parempi jättää kommentoimatta ohjelmistotuotantoa jos kuvittelee että ainoa syy jonkun softan hidastumiselle on "laiskuus" ja "paskuus"

Win 10 nyt olikin julkaisuin tienoilla vielä (tapahtui muuten heinäkuussa 2015) ylivertaisen nopea käyttis. Mutta on hidastunut sittemmin ihan tuntuvasti. Ei sillä että itseäni enää jaksaisi kiinnostaa kun koko IT ala yhtä isoa kuplaa. Kunhan tulin trollaamaan tositapahtumiin perustuvalla skenaarioinnilla

 

[vetten äärelle istutettu]

Samahan se muuten on puhelinpuolella. Rauta on äärettömästi nopeampaa kuin vaikka 10v sitten. Asiat tapahtuu kuitenkin ihan yhtä hitaasti tai jopa hitaammin kuin silloin. Syyllinen ei ole ainakaan raudan heikkous. Kyllä se syyllinen on softan päässä ja se on ihan varma se.

 

[Paapaa]

Samahan se muuten on puhelinpuolella. Rauta on äärettömästi nopeampaa kuin vaikka 10v sitten. Asiat tapahtuu kuitenkin ihan yhtä hitaasti tai jopa hitaammin kuin silloin.

Tässä olisi kiva tietää, mitä puhelinta ja softaa tarkoitat. Mutta tuossahan juuri joku puhui kamerasovelluksesta, jonka aukeaminen kesti 5s vanhalla Android-luurilla. No, mun varsin nopealla S22+:lla oletuskamerasofta käynnistyy melko tarkkaan 0,5 sekunnissa. Aikaa menee 90% vähemmän. Ehkä tuo 5s oli liioittelua, mutta tuon perusteella samanlaiset softat aukeavat nykyään nopeammin.

 

[Aquarium]

Ajatus softatuotannon puolelta; rautaa eli resursseja on nykyään saatavilla riittävästi. Toki on prosesseja jotka on erittäin raskaita ja joita pyritään optimoimaan jotta esim. pilvessä säästettäisiin rahaa (pilvihän maksaa suoraan käytettyjen resurssien mukaan). Nopeutta tärkeämpää on kuitenkin laatu ja laatu on yhtä kuin virheettömyys. Virheettömyyteen pyritään selkeällä koodilla. Usein selkeä koodi ei ole kaikkein nopeinta mutta kun softaan halutaan vuoden päästä jokin muutos, on tärkeää että muutos ei riko mitään. Usein käy siten että softa toimii aivan riittävän nopeasti kunnes järjestelmään ajetaan vaikka täysin uudenlaista dataa tai tietyn datan määrä kasvaa reilusti. Tällöin havaitaan hidastumista ja jos se häiritsee, optimoidaan se kohta joka hidastuvuutta aiheuttaa.

Ei ole järkevää siis miettiä nopeusoptimointia kaikessa sovelluskehityksessä vaan tärkeämpää on että esim. kymmenien tuhansien käyttäjien pilvisofta toimii virheettömästi.

 

[Gandalf]

Ei tullut tämmöistä ketjua vielä vastaan, mutta olenko ainoa ketä häiritsee varsinkin modernien ohelmien/ohjelmistojen hitaus?

Ei ole tuntunut hitaalta.

Nykyprossut on niin tuhottoman nopeita, niin miksi ihmeessä esim, koodieditorin käynnistymisessä voi mennä se ~10s ja on mahdollista kirjoittaa nopeammin kuin editori kerkeää maalata fontteja näkyviin/pieni mutta havaittava viive jokaisen näppäinpainalluksella?? Mobiiliohjelmat/käyttiksen on sitten asia erikseen, jotka häiritsevät ihan jatkuvasti joka sekunti kun käyttää kännykkää mihin asiaan tahansa.

Voihan siellä olla jotain muutakin kuin prosessori, kuten vaikka IOPS:t.

VS Code mulla olikin mielenpäällä kun aloituspostausta kirjoittelin, joskin moni ihan natiivisoftakin häiritsee. Paljon, paljon harvemmassa tuntuu olevan ohjelmat joita voisi kehua kuin haukkua tän asian suhteen.

Sen vauhti on kiinni siitä paljon siinä on extensioita laitettu ja mitä ne tekevät. Kyllähän se nyt sekunnissa tai kahdessa pyörähtää käyntiin vanhallakin koneella.

 

[Gandalf]

Itse en voi kuin pelipuolen softia kommentoida, mutta siellä vaivaa sellainen tauti että hyvin vähän viitsitään yrittää optimoida mitään enää nykyaikana. Tuntuu että pelit vain lähinnä ns. brute forcetetaan toimimaan kera välillä järjettömän tuntuisten laitevaatimusten kautta, kyllähän pelaajilla tehoa piisaa varmaan miettivät.

Mielestäni pelimoottoreissa ja peleissä suorituskyky ei ole niinkään kiinni koodista vaan grafiikka-asseteista. Ne jos on tehty miten sattuu niin voi peli olla kyykyssä vaikka olisi minkälainen kone ja koodi.

Noin yksinkertaistettuna, GPU:t on suunniteltu niin että piirrettävän kolmion koko on minimissään 10 pikseliä. Kun menee hyvin pieneksi niin tulee ihan uskomattoman kovaa performance hittiä. Tarkemmat, pikseli tai alipikselitason geometriat on tarkoitus tehdä vaikka normal mappingilla. Sitten kun amatöörit tekemässä, että eivät ymmärrä miten GPU toimii niin tulee joku Cities: Skyline II pökäle.

Peleissä toki nykyään todella usein myös jännä design ratkaisu käyttää ns. viivästettyä renderöintiä. Tässä ajatus siis olisi, että saisi hillittömät määrät valonlähteitä pienemmällä laskentaresurssilla mutta oikeasti siellä näytönohjaimissa ei se laskenta ole ollut ongelma, yhden assetin (tai assetin osan) valaisua ei tarvitse tehdä yli kahdeksalla dynaamisella valolla ja tuo viivästetty renderöinti sen sijaan rohmuaa muistikaistaa, ja siinä on heikompi antialiasointi. Tämä on myös siinä siihen miksi peleissä on sitten nykyään niin paljon asetuksissa se temporal antialiasing (TAA) mikä lähinnä suttaa kuvaa.

 

[RandomUser859]

Hyvä varmaan jos ei tunnu samalta, mutta mua on kyllä nyppinyt siitä asti kun tein dipan reaaliaikaisesta simulaatiomallista, jonka aika-askel oli 1 ms ja koin hyvinkin konkreettisesti, että kuinka paljon hyödyllistä työtä kerkiää tekemään siinä ajassa. Eikä tarvinnut edes olla mikään erityinen ohjelmointiguru.

Käytännössä se, että pitää datatyypit ja algoritmit sellaisina jotka hyödyntää nykyisten prosessorien arkkitehtuuria riittää jo tosi pitkälle. Ihan muutama laskentalooppi piti vääntää SIMD:llä.



Ihan parina esimerkkinä mä muokkailen vapaa-ajallani yhden vanhan pelin lähdekoodia välillä ja siinä vihollisten vaara-alueiden näyttäminen on ollut tuskallisen hidasta ties kuinka kauan (peliin on lisätty asetus jolla voi säätää päivitysväliä ja se on ollut 500 ms oletuksena, koska se hidastaa muuten peliä turhan paljon). Pelkästään se muutos, että käydään näkyvän alueen laskenta vihollinen kerrallaan vs alkuperäinen, joka tarkistaa solu kerrallaan kaikkien vihollisten näkökenttää vastaan muutti sen sellaiseksi, että päivitys aika voi olla alle 100 ms eikä se enää hidasta peliä häiritsevästi. Ainoa muutos tuossa on se, että ei jatkuvasti haeta muistista dataa prossun välimuistiin, mikä siellä oli just hetki sitten. Okei, mä myöskin nostin parin raskaimman funktion tulokset ulos sisimmästä loopista, koska niitä pystyi uudellen käyttää mut silti muutokset oli minimaalisia.

Toinen esimerkki on pelin itemieditorin uudelleen kirjoitus mikä mulla on vaiheessa. Vanha editori lataa pelin xml filuista ja kuvista koostuvaa dataa mun koneen kokoonpanolla kirjaimellisesti useampia minuutteja. Mun softassa sama tapahtuu reilusti alle puolessa sekunnissa, joka on oikeasti edelleen aika hidasta.


Vähän samanlaisia ajatuksia löytyypi esim. tältä kaverilta, joka ei taida ihan onneton olla ohjelmoinnin kanssa

Why Modern Software is Slow–Windows Voice Recorder

I apologize for this title because there are many things that can make modern software slow. Blindly applying one explanation without a bit of investigation is the software equivalent of a cargo cu…

randomascii.wordpress.com

Arranging Invisible Icons in Quadratic Time

Near the end of January I was pointed to a twitter thread where a Windows user with a powerful machine was hitting random hangs in explorer. Lots of unscientific theories were being proposed. I don…

randomascii.wordpress.com

 

[Gandalf]

Hyvä varmaan jos ei tunnu samalta, mutta mua on kyllä nyppinyt siitä asti kun tein dipan reaaliaikaisesta simulaatiomallista, jonka aika-askel oli 1 ms ja koin hyvinkin konkreettisesti, että kuinka paljon hyödyllistä työtä kerkiää tekemään siinä ajassa. Eikä tarvinnut edes olla mikään erityinen ohjelmointiguru.

Ehtii toki. Vaatimushan usein on se, että kun klikkaa nappia niin saisi mielellään olla valmis ennen kuin sekunti kulunut.

Kannattaa myös huomioida se, että mihin se aika menee. Hyvin paljon softaa tehdään niin, että ei edes ole pahemmin looppeja tai ne ovat hyvin lyhyitä. Usein vaan reagoidaan eventteihin ja lähetetään viestejä. Se looppi sitten missä aikaa palaa voi olla oma palikkansa.

Käytännön ohjelmoinnissa ei normaalisti viilailla mitään millisekunteja. Ennemminkin ohjelmia tehdään niin siitä, että yritetään kirjoittaa koodi niin että olisi mahdollisimman helposti luettavissa toiselle työntekijälle mikä asiasta ei tiedä mitään, itselle 6kk kuluttua, ja niin että kone pystyy sen lukemaan.

Hyvin pitkään aikaan, tyyliin yli neljäänkymmeneen vuoteen, suorituskyky ei ole ole juuri koskaan mikään ongelma silloin kun softa on siististi kirjoitettu. Silloin kun toimii hitaasti niin silloin lähinnä tehdään jotain todella tyhmää. Laitteiden muistikapasiteetit, IO, tietoliikenneyhteys jne. rajanneet perinteisesti käsiteltävää dataa niin, että harvemmin on kiinni siitä mitä CPU tekee.

Ainoa muutos tuossa on se, että ei jatkuvasti haeta muistista dataa prossun välimuistiin, mikä siellä oli just hetki sitten. Okei, mä myöskin nostin parin raskaimman funktion tulokset ulos sisimmästä loopista, koska niitä pystyi uudellen käyttää mut silti muutokset oli minimaalisia.

Pelimoottoreiden arkkitehtuurissa ihan normaalisti joku thread pool ja siellä sitten tehtävien ajoa, että pitäisikin palastella asiat jotka menevät sinne pooliin käsiteltäväksi. Cacheen sopiva pala on juurikin sopiva.

Mielenkiintoista puuhaa tuo mitä teet mutta wanhojen pelien tapauksessa ensisijainen asia ei varmaan edes olisi optimointi vaan tehdä migraatiota pois legacystä, että pysyy ehjänä. Helposti melkoinen läjä deprekoituja kutsuja, puuttuvaa yhteensopivuutta ja jne.

Yleisesti ottaen keskittymällä koodin ylläpidettävyyden parantamiseen tekemällä siitä siistiä, parantaa vähän kaikkea muutakin. Kuten suorituskykyä, vähentää bugeja ja tietoturva-aukkoja, siirrettävyyttä ja jne.

 

[ississ]

Käytännön ohjelmoinnissa ei normaalisti viilailla mitään millisekunteja. Ennemminkin ohjelmia tehdään niin siitä, että yritetään kirjoittaa koodi niin että olisi mahdollisimman helposti luettavissa toiselle työntekijälle mikä asiasta ei tiedä mitään, itselle 6kk kuluttua, ja niin että kone pystyy sen lukemaan.

Tähän täytyy mainita poikkeuksena datamassojen käsittely, esim ETL tyyppistä hommaa tekevät ohjelmat.

Töissä näitä tulee vastaan jos pitää käsitellä vaikka 300M riviä jotain dataa niin varmasti optimoidaan ainakin jonkin verran koska muuten suoritusaika kasvaa liian pitkäksi.
Monesti luettavuus kärsii kyllä.
Ja kyllä, rinnakkasuus yms tietysti myös käytössä.

 

[Gandalf]

Ihan parina esimerkkinä mä muokkailen vapaa-ajallani yhden vanhan pelin lähdekoodia välillä

Mikäs peli muuten?

Ajattelin vaan että jos peli on niin hyvä, että motivoi koodastelemaan niin se voisi olla kiinnostava.

 

[RandomUser859]

Käytännön ohjelmoinnissa ei normaalisti viilailla mitään millisekunteja. Ennemminkin ohjelmia tehdään niin siitä, että yritetään kirjoittaa koodi niin että olisi mahdollisimman helposti luettavissa toiselle työntekijälle mikä asiasta ei tiedä mitään, itselle 6kk kuluttua, ja niin että kone pystyy sen lukemaan.

Juu ei tietenkään, mutta kun oltaisiin edes satojen millisekuntien luokassa eikä kymmenissä sekunneissa tai pahimmillaan minuuteissa. Meillä on duunissa PTC:n CAD softa käytössä ja mä oon parhaimmillaan kellon kanssa ajoittanut yli 2 minuutin taukoja missä koko softan UI on jumissa vain yhden kontekstimenun avaamisen vuoksi. Samanlaisia esimerkkejä löytyy vaikka kuinka paljon ja se mikä mua häiritsee on juurikin se, että kohtuullisen hyvän suorituskyvyn saavuttamiseen ei vaadita erikoisempia temppuja tai optimointia niin kuin se yleisesti tunnutaan ymmärrettävän, missä pitäisi mennä käsin kirjottamaan esim. SIMD intrinsic käskyillä jotain algoritmia.

Tyyliin sillä, että lukee seuraavat kirjat ja miettii miten data saadaan prossulle käsittelyyn sille sopivaan muotoon riittää lähes aina.

https://www.dataorienteddesign.com/dodbook.pdf <- Data oriented design - Richard Fabian (2018)
https://www.akkadia.org/drepper/cpumemory.pdf <- What Every Programmer Should Know About Memory - Ulrich Drepper (2007) Vanhahko kirja mut suurin osa siitä on edelleen ihan käyttökelposta infoo.

How much of ‘What Every Programmer Should Know About Memory’ is still valid?

I am wondering how much of Ulrich Drepper's What Every Programmer Should Know About Memory from 2007 is still valid. Also I could not find a newer version than 1.0 or an errata. (Also in PDF form on

stackoverflow.com

Mike Actonin vanha luento on kans ihan hyödyllinen kattoo läpi, jos tällainen kiinnostaa

Mielenkiintoista puuhaa tuo mitä teet mutta wanhojen pelien tapauksessa ensisijainen asia ei varmaan edes olisi optimointi vaan tehdä migraatiota pois legacystä, että pysyy ehjänä. Helposti melkoinen läjä deprekoituja kutsuja, puuttuvaa yhteensopivuutta ja jne.

Mikäs peli muuten?

Ajattelin vaan että jos peli on niin hyvä, että motivoi koodastelemaan niin se voisi olla kiinnostava.

Jagged Alliance 2 1.13 modi, löytyypi GitHub - 1dot13/source: Source code for the game executable of the Jagged Alliance 2 v1.13 project reposta.

Varoituksen sanana tosin, että jos on tottunut katselemaan siistiä koodia, niin tuo saattaa järkyttää herkimpiä. Alunperin koodattu C:llä / x86 assemblylla ja siihen lisänä ~20 vuotta eritasoisten modaajien C++ koodia. 2-3 tuhannen rivin funktiot on vielä pieniä ja niitä tulee vastaan jatkuvasti. Mä oon välillä miettiny, et tekisin ketjun mihin voisi kirjoitella parhaita paloja mitä on tullut vastaan koodia ihmetellessä.

Koodin siivoamistakin pyritään tekemään aina kun jotain osiota työstetään, mut siinä on hieman työsarkaa. Tää oli tulos kun ajoin lähdekoodin läpi scc:sta joku aika sitten.

 

[Gandalf]

Juu ei tietenkään, mutta kun oltaisiin edes satojen millisekuntien luokassa eikä kymmenissä sekunneissa tai pahimmillaan minuuteissa.

Tätä on tutkittu 60-luvulla jo.

Kun klikkaa jotain niin kokonaisvasteen pitäisi olla <1s. Sitten jos pyörittelee jotain että UI näyttää välittömästi kun säädellään niin kokonaisvasteen pitäisi olla <100ms. Yli sekunnin jutuissa pitäisi sitten laittaa jotain ilmaisemaan että nyt kestää, ja jos kestää yli 10s niin voisi näkyä joku palkki, ETA jne. että käyttäjä tietää lähteäkö kahville. Tuossa jutussa että jos homma kestää niin on hyvä miettiä näitä aikajänteitä, että tuleeko tehtävä valmiiksi kahvitauon aikana, tuleeko valmiiksi ruokatunnin aikana, jätetäänkö yön yli vai viikonlopuksi.

Meillä on duunissa PTC:n CAD softa käytössä ja mä oon parhaimmillaan kellon kanssa ajoittanut yli 2 minuutin taukoja missä koko softan UI on jumissa vain yhden kontekstimenun avaamisen vuoksi.

Tuo on paskaa, pitäisi olla <1s.

Samanlaisia esimerkkejä löytyy vaikka kuinka paljon ja se mikä mua häiritsee on juurikin se, että kohtuullisen hyvän suorituskyvyn saavuttamiseen ei vaadita erikoisempia temppuja tai optimointia niin kuin se yleisesti tunnutaan ymmärrettävän, missä pitäisi mennä käsin kirjottamaan esim. SIMD intrinsic käskyillä jotain algoritmia.

Niin, käytännössä jos kestää niin silloin likimain aina tehdään asioita jotenkin hölmösti. Laskennan hyötysuhde on kasvanut kaiken aikaa enemmän miten muistihaut toimivat, pullonkaula on muistikaista ja kun data nyt yleensäkin sopii muistiin niin se on se muistikaista siellä mikä kiinnostaa. CPU:sta se rauta ei oikeastaan ole riippuvainen mutta siellä vaan voidaan tehdä jotain todella hölmöä.

Varoituksen sanana tosin, että jos on tottunut katselemaan siistiä koodia, niin tuo saattaa järkyttää herkimpiä. Alunperin koodattu C:llä / x86 assemblylla ja siihen lisänä ~20 vuotta eritasoisten modaajien C++ koodia.

Mjoo tuo just sellaista että koodi ei oikeasti kaipaa yhtään optimointia vaan siistimistä, deprekoitujen asioiden päivittämistä, testien kirjoittamista, uudelleenkirjoittaa assemblyt vaikka C:llä, testailee buildausta eri alustoilla, refaktoroi niitä tuhansien rivien funktioita, kiristää vähitellen kaikenlaisten lintterien sääntöjä... Tekemällä koodista siistiä ne kaikki hölmöydet huomaa sieltä paremmin, bugeja lähtee tuhat pois, koodirivien määrä vähenee...

Pelien lähdekoodien näkeminen havainnollistaa sitä, että peliohjelmoijat eivät useinkaan ole erityisen hyviä ohjelmoijia.

 

[RandomUser859]

Mmm, mä en välttämättä menis heti sanomaan, että peliohjelmoijat olis huonoja taidoiltaan. Prioriteetit vaan on usein jotain ihan muuta kuin tehdä siistiä ja uudelleenkäytettävää koodia, kun moni peliprojekti tarvii saada valmiiks suht tiukkaan aikatauluun eikä sitä koodia välttämättä pääse hyödyntämään kunnolla seuraavassa projektissa. Näissäkin on tottakai paljon eroja ja jos kattoo esim. ID softwaren koodia vs Sir-tecin poikien käsialaa niin kylhän niissä laatu on ihan eri tasolla.

Tuo on paskaa, pitäisi olla <1s.

Juu niin on, eikä oo harmi kyllä mikään poikkeus. Siitä ärsytyksestähän tää koko ketju alkoi

 

[Paapaa]

moni peliprojekti tarvii saada valmiiks suht tiukkaan aikatauluun eikä sitä koodia välttämättä pääse hyödyntämään kunnolla seuraavassa projektissa

Tämähän se on se iso ongelma. Rajalliset resurssit. Kun joku asia on ns. riittävän hyvä, sen kanssa eletään ja mennään eteenpäin. Esim. se mainittu editorin käynnistys on 99,99%:lle ihan riittävän nopea, vaikka se kestäisi > 1s. Ja sen 0,01 %:n takia (jotka vaativat 0,1s käynnistysaikaa) en kannata uhrata optimointiin isoja summia tai uhrata niitä muita etuja joita se binäärin iso koko toi tullessaan (esim. Electron vs. joku natiivi toteutus). Kannattaa aina muistaa että softakehitys on kallista ja 100e/h on ihan normilaskutus yhden kehittäjän ajasta. Silloin se lopputulos ei ole taidoista vaan ajasta kiinni. Ja raha ei ole ainoa asia jonka suhteen pitää tehdä niitä kompromisseja.

Omien projektien kohdalla tilanne on toinen ja aikaa voi upottaa loputtomasti varsinkin jos nauttii harrastuksesta. Enkä tällä tarkoita, etteikö kannata käyttää vaivaa varsinkin matalalla roikkuvien hedelmien poimimiseen optimoinnin suhteen. Yleensä näin tehdäänkin.

 

[Gandalf]

Ja sen 0,01 %:n takia (jotka vaativat 0,1s käynnistysaikaa) en kannata uhrata optimointiin isoja summia tai uhrata niitä muita etuja joita se binäärin iso koko toi tullessaan (esim. Electron vs. joku natiivi toteutus).

Niin se Electron nyt on käytössä siksi, että ei tarvitse tehdä samaa softaa moneen kertaan.

Meillähän ei oikeasti ole olemassa mitään standardin tapaistakaan UI puolella mikä olisi käännetty natiiviksi.

Omien projektien kohdalla tilanne on toinen ja aikaa voi upottaa loputtomasti varsinkin jos nauttii harrastuksesta.

Toistaalta omissa projekteissa helposti vielä vähemmän resursseja käytössä, että sekään ei auta jos haluaa tehdä hyvää. Parempi valita käytettävät teknologiat fiksusti ja toimii niiden rajoissa ennen kuin alkaa syvemmälle pureutua optimoinneissa. Client puolen softassa se tarkoittaa käytännössä selainta ellei nyt oikeasti ole ostanut ja ole valmis ostamaan kaikki mahdolliset härvelit mille kääntää ja testaa. Lopputulos on sitten helposti parempi kuin joku natiiviksi käännetty pökäle joka ei toimi joka paikassa.

 

[huglo]

Microsoft Teams, tarvitseeko muuta sanoa.

Koodinikkareilla on heti selitykset valmiina kun joku kehtaa kritisoida nykysoftien performanssia. Näissä ketjuissa aina sama juttu.

 

[kolistelija]

Microsoft Teams, tarvitseeko muuta sanoa.

Koodinikkareilla on heti selitykset valmiina kun joku kehtaa kritisoida nykysoftien performanssia. Näissä ketjuissa aina sama juttu.

Teamsin viiveistä suurin osa taitaa tulla verkkoviiveistä. Lisäksi uusi versio on täynnä bugeja jotka jumittavat koko softan. Sehän on hauska että väittivät että uuden version pitäisi olla nopeampi kun siirtyivät electronista pois, vaikka oikeasti se taisi vain olla tekosyy rewritelle Angularista pois...

Itse olen tehnyt työkseni Electronia, eikä siinä ole mitään perusteellista ongelmaa miksi se olisi erityisen hidas ympäristö. Sovelluksen saa käyntiin reilusti alle sekunnissa jos ei tee mitään typerää käynnistyksessä ja käyttöliittymän saa kyllä päivittymään hienosti raskaissakin hommissa, kunhan heittaa romukoppaan monet modernit sovelluskehityksen teesit ja kirjastot. Suorituskykyinen koodi lähes poikkeuksetta vaikealukuisempaa ja monimutkaisempaa, eli sitä kannattaa usein jopa välttää ellei sille ole tarvetta.

On myös eri asia onko suorituskyky millään mittarilla priorisoitua. Väitän että suurin osa nykysoftista ei tee mitään missä suorituskyky on kriittistä, eikä se ole kehittämisen kannalta relevanttia.

Täällä mainittu VSCode on hyvä esimerkki siitä että softa on nopea, mutta ongelmia sillä tulee kun sillä ajetaan esim typescript palvelua tai muita analysointiplugareita. Samat ongelmat tulevat ihan kaikilla editoreilla kun vaaditaan samoja ominaisuuksia.

Webbisivuilla sitten taas nähdään kirjastoja kuten esim. Reactillr MaterialUi, joka on aivan käsittämättömän raskas. Toisaalta se tekee kehittämisestä todella paljon nopeampaa, eli halvempaa. Lisäksi tässä on tietenkin ongelmana että yllättävän suuri osa koodareista ei osaa itse tehdä laadukkaita korvaajia näillä kirjastoille, joten senkin kannalta on usein parempi käyttää toimivaksi tunnettua kirjastoa. Maksetaanko konsultille 3000 € napista joka ei välttämättä ole hyvä, vai ajetaanko npm install?

 

[Paapaa]

Koodinikkareilla on heti selitykset valmiina kun joku kehtaa kritisoida nykysoftien performanssia. Näissä ketjuissa aina sama juttu.

Olipa outo kommentti. Mikä perustelu tässä ketjussa sun mielestä on ollut siis virheellinen? Laita rohkeasti suora lainaus ja kerro miksi perustelu ei pidä paikkaansa. Onko susta siis huono asia, jos aiheesta keskustellaan ja tuodaan esille niitä syitä, miksi asiat ehkä on kuten ne ovat? Tai kyseenalaistetaan vertailua, jossa ei edes vertailla samanlaisia asioita? Lisäksi kokemukset hitaudesta ovat subjektiivisia. Ei tällä ketjulla ole mitään virkaa jos täällä vain listataan softien nimiä eikä mistään keskusteltaisi.

Hiukan nyt kyseenalaistan ton sun heittosi.

 

[Oksa]

Tässä olisi kiva tietää, mitä puhelinta ja softaa tarkoitat. Mutta tuossahan juuri joku puhui kamerasovelluksesta, jonka aukeaminen kesti 5s vanhalla Android-luurilla. No, mun varsin nopealla S22+:lla oletuskamerasofta käynnistyy melko tarkkaan 0,5 sekunnissa. Aikaa menee 90% vähemmän. Ehkä tuo 5s oli liioittelua, mutta tuon perusteella samanlaiset softat aukeavat nykyään nopeammin.

Lainaan vanhaa viestiä kun osui silmään asia mikä on itseä ihmetyttänyt jo pidemmän aikaa. Nykyiset puhelimet ovat todella nopeita ja pystyvät pyörittämään vaativia tekoälyasioita ja pelejä, mutta kaiken maailman S-Mobiili, OmaPosti, K-Ruoka jne. mielestäni lähinnä kotimaiset sovellukset käynnistyvät sekä lippulaiva-Samsungeilla että iPhonella jumalattoman hitaasti, useita sekunteja. Myös valikosta toiseen siirtyminen on joissakin tapauksissa hidasta. Eikö Suomessa osata ohjelmoida mobiilisovelluksia vai mitä nämä oikein touhuavat käynnistyessään?

Kellotin kokeeksi K-Ruoka -sovelluksen aukeamisen, 8 sekuntia painalluksesta siihen että alkunäkymä oli latautunut kokonaan.

Osa varmaan selittyy sillä että ottavat palvelimiin yhteyttä ja tarkistavat sieltä asioita, mutta ei tämänkään pitäisi nykyisillä yhteyksillä noin kauan kestää.

 

[emagdnim]

Kellotin kokeeksi K-Ruoka -sovelluksen aukeamisen, 8 sekuntia painalluksesta siihen että alkunäkymä oli latautunut kokonaan.

Jokunen sekunti meni. Parissa sekunnissa oli käytettävissä. e: iphone 12 pro max

Osa varmaan selittyy sillä että ottavat palvelimiin yhteyttä ja tarkistavat sieltä asioita, mutta ei tämänkään pitäisi nykyisillä yhteyksillä noin kauan kestää.

K-ruoka tapauksessa about koko sisältö latautuu palvelimilta, vähän kuin selainta käyttäisit. Kuitenki järkevästi, että ei blokkaa softaa muuten (odotellessaan sisällön latautumista). Voisihan se taustalla päivitellä valmiiksi, mut mikäs järki siinä olis akkua tuhlata ton appin kohdalla. Omaposti taas tuntuu kyl tosiaan melko kankeelta.

 

[Boromir]

En allekirjoitetta väitteitä nykysoftien hitaudesta. Ovatko kaikki unohtuneet muistot 90-luvulta, esim Windows 95/98 ajoilta kun koneiden käyttö oli tuskaisen tahmeaa. Officen, Photarin, selaimen tai minkä tahansa softan käynnistäminen ja niiden käyttäminen oli järkyttävän hidasta. Kokeilkaapa käyttää jotain retrokonetta sen ajan sovelluksia, kaikki on aivan järkyttävän hidasta.

Toki rauta oli silloin tehotonta, etenkin perinteiset kovalevyt hidastivat kaikkea. Softat tekivät huomattavasti vähemmän asioita mitä nykyään joten ei näitä ole hirveästi järkeä verrata, mutta yritetään. Otetaan nyt vaikka koodieditorit/IDE:t esimerkiksi: Eclipse vuodelta 2001/2002, kaikki modernit toiminnallisuudet puuttuvat ja oli hidas kuin mikä käyttää jos verrataan mihin tahansa moderniin IDE:n. Toinen hyvä esimerkki näistä on Office, nykyään käynnistyy 1-2 sekunnissa ja muinoin tässäkin taisi vierähtää 10 sekuntia.

En lähtisi merkittävästä hidastumisesta puhumaan tai huolestumaan kun koneiden/softien käyttö on joka vuosikymmenellä vain nopeutunut.

 

[Paapaa]

kaiken maailman S-Mobiili, OmaPosti, K-Ruoka jne. mielestäni lähinnä kotimaiset sovellukset käynnistyvät sekä lippulaiva-Samsungeilla että iPhonella jumalattoman hitaasti, useita sekunteja

Kellotin kokeeksi K-Ruoka -sovelluksen aukeamisen, 8 sekuntia painalluksesta siihen että alkunäkymä oli latautunut kokonaan.

Mulla näistä K-Ruoka ja OmaPosti käytössä. Puhelimena S24+ perusmalli ja nopeahko netti.

OmaPosti: Sovelluksen avaaminen välitön eli kesto vain avausanimaation verran. Sen jälkeen kun on lukenut sormenjäljen kestää noin sekunnin (arviolta 1-1.2s) että päänäkymä on ladattu ja piirretty. Koen tuon kaikella tavalla nopeaksi. Ja tuon kutsuminen "jumalattoman hitaaksi" on ihan käsittämätön kommentti joka ei päde ainakaan S24+:lla. Ja voin kohta kokeilla myös S22+:n.

K-Ruoka: ikonin klikkaamisesta 3s päästä päänäkymä on avattuna ja muu paitsi yläreunan pyöreät ikonit (Kaupan edut, Plussa-kortti...) on ladattu. 4s kohdalla myös ne on ladattu eli kaikki sisältö, käyttäjätiedot, edut, kauppatiedot sun muut on ladattu. Varmaan useasta eri lähteestä. Eli 3s kohdalla käytettävä, 4s kohdalla kaikki näkyvä on ladattu. Onko tuo 3-4s sitten kamalan hidas? Ei, muttei kovin nopeakaan. Tosin on iso ero, puhutaanko softista jotka säilövät kaiken offlinessa eivätkä tarvitse mitään netistä ladattavaa ja toisaalta ne jotka tarvitsevat. K-ruoka näyttää henkilökohtaisia etuja ja tarjouksia jotka voivat vaihdella varmaan jopa päivän sisällä, joten tietenkin sen pitää ladata tavaraa.

Ja oikeasti, jos se appin avaamisen parin sekunnin viive on noin kaamea ongelma, niin ei kannata sulkea sitä vaan jättää taustalle. K-Ruoka avautuu silloin välittömästi ja on heti käytettävissä. Käyttis osaa kyllä nukuttaa sitä eikä se syö resursseja.

 

[Oksa]

Ja oikeasti, jos se appin avaamisen parin sekunnin viive on noin kaamea ongelma, niin ei kannata sulkea sitä vaan jättää taustalle. K-Ruoka avautuu silloin välittömästi ja on heti käytettävissä. Käyttis osaa kyllä nukuttaa sitä eikä se syö resursseja.

Ei tämä ole mulle mikään oikea ongelma, mutta en vain ymmärrä miksi kestää suhteessa niin kauan, kun palvelimelta lataus huomioiden nykytekniikalla pitäisi kulua sekunteja paljon vähemmän.

Kokeilit ja raportoit ajat uusimmalla ja nopeimmalla puhelimella joka maksaa vajaa tuhat euroa. Mulla on pari sukupolvea vanhempi S22 käytössä niin testaa ihmeessä myös S22+:lla. Aika suurella osalla suomalaisista on käytössä joku 200-300 euron Android-laite niin sillä saa vielä muutaman ekstrasekunnin odotella alennuskuponkien latautumista.

Lisäksi myös @emagdnim koki OmaPostin käytön hitaaksi niin en ainakaan täysin yksin ole asian kanssa.

 

[emagdnim]

Lisäksi myös @emagdnim koki OmaPostin käytön hitaaksi niin en ainakaan täysin yksin ole asian kanssa.

Emmä sinänsä hitaaksi kokenut, mut jotenki kankeaksi.