1. Onko nopeinta laskea muuttujia keskenään bitteinä vai kymmenjärjestelmällä?
2. Kuinka hidas kertolasku on yhteenlaskuun verrattuna?
Kiitos vastauksista etukäteen jos kommentointi kestää kauan
Darwen kirjoitti:
1. Onko nopeinta laskea muuttujia keskenään bitteinä vai kymmenjärjestelmällä?
No sehän riippuu ihan sinusta :)
Tietokone käyttää aina sitä binäärijärjestelmää. Ja jos kirjotat lähdekoodiin luvun desimaalina, se kyllä käännetään binääriksi, ennenkuin se menee prosessorille asti.
Darwen kirjoitti:
2. Kuinka hidas kertolasku on yhteenlaskuun verrattuna?
Ymmärtääkseni kertolasku palautuu useaksi yhteenlaskuksi. Molemmat on kuitenkin ollu viimisen kymmenen vuoden ajan ihan riittävän nopeita. Monimutkasemmat operaatiot (neliöjuuri) on sen sijaan edelleen varsin hitaita, ja niitä kannattaa välttää nopeuskrittiisissä paikoissa, jos vain voi.
Kiitos avartavasta vastauksesta Blaze :D
Blaze kirjoitti:
Tietokone käyttää aina sitä binäärijärjestelmää. Ja jos kirjotat lähdekoodiin luvun desimaalina, se kyllä käännetään binääriksi, ennenkuin se menee prosessorille asti.
Onhan noita kolmijärjestelmällä (jota kutsutaan yleensä trinääriksi tai ternääriksi) toimivia koneita kans ollu, äläs nyt valehtele siinä!
Blaze kirjoitti:
Ymmärtääkseni kertolasku palautuu useaksi yhteenlaskuksi. Molemmat on kuitenkin ollu viimisen kymmenen vuoden ajan ihan riittävän nopeita. Monimutkasemmat operaatiot (neliöjuuri) on sen sijaan edelleen varsin hitaita, ja niitä kannattaa välttää nopeuskrittiisissä paikoissa, jos vain voi.
En usko että esim. sadalla kertomista nyt kuitenkaan tehtäis sadalla yhteenlaskulla, menis aika hitaaks isoilla luvuilla.. prosessori tekee kai jotain hurjan jännähassuja taikatemppuja joilla se kertoo jotenki eri tavalla, vaikka saattaahan seki jonkulainen yhtenlaskukasa olla.
Neliöjuuria ja muita semmosia kantsii tosiaan välttää.
Joo kertolaskua ei tosiaankaan kannata palauttaa perusyhteenlaskuksi. Jopa ihan perustasolla bittejä shiftaamalla säästää todella paljon aikaa. Käytännössä nykyprossuissa on tosiaan kohtuullisen nopeat kertolaskuoperaatiot jotka voivat käyttää jopa piihin upotettuja aputaulukkoja yms, mutta jos joskus joudutte koodaamaan vaikka mikrokontrolleriin jossa ei ole kertolaskua raudassa oman kertolaskurutiinin, niin sitä ei kannata tehdä laskemalla lukua x yhteen y kertaa.
Eikä sitä neliöjuurtakaan kannata pahemmin pelätä. Nykyprossut kuitenkin suorittavat kymmeniä miljoonia neliöjuurioperaatioita sekunnissa.
Esimerkkinä Intel Core Duo prosessorissa erinäisten double precision liukulukuoperaatioiden Latencyt:
Yhteenlasku (FADD) 6
Kertolasku (FMUL) 8
Jakolasku (FDIV DP) 30
Neliöjuuri (FSQRT DP) 30
Eli kertolasku ei ole hirveästi hitaampi kuin yhteenlasku ja toisaalta neliöjuuri ei ole jakolaskua hitaampi.
Nopeudenhan voi mitata itse. Varmasti löytyy jokin ajanmittausoperaatio ja tarkkuutta voi lisätä toistamalla operaatiota silmukassa esim. miljoona kertaa. Mittaa ensin tyhjän silmukan nopeus. Lisää sitten silmukkaan haluamasi operaatio ja mittaa uudelleen. Erotuksena saat operaatioon kuluvan ajan kerrottuna silmukoiden määrällä.
setä kirjoitti:
Nopeudenhan voi mitata itse. Varmasti löytyy jokin ajanmittausoperaatio ja tarkkuutta voi lisätä toistamalla operaatiota silmukassa esim. miljoona kertaa. Mittaa ensin tyhjän silmukan nopeus. Lisää sitten silmukkaan haluamasi operaatio ja mittaa uudelleen. Erotuksena saat operaatioon kuluvan ajan kerrottuna silmukoiden määrällä.
Paitsi että mittaustuloksiin kannattaa suhtautua varauksella. Nykyisten prosessorien liukuhihna-arkkitehtuurin ansiosta prosessorin on mahdollista saada valmiiksi yksi plus-, kerto- tai jako-lasku kullakin kellojaksolla olettaen, että liukuhihnaa ei tarvitse pysäyttää hetkeksi odottamaan jotain muuta tulosta. Näinollen miljoona plus-, kerto ja jako-laskua menee läpi suunnilleen yhtä nopeasti, vaikka yksittäisen kertolaskun suorittamiseen menisikin esim. viisinkertainen aika.
En tiedä mistä Grez löysi noi arvot latensseille, mutta omien kokemusten mukaan parin kertolaskun poistaminen tiukasta Java-koodisilmukasta on toisinaan nopeuttanut koodia enemmän kuin tuo yksittäisen operaation 25% olettaisi. Varmaan tässä pitäisi huomioida se miten hyvin operaatiot sopivat prosessorin liukuhihnoille ja pitääkö jotain operaatiota odottaa.
Harvemmin tosin tulee vastaan tilanteita, jossa koodista pitäisi alkaa optimoimaan kertolaskuja pois. Kultainen sääntö onkin: älä optimoi, valitse pararempi algoritmi.
FooBat kirjoitti:
En tiedä mistä Grez löysi noi arvot latensseille, mutta omien kokemusten mukaan parin kertolaskun poistaminen tiukasta Java-koodisilmukasta on toisinaan nopeuttanut koodia enemmän kuin tuo yksittäisen operaation 25% olettaisi. Varmaan tässä pitäisi huomioida se miten hyvin operaatiot sopivat prosessorin liukuhihnoille ja pitääkö jotain operaatiota odottaa.
Ne on Intelin julkaisusta "Intel® 64 and IA-32 Architectures Optimization Reference Manual"
Kannattaa muistaa sekin, että Java ei ole yleensä suoraa konekoodia, eli ei voi tietää tarkasti mitä se virtuaalimasiina tekee siinä välissä. Lisäksi tietysti jos silmukassa on vaikka paljon kertolaskuja niin se kuormittaa kertolaskuyksikköä kun yhteenlaskuyksikkö on tyhjänpanttina, eli joskus on varmaan järkevää korvata kertolasku jollakin muulla. Ja jotkut kääntäjäthän optimoivat itsekin, esim. kokonaisluku * 256 voikin muuttua shiftaukseksi kahdeksalla ja luku * 2 voi muuttua luku + luku muotoon. Pointti nyt oli lähinnä että ei kannata yleisesti ottaen pelätä niitä kertolaskuja eikä edes välttämättä neliöjuuria.
tejeez kirjoitti:
Blaze kirjoitti:
Tietokone käyttää aina sitä binäärijärjestelmää. Ja jos kirjotat lähdekoodiin luvun desimaalina, se kyllä käännetään binääriksi, ennenkuin se menee prosessorille asti.
Onhan noita kolmijärjestelmällä (jota kutsutaan yleensä trinääriksi tai ternääriksi) toimivia koneita kans ollu, äläs nyt valehtele siinä!
Puhelintekniikassa käytetään kolmijärjestelmää vieläkin (-5v, 0v, +5v)
Aihe on jo aika vanha, joten et voi enää vastata siihen.