(Nyky)softien hitaus

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.
 
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.
 
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.
 
Viimeksi muokattu:
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).
 
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:


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.
 
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.
 
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.
 
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.
 
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.
 
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.
 
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:

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.
 
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.
 
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 :hammer:

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.
 
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 :D Vaihtoon menee avatar, kunhan kerkiän.
 
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.
 
*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.
 
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ä. :rofl2:

Windows XP:ssä jollain single core paskeella paintin työkalut sentään aukesivat heti eikä se itse softakaan juuri sen kauemmin latautunut. :kahvi:
 
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ä.
zoom-2-11-24.png
 
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.
 
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...
 
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ä.
 
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.
 
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.
 
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?
 
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.
 
Viimeksi muokattu:
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.
 
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ä.
 
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 :rolleyes:
 
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 :rolleyes:

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.
 
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.
 
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.
 
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.
 
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.
 
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.
 
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.
 
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.
 
Mä olen koko ketjun alkuperäisestä väitteestä täysin eri mieltä. Musta osa nykysoftista on todella nopeita, osa "ihan ok" ja osa hitaita.
Raudan kehitykseen nähden, jotkut softat on aivan tautisen hitaita.

Otetaan vaikka MS Office. Joku Wordi tai Exceli avautui mielestäni paljon nopeammin office 2007-2016, kuin mitä nykyään 365.

Lisäksi monien valikoiden availu on tahmeaa.

Outlook on todella tahmea nykyään, varmaan joka maili pitää ladata joka kerta pilvestä kun plärää niitä läpi.

Teams on ihan älyttömän laginen.. keskusteluitakin pitää skrollatessa vissii ladata pilvestä kokoajan.. olis mulla levytilaa lokaali backupillekin.. meinaa joskus vähän onnetonta ilman internettiä, kun ois halunnu tarkistaa jotain.

VS2015-2019 (ja varmaan 2022) on hitaita vrt 2008 tai 2010.

2010 noita avattiin vielä pyörivältä levyltä. Kyllähän noi uudet pelittää ihan jees sitten kun kaikki on avattu.

Noita kun käyttäisi jollain 2008 aikasella PCllä, niin voisi olla ihmetystä..

Ehkä ongelma on joku pilvi synkkallu tai firman säädöt..

Koska softassa offline-sisältöä on tyyliiin ainoastaan asetukset.
Itse tekisin sovelluksen ainakin niin että sisällön lataus ei vaikuttaisi sovelluksen käynnistymiseen. Jonkunlaisen pääsivun voisi ladata ensin ja tehdä jonkunlaisen latausindikaattorin mistä selviää käyttäjälle että tietoja haetaan..


Mutta joo. Mitä oon aiheesta nähyt juttuja niin monesti on toistunut, että koodaajilta odotetaan ennemmin uusia ominaisuuksia, mitä sitten pitää esitellä aika tiuhaankin tahtiin sensijaan että nykyistä softaa tehtäisiin paremmaksi tai sitten niitä ominaisuuksia tehtäisiin huolellisemmin..
 
Raudan kehitykseen nähden, jotkut softat on aivan tautisen hitaita.

Otetaan vaikka MS Office. Joku Wordi tai Exceli avautui mielestäni paljon nopeammin office 2007-2016, kuin mitä nykyään 365.
Toimisto-ohjelmiin hyvä vertailukohta on esim. gnumeric. Sillä tekee monet perustaulukkolaskennat ja ainakin laskentataulukoiden selaamiset jos ei sitten kaikkia toimintoja. On aika hupaisa ero käynnistysajassa esim. LibreOfficeen tai MS Officeen verrattuna. Kannattaa kokeilla. Joo, kahdessa myöhemmin mainitussa on enemmän toimintoja, mutta mikä on se tietojenkäsittelytieteeseen pohjautuva perustelu, miksi niiden lisäominaisuuksien pitää hidastaa välittömästi jo ohjelman käynnistyksessä ennen kuin niillä tehdään mitään? Kompleksisuusanalyysin tunnillahan opetetaan, että O(0) on nopein nopeusluokka - eli esim. tehdään laiskasti asioita vasta kun niitä oikeasti tarvitaan.
Lisäksi monien valikoiden availu on tahmeaa.

Outlook on todella tahmea nykyään, varmaan joka maili pitää ladata joka kerta pilvestä kun plärää niitä läpi.

Teams on ihan älyttömän laginen.. keskusteluitakin pitää skrollatessa vissii ladata pilvestä kokoajan.. olis mulla levytilaa lokaali backupillekin.. meinaa joskus vähän onnetonta ilman internettiä, kun ois halunnu tarkistaa jotain.
Outlookin webbiversion verkkoliikennettä seuraamalla ainakin huomaa, että jokainen asia noudetaan erillisenä API-kutsuna ja verkosta riippuen lagia on esim. 150+ ms per pyyntö. Kun noita pyyntöjä on tusinan kerran, siitä tulee jo parin sekunnin odottelua. Yhdellä kootulla pyynnöllä säästäisi 90% ajassa, jos vaan palvelin jaksaisi.

