Jos ne uudet käskykannat tekevät ohjelmista niin paljon tehokkaampia, niin miksi ohjelmistot kuitenkin hidastuvat koko ajan?
Pääosin koska
1) Niistä ohjelmista huomattava osa logiikasta on nykyään tehty jollain dynaamisesti tyypitetyllä ja pääosin tulkattavalla ja huonosti rinnakkaistuvalla kielellä kuten Python tai Javascript. Toki JIT-tai hotspot-käännökset niistäkin konekiellelle on jossain määrin mahdollisia, mutta dynaaminen tyypitys tekee siitä paljon tehottomampaa ja sitten tulee kuitenkin aina viive siitä ajonaikaisesta käännöksestä
2) Ohjelmat säilövät datansa ja konfiguraationsa nykyään usein todella tehottomiin ja hitaasti parsetettaviin formaatteihin kuten JSON tai XML. Aiemmin ohjelmien data säilöttiin joko binääriformaattehin jotka voitiin vaan lukea suoraan muistiin ilman mitään parsettamista, tai paljon JSONia ja XMLää yksinkertaisemman rakenteen omaaviin tekstitiedostoihin joiden lukeminen ja parsettaminen oli paljon näitä nopeampaa. Samoin netin yli kommunikaatiossa käytetään nykyään usein näitä samoja formaateja joten netin yli pitää siirtää moninkertainen määrä dataa.
3) Niissä ohjelmissa on nykyään enemmän kaikkea "hienoa" GUI- tauhtaa. Isompia ikoneita, hienompia väriliukuja, kaikki graafiset elementit on isompia (enemmän pikseleitä piirrettäväksi) jne.
4) Uudemmat GUI-kirjastot ovat bloatimpia. Niissä on enemmän keskitytty muuhun kuin suorituskykyyn, kun taas aiemmin oli pakko keskittyä suorituskykyyn.
Ihan oikeasti, tavallisessa työpöytäsoftassa ja käyttöjärjestelmäytimissä ei useimmista uusien käskykantojen käskyistä x86-alustalla ole yhtään mitään nopeushyötyä. Huomaa, että sinulla ei oikeasti ole syvempää ymmärrystä aiheesta.'
Suunnittelen prosessoriytimiä työkseni, että minulla on asiasta aika paljon enemmän syvällistä ymmärrystä kuin sinulla.
Olen hyvin paljon miettinyt ja simuloinut erilaisten käskykantalaajennosten vaikutusta ohjelmien suorituskykyyn.
Olen mm. tuijotellut kääntäjän tuottamia asm-koodeja, ja niitä tuijotellessani tajunnut, että tällainen uusi käsky olisi hyödyllinen, ja sitten toteuttanut käskyn prosessoriin (ja sen simulaattoriin) ja lisännyt kääntäjään tuen sille, ja sen jälkeen kääntänyt uusiksi ja ajanut kellojaksontarkassa simulaattorissa benchmarkit ja saanut niissä selvää nopeutusta.
Että melkoisen ylimielisiä kommentteja sinulta jälleen.
Tietoturvan ja koodin monimutkaisuuden kanssa asialla ei ole mitään tekemistä, koska ne ohjelmat kirjoitetaan korkeamman tason kielellä ja vasta kääntäjä kääntää ne konekieleksi, eikä kukaan ihminen kirjoita niitä konekäskyjä käsin. Kohdekäskykantaa voidaan muuttaa kääntäjän asetuksista.
Eli siis et ymmärtänyt ollenkaan lausetta, mihin vastasit. Tällä ei ole mitään tekemistä sen kanssa, että ihminen lukisi tai kirjoittaisi konekieltä käsin.
Pitää siis vääntää rautalangasta.
Jos ne uudet käskykantalaajennokset otetaan sieltä kääntäjän asetuksista käyttöön, se niillä asetuksilla käännetty koodi ei toimi vanhalla prossulla, joka niitä käskyjä ei tue.
Jotta voidaan saada sekä uudet käskykantalaakennokset käyttöön että softa toimimaan vanhoilla, niitä käskykantalaajennoksia tukevalla prossulla, pitää koodia kääntää kahteen kertaan. Ja sitten pitää olla valintamekanismi, joka valitsee näiden koodiversioden välillä. ja sitten tulee vastaan kysymys, että missä kohtaan tehdään se valinta. Käännetääkö kaikki koodi kahteen kertaan ja tehdään koko käyttiksestä kaksi täysin erillistä levityspakettia?
Käännetäänkö vain kriittiset innerloopit kahteen kertaan ja sitten ennen sinne kriittiseen innerlooppin menoa tehdään se valinta ja haarautuminen?
Miten saadaan kääntäjä generoimaan sama koodi kahteen kertaan ja lisäämään tämä valintakoodi? Ei mitenkään automaattisesti?
Käytännössä kääntäjä käsittelee pienimmillään funktiota, sitä pienempiin palasiin ei saada eri asetuksia käyttöön.
Eli, tehdäänkö tämä valinta funktiokohtaisesti? Kutsutaan funktioita funktiopointterin kautta ja asetetaan funktiopointteri sen mukaan, onko uudet käskyt tuettu vai ei?
Vai tehdäänkö DLL:stä kahdet versiot? toinen käyttää uusia käskyjä, toinen ei, ja valinta koodipolkujen tehdään DLLää ladatessa?
Kaikissa näissä homma monimutkaistuu ja koodin koko kasvaa. Aina on riski, että jotain jää testaamatta ja aina kun koodi monimutkaistuu, lisääntyy todennäköisyys, että sinne jää myös tietoturvaongelmia. Esim. sen funktiopointteirn pystyy ylikirjoittamaan kun joku datapuskuri ylivuotaa tms. ja jos sitä funktiopointteria ei olisi, ei se sama datapuskurin ylivuoto ei saisi mitään haitallista aikaan tms.
Ei pidä paikkaansa. Sinä et ymmärrä, miten valtavasti Pentium II:ssa on laskentakapasiteettia.
Voisitko opetella lukemaan lauseen johon vastaat sen sijaan että olkiukkoilet typeriä?
En puhunut mitään sen Pentium 2n tehoista, vaan niistä muista komponteista jotka yleensä löytyy koneesta jossa on niin antiikkinen prossu kuin pentium 2.
Esim. nykyiset graffa-frameworkit taitavat kunnolla toimiakseen vaatia GPUn jossa unified shaderit (jotka tulivat n. 2007), (nVidialta vähintään Tesla-arkkitehtuuri eli geforce 8000-sarja, ATI:lta Terascale-arkkitehtuuri (Radeon HD2000 eteenpäin), Intel GMA X3000)
Ja missään Pentium 2-koneissa ei ole sellaista määrää muistia että se alkuunkaan riittäisi moderneille windows-versioille.
Useimmat Pentium 2-emolevyt tukivat maksimissaan vain puolta gigaa muistia. Ja se puoli gigaa on auttamattomasti liian vähän.
Ja niiillä harvinaisilla emolevyillä, jotka tukivat suurempaa määrää muistia, sen yli puolen gigan käyttäminen oli joka tapauksessa useimmilla pentium 2-malleilla hidasta, koska alun perin Pentium 2:n välimuistin kirjainpito oli mitoitettu tukemaan vain puolta gigaa muistia; osoitteille, jotka menivät tämän yli, ei L2-välimuisti ollut käytössä. Tosin joku viimeinen stepping omasi suuremman kirjanpidon ja sen välimuisti toimi 4 gigaan asti.
Tässä vielä uudestaan tuo lauseeni tuosta edellisestä viestistäni:
hkultala sanoi:
Niin, mutta tietokoneessa on paljon muutakin kuin prosessori. Kaikissa niissä muinaisissa pentium II-koneissa kaikki muut komponentit on totaalisen vanhentuneita ja alitehoisia sille uudelle windowsille.
Mutta, jos mennään siihen Pentium 2n suorituskykyyn niin ymmärrän sitäkin aika paljon sinua paremmin.
Mikäli esim. lasketaan raakojen laskutoimitusten määrää aikayksikköä kohden, niin siinä Pentium 2:ssa on yli sata kertaa vähemmän raakaa laskentanopeutta kuin siinä n. nuppineulanpään kokoisessa prosessoriytimessä, jonka pääsuunnittelija olen itse ollut.
Mutta ymmärrän myös sen, että keskimääräisen softan suorituskyvyssä ero on paljon pienempi.
Ymmärrän myös sen Pentium 2:n käskyjen uudelleenjärjestelylogiikan toimintaperiaatteen, sen Pentium 2:n välimuistikoherenssiprotokollan toimintaperiaatteen, sen Pentium 2:n L1D-välimuistin VIPT-välimuistin toimintaperiaatteen, yhteyden virtuaalimuistin sivukokoon ja merkityksen suorituskyvylle, yms. ziljoona teknistä asiaa siitä joita sinä et ymmärrä.
yhteiso.telia.fi
Onhan tuota ihan viihdyttävää lukea, ei siinä mitään 
Aina vain paranee nämä "viisaudet".