Noiden videokonffaohjelmien hitauden huomaa, kun kaivaa jonkun vähän vanhemman läppärin käyttöön. Itsellä oli Intelin i5 7200U aika pitkään käytössä, muistia yli 16 gigaa ja olikohan 3. vai 4. gen PCIe SSD. Tuossahan on siis esim. raudalla QuickSyncin kautta täysi H264/H265/VP9-tuki. Joku videopuhelu pitäisi onnistua aika kivuttomasti, koska työn voi offloadata. Vertailun vuoksi joku valvontakameran RTSP-striimi dedikoidulla videosoittimella (VLC, mpv) ei kuluta juuri mitään. Zoomilla CPU-kuormat oli molemmilla coreilla jotain 65-75% kun kokouksessa puoli tusinaa ihmistä ja 1-2 piti kameraa päällä, itse en. Teams oli ihan käsittämättömän tahmea. Vähän sama kuin ajaisi jotain Windows XP:tä Pentium mmx:llä. Teamsissa varsinkin eri osioiden väliset siirtymät oli todella hitaita.

Nyt Ryzen 5950X:lläkin Teams tuntuu vähän tahmealta, mutta tiedän että pitäisi päivittää 9950X:ään jo Teamsinkin takia kun on vuosi 2025. Tai ehkä Threadripperiin tai EPYCiin. Pelithän noilla toimii ja kaikki geenidatan analyysit, mutta sellaisten toimisto-ohjelmien kanssa tekee tiukkaa, joita oli jo 80-luvulla 1-5 megahertsin koneissa.
 
Käytin äskettäin offline-tietokonetta joka oli säilytetty Windows 7 -versiossa erästä erikoistyökalua varten. Olipa virkistävää kun käynnistä-valikon haku löysi millisekunneissa ne mitä halusin sen etsivän, eli tietokoneelle asennetut ohjelmat. Ei ollut bing-hakutuloksia, säätä, office 365 -ja onedrive-pakotusta ja ties mitä turhuuksia mitä siellä nykyään on puolet lagisempana.

Yksi hidastuneista softista joka tulee mielee on Spotifyn Windows-versio. Ilmeisesti välimuistia ei ole musiikkivalikoiman selailuun ollenkaan ja ihan kaikki haetaan palvelimilta reaaliajassa pitkällä pilviviiveellä tai jotain muuta on vialla. En siis tarkoita musiikkitoiston bufferia/välimuistia vaan esim. artistin diskografian selaamista. Skrollaamisen tuntu on nopealla nykykoneella niin kuin näytön virkistystaajuus olisi 20 Hz ja joka asiassa on ärsyttävä viive. Olen tuota käyttäny yli kymmenen vuotta eikä vaikkapa vuonna 2015 ollut noin laginen peruskäyttö mitä on nyt.
 
Vähän kun teamsin chatin scrollaus. Joka skrollauksella lagia kun pitää aina hakee ne tekstit erikseen varmaan palvelimelta. Miksei vaikka latailis niitä muutaman sivua etukäteen ja kun alkaa skrollailla niin lataisi valmiiksi eteenpäin.

Toki parempi olis vaan tallentaa ne lokaalisti, jolloin niitä voisi selata vaikka ilman nettiyhteyttäkin.
 
Teams-chateista puheen ollen: en tiedä, onko omasta (työ)puhelimesta kiinni, mutta välillä kun chattaa ensin tietokoneelta käsin (olipa se sitten selaimella tai työpöytäsovelluksella) ja sen jälkeen tarkistaa saman chatin puhelimella, niin chatista saattaa puuttua osa kokonaan, eikä chatin rullailu ees taas tai sovelluksen sulkeminen ja/tai avaaminen uudelleenkaan tunnu korjaavan tuota. Ihana rikkinäinen puhelin-efekti - siis melko kirjaimellisesti.

(edit (22:09): typo)
 
Viimeksi muokattu:
Teams-chateista puheen ollen: en tiedä, onko omasta (työ)puhelimesta kiinni, mutta välillä kun chattaa ensin tietokoneelta käsin (olipa se sitten selaimella tai työpöytäsovelluksella) ja sen jälkeen tarkistaa saman chatin puhelimella, niin chatista saattaa puuttua osa kokonaan, eikä chatin rullailu ees taas tai sovelluksen sulkeminen ja/tai avaaminen uudelleenkaan tunnu korjaavan tuota. Ihana rikkinäinen puhelin-efekti - siis melko kirjaimellisesti.

(edit (22:09): typo)
Samaa käy joskus (ei kovin usein) minulle, kun käytän töissä kahta vierekkäistä pöytäkonetta, joissa molemmissa Teams.
 

Statistiikka

Viestiketjuista
275 159
Viestejä
4 746 759
Jäsenet
77 271
Uusin jäsen
Riverbonfiree

Hinta.fi

Back
Ylös Bottom