Raapustin C kielellä linuxille sellaisen yksinkertaisen "benchmark" ohjelman jossa kokonaisluvun arvoa lisätään yhdellä toistolauseessa.
kutakuin koodi on
i = 0;
while (i < 2700000)
i;
printf("%d ", i);
Kirjoitin koodin aluksi ikivanhalla läppärillä jossa 32 bittinen intel dualcore. Luvuksi asettui 2 700 000 koska sillä ohjelman suoritus kesti toivottu 10 sekuntia. Ohjelma siis ei tee muuta kuin lisää kokonaisluku i arvoa yhdellä kunnes sen arvo on tuo 2.7 miljoonaa, sekä tulostaa jokaisen luvun näytölle. Ajan ohjelmaa shell skriptin avulla jossa date komento kirjoittaa aikaleiman tekstitiedostoon ennen ohjelman suoritusta, sekä sen jälkeen, lopuksi aikaleimat tulostetaan cat komennolla.
Tein tismalleen saman ohjelman ja skriptin koneeseen jossa intel 64 bittinen i7 prosessori.
Tulos dualcorella on siis se 10 sekuntia, 64 bittinen i7.... 50 sekuntia!! MITEN!?
Käyttöjärjestelmä tismalleen sama Xubuntu LTS ja ihan tty terminaalissa ajan molemmissa koneissa. Järkeni ei riitä käsittämään miten tuollainen yksinkertainen ohjelma toimii 5 kertaa hitaammin 64 bittisessä i7 prosessorissa jossa kokonaisluvulle varattu bittimäärä on samat 4 bittiä!
Johtuuko hitaus prosessorista vai käyttöjärjestelmästä? Haluaako joku i7 omistaja kokeilla samaa Windowsilla, itselläni ei ole siihen mahdollisuutta. Ihan järjettömältä vaikuttaa.
64bit i7 hitaampi kuin 32bit dualcore?
22
395
Vastaukset
- johannytonmarkkinatt
siis kokonaisluvulle varattu tavuja 4 piti kirjoittaa
- 102030405060
Tuon printtikomennon takia tuo taitaa benchmarkata koko käyttöjärjestelmää, koska eikö siinä tule järjestelmä kutsu joka tulostuksella.
Ja kun tulee järjestelmäkutsu, niin käyttis saattaa vaihtaa jonkin toisen ohjelman ajoon sen jäljiltä.
Toisaalta samoinhan se toimii molemmilla koneilla, mutta voiko tuossa nyt vaikuttaa se mitä muita ohjemlia pyörii samaan aikaan. :/
Kokeile isompaa lukua ja ilman printtikomentoa, mutta pitääköhän siinä käyttää jotakin volatile sanaa, ettei kääntäjä optimoi koko looppia pois.
Vai oliko sinulla sitten tarkoituskin benchmarkata jotakin muuta kuin tuota itse luvun i pyöritystä.- 102030405060
Kokeilin Windows 10:ssä, Linux subsystemissä. Prossu 64 bittinen Core i7-2670QM.
Ja suoritusajaksi tuli time komennolla mitattuna 10.738s :
real 0m10.738s
user 0m0.766s
sys 0m1.172s
Mutta kuten tästä näkyy, user moodissa kului vain 0,766s koko suoritusajasta, eli tuo on se aika mikä prossulta meni tuota i lukua laskiessa ja print komentoa valmistellessa.
Sys kertoo, minkä ajan käyttöjärjestelmä oli kernel moodissa, eli tuo lienee järjestelmäkutsun aikana, että saadaan luku piirrettyä näytölle.
Real on sitten todellinien aika, jossa on mukana myös kaikkiin muihin tietokoneella samaan aikaan pyöriviin ohjelmiin kulunut aika, koska joka kierroksella printtikomennon jälkeen, käyttis todennäköisesti laittaa jonkun muun ohjelman ajoon.
Kokeile sinäkin ajaa time komento tuolle benchmarkille, niin näkyy mihin aikaa kului. ;) - 102030405060
102030405060 kirjoitti:
Kokeilin Windows 10:ssä, Linux subsystemissä. Prossu 64 bittinen Core i7-2670QM.
Ja suoritusajaksi tuli time komennolla mitattuna 10.738s :
real 0m10.738s
user 0m0.766s
sys 0m1.172s
Mutta kuten tästä näkyy, user moodissa kului vain 0,766s koko suoritusajasta, eli tuo on se aika mikä prossulta meni tuota i lukua laskiessa ja print komentoa valmistellessa.
Sys kertoo, minkä ajan käyttöjärjestelmä oli kernel moodissa, eli tuo lienee järjestelmäkutsun aikana, että saadaan luku piirrettyä näytölle.
Real on sitten todellinien aika, jossa on mukana myös kaikkiin muihin tietokoneella samaan aikaan pyöriviin ohjelmiin kulunut aika, koska joka kierroksella printtikomennon jälkeen, käyttis todennäköisesti laittaa jonkun muun ohjelman ajoon.
Kokeile sinäkin ajaa time komento tuolle benchmarkille, niin näkyy mihin aikaa kului. ;)Näköjään silläkin on eroa, minkälaisesta komentoikkunasta suorittaa, tavallisesta windows komentoikkunasta menee noin 8,5 s, powershell ikkunasta tuo vähän reilu 10 s.
Sitten jos pipettä koko tulostuksen tiedostoon, niin menee vain 1,2 s.
Eli tästä päätellen komentoriville tulostus on koko ketjun hitain palikka.
Voisiko siinä olla joku näytönpäivitystahti rajana. Ehkä se päivittää tuon komentorivinäytön jotakin tasaista tahtia, ja siis ohjelma olisi blokattuna aina seuraavaan näytön piirtoon asti. - JohanNytonmarkkinatt
Joo näin se ilmeisesti on. Muutin koodia huomattavasti yksinkertaisemmaksi, nyt
for (int i = 0; i >= 0; i);
ja ohjelma suorittuu ~10 sekunnissa dualcorella ja ~4 sekuntia i7 koneessa, sama kellottaako time vai date komennolla. En uskonut että tulostus voisi hidastaa ohjelman suoritusta niin pahasti. Jokatapauksessa lopputulema on että 64 bit Linux Bash tulostaa huomattavasti hitaammin kuin 32 bit, vaikea sanoa onko kyseessä bugi vaiko tarkoin harkittu ominaisuus.
- Puskurit
Kuten täällä on sanottu se johtuu siitä tulostamisesta. Tuo koodi minkä tuossa annoit ja joka oli eri mitä tekstissä kuvasit, kääntyy objdump:lla katsottuna:
while (i < 2700000)
i;
=>
40053e: 83 45 fc 01 addl $0x1,-0x4(%rbp)
400542: 81 7d fc df 32 29 00 cmpl $0x2932df,-0x4(%rbp)
400549: 7e f3 jle 40053e <main 0x18>
Tuo menee heittämällä 2 700 000 kertaa alle 100 millisekunnissa jopa alle 600 MHz prosessorilla. Ytimien määrällä ei ole merkitystä, sillä olet kirjoittanut ohjelman vain ydelle ytimelle. Eikä bittisyydellekään pitäisi olla mitään merktiystä jos "i" leveys on optimi kummalekin prosessorille.
Yleisellä tasolla nopeus erot aiheutuvat kello taajudesta (prosessorin ja muistin) ja välimuistista, mutta tässä tapauksessa siitä tuskin on kyse siitä (kuin korkeintaan välilliesti). Todennäköisesti joku muu prosessi syö sen toiseen koneen tehoja, tai sitten astukset (lähinnä puskurikoot) vain ovat niin paljon erinlaiset, jotta I7:lle tulee huomattavasti enemmän tyhjennettävää. Benchmark silmukka tulisi rakentaa riippumattomiksi käyttöjärjestelmän kutsuista, jos tarkoitus on mitata prosessorin nopeutta.- JohanNytonmarkkinattt
Niin toisaalta mikään ohjelma ei saa Linuxilta lupaa toimia riippumatta kutsuista. Kaikki ohjelmat toimivat ns. protected modessa jossain ring 3ssa ja vaikka assembly koodi kertookin rekisterit joita tiettävästi käytetään, niistä päättää lopulta käyttis ja prosessori itse. Ei siis ole mahdollista testata prosessoria real modessa tai protected mode ring nollassa, ellei kirjoita ohjelmaa joka toimii suoraan usb tikulta tai cdltä. Tietääkseni i7 joka on siis x86-64 arkkitehtuuria, käynnistyy edelleen real modessa. Dualcore 32 bittinen todistetusti käynnistyy real modessa, sen olen sillä testannut. Seuraavaksi kirjoitan ohjelman real modeen jolloin käyttis ei ainakaan ole välissä häiritsemässä.
Uskon itse että tämä huomattavasti hitaampi tulostus 10sek <> 50sek 64 bit Linuxissa on joko bugi tai harkittu ominaisuus, jonka syytä en ole keksinyt. Tarkoitus oli testata enimmäkseen prosessoria mutta, käyttistäkin. Testi lienee onnistui koska sen avulla selvisi asia jos toinenkin? - Puskurit
JohanNytonmarkkinattt kirjoitti:
Niin toisaalta mikään ohjelma ei saa Linuxilta lupaa toimia riippumatta kutsuista. Kaikki ohjelmat toimivat ns. protected modessa jossain ring 3ssa ja vaikka assembly koodi kertookin rekisterit joita tiettävästi käytetään, niistä päättää lopulta käyttis ja prosessori itse. Ei siis ole mahdollista testata prosessoria real modessa tai protected mode ring nollassa, ellei kirjoita ohjelmaa joka toimii suoraan usb tikulta tai cdltä. Tietääkseni i7 joka on siis x86-64 arkkitehtuuria, käynnistyy edelleen real modessa. Dualcore 32 bittinen todistetusti käynnistyy real modessa, sen olen sillä testannut. Seuraavaksi kirjoitan ohjelman real modeen jolloin käyttis ei ainakaan ole välissä häiritsemässä.
Uskon itse että tämä huomattavasti hitaampi tulostus 10sek <> 50sek 64 bit Linuxissa on joko bugi tai harkittu ominaisuus, jonka syytä en ole keksinyt. Tarkoitus oli testata enimmäkseen prosessoria mutta, käyttistäkin. Testi lienee onnistui koska sen avulla selvisi asia jos toinenkin?Tuosta sen verran, että jos haluat testata rautaa pitäisi tehdä erinlaisia testejä, eri tarkoituksiin. Rekisteri silmukka (jos unohtaa sen tulostuksen) mittaa lähinnä CPU:n kello taajuutta. Esim. muistin luku satunnaisiin osoitteisiin paljastaa paremmin muisti väylän nopeuden. Toisaalta järjestelminen luku laajalta alueelta paljastaa välimuistin vaikutuksen (tosin en tiedä onko välimuistille joku oma ohjain)...
Tuota 50 sek en pitäisi bugina, kun sulla kuitenkin oli se tulostus siinä. Vähän sama kuin kirjoittaisi tiedostoon 2700000 kertaa moi, moi.. Jos toisen ohjelman kirjoitus puskuri 1 kt ja toisen 3 Mt, niin erokin on helposti 100x. Ja vaikka puskurit olisi saman kokoisia, niin jos toisessa nopa SSD ja toisessa hidas ja pirstaloitunut HDD, niin 5x ero ei loppujen lopuksi ole kovin iso. Tuossa kun tulostat näytölle, kyse voi myös käänteisestä puskurista, eli mitä isompi rivi puskuri terminaalissa, sitä enemmän niitä tavuja siirrettävänä jotta saa yhdelle riville lisää tilaa. Pystyitkö varmistamaan että kaikki tuli terminaalin?
Joo testi oli onnistunut, sillä se paljasti erot.. - JohanMarkkinatNytOn
Puskurit kirjoitti:
Tuosta sen verran, että jos haluat testata rautaa pitäisi tehdä erinlaisia testejä, eri tarkoituksiin. Rekisteri silmukka (jos unohtaa sen tulostuksen) mittaa lähinnä CPU:n kello taajuutta. Esim. muistin luku satunnaisiin osoitteisiin paljastaa paremmin muisti väylän nopeuden. Toisaalta järjestelminen luku laajalta alueelta paljastaa välimuistin vaikutuksen (tosin en tiedä onko välimuistille joku oma ohjain)...
Tuota 50 sek en pitäisi bugina, kun sulla kuitenkin oli se tulostus siinä. Vähän sama kuin kirjoittaisi tiedostoon 2700000 kertaa moi, moi.. Jos toisen ohjelman kirjoitus puskuri 1 kt ja toisen 3 Mt, niin erokin on helposti 100x. Ja vaikka puskurit olisi saman kokoisia, niin jos toisessa nopa SSD ja toisessa hidas ja pirstaloitunut HDD, niin 5x ero ei loppujen lopuksi ole kovin iso. Tuossa kun tulostat näytölle, kyse voi myös käänteisestä puskurista, eli mitä isompi rivi puskuri terminaalissa, sitä enemmän niitä tavuja siirrettävänä jotta saa yhdelle riville lisää tilaa. Pystyitkö varmistamaan että kaikki tuli terminaalin?
Joo testi oli onnistunut, sillä se paljasti erot.."Rekisteri silmukka (jos unohtaa sen tulostuksen) mittaa lähinnä CPU:n kello taajuutta."
Näin olen ymmärtänyt itsekin. Osaatko sanoa onko kellotaajuus sama 8 bitin ja 64 bitin rekistereille? Itse olen siinä uskossa että mainostettu kellotaajuus on paras mahdollinen tehtaan mittaama, mutta toisaalta 64 bitin kirjoittamisen *pitäisi* viedä enemmän aikaa kuin 8 bitin. Sitä en osaa sanoa onko ero edes mitattavissa. En oikeastaan vieläkään tiedä kun en ole koskaan aiemmin real modessa testannut, onko mainostettu kellotaajuus mitattu pienimmän bittimäärän rekistereillä vai suurimman? Nykyiset prosessorit myös säätelevät omaa kellotaajuuttaan kuormituksen mukaan ja on niissä vaikka mitä hienoja uusia ominaisuuksia ja osaa ei aina edes dokumentoida kunnolla, joskus ei ollenkaan.
Tottakai välimuisti ja monet muut tekijät vaikuttavat prosessorin suorituskykyyn, mutta juuri siksi ihan mielenkiinnosta halusin tehdä tällaisen yksinkertaisen "benchmark" ohjelman C kielellä että oppisin juuri näitä asioita mitä tässäkin on nyt tullut ilmi.
Mielestäni prosessori pitäisi aina testata real modessa itse kirjoitetulla ohjelmalla, se toki vaatii arkkitehtuurin assembly kielen opiskelemista ja jossain määrin myös varsinaisen konekielen opettelua. Assemblystä konekielelle kääntävät kääntäjät ovat nykyään tosi hyviä, mutta kannattaahan se koodi aina tarkistaa varsinkin jos real modessa aikoo ajaa. C kielellä ohjelman voi tehdä kunhan tarkistaa konekielisen koodin että se tekee mitä pitääkin. Ymmärtääkseni real modessa prosessori käyttää niitä rekistereitä mitä koodi käskee, mutta en ole ihan varma asiasta. Jos esimerkiksi koodi käskee käyttämään 32 bittisiä rekistereitä arvolle joka on 64 bittiä, käyttääkö prosessori niitä 32 rekistereitä ja sitten "spill" muistiin vai osaako nykyiset prosessorit vaihtaa 64 bit rekisteriin jos niitä ei ole muuten varattu käyttöön? Onhan noissa kaikenlaisia muistia suojaavia ominaisuuksia ym. vaikka kuinka paljon. Kuuleman mukaan uusimmat prosessorit osaavat suojata itseään huonoa koodia vastaan. En sitten tiedä asiasta sen enempää pitää varmaan seuraavaksi alkaa opettelemaan intelin i7 manuaalia ja rekisteröityä asiantunteville palstoille.
Niinhän Linux sai alkunsa, kun Torvalds halusi opetella intel 386 prosessorin ominaisuuksia ja ne jotka silloin lukivat ensimmäisen julkaisun koodia oppivat nopeasti että C kieli voi olla myös osittain assemblyä...
Tämän olen itsekin huomannut. Ehkä se johtuu siitä, että 32bit koodi on karkeasti puolet lyhyempää ja ehkä siten suorittimelle / välimuisteille yms. nopeampaa liikutella ja prosessoida.
Riippunee kai aika lailla millainen ohjelma on kyseessä, ts. voiko se hyödyntää tehokkaammin 64-bittistä käskykantaa ja väyliä. Mutta arvailuja nämä vain- i_spell_potato
jos kirjoitat koodin
main(){
for(int i = 0; i >= 0; i );
}
niin sen pitäisi <time> komennolla kellottua nopeammin 64 i7 prossulla kuin 32 dualcorella. Tuo koodi kasvattaa kokonaisluku i:n arvoa yhdellä joka toistolla kunnes int pyörähtää negatiiviseksi. Int arvo ei voi olla unsigned tai sitten koodi pitää olla erilainen. Jos siihen toistolauseeseen sekoitetaan printf() niin 32 bittinen Linux suorittaa sen nopeammin. En osaa sanoa mistä johtuu. Mielenkiintoinen juttu tosin, pitäisi varmaan kysyä kernel.org palstalla. Itse veikkaan että johtuu jotenkin nice arvosta, joka hyvinkin on hitaammalla prosessorilla pienempi.
- f95
Kokeilin huvikseni tehdä 64-bittisellä Linuxilla Fortranilla saman testauksen. Ohjelman suoritusajat olivat tällaiset:
real 1m33.198s
user 0m5.851s
sys 0m10.782s
Tässä käyttämäni koodi:
program loop_benchmark
implicit none
integer :: i
i = 0
do while (i < 2700000)
write (*,*) i
i = i 1
end do
write (*,*) "valmis!"
end program- f95
Ja koneeni suoritin on vanha kolmiytiminen AMD Athlon II X3 455.
- laitteistoohjelmointi
Täysin laitteistokohtaista juttua joka vaihtuu aina jokainen päivä mitä prosessoreja kelläkin on eli... ei voi sanoa mitään vastausta, jos vastaus muuttuu jokainen päivä erilaiseksi.
- pelleajatfunktiosta
Ajan mittaaminen tuollaisissa on se joka aina tökkii, eli pitäisi käyttää stabiilia aikaa eli Real Time Clockia, ei mitään BIOS:n koodeja, vaan suoraan kiteeltä joka sykkii emolevyllä lukea se ajan mittaaminen :D
En usko että kovin paljon on merkitystä että onko ohjelmakoodi sitten miten intensiivisesti tehty 128/64/32 -bittisille prosessoreille, kun osaavat sen huomioida kuitenkin.
Ajan mittaaminen on se ratkaiseva asia, eli ei mitään normaalia tietokoneen aikaa, vaan suoraan pitää lukea emolevyn kristallista niitä REAL TIME -aikoja :D
Monesti selaimet ja kaikki cookiet sun muutkin sekoavat jos tietokoneen aika on väärin, joko 100 etuajassa tai jälkiajassa, eli oikeata aikaa mitata sitten eikä mitään "pelle"-aikaa jostain funktiosta. - 64bit-vs-32bit
Yksinkertaisissa laskutoimituksissa 32 bittinen on nopeampi kuin 64 bittinen, jonka hyödyt tulee esiin vasta moniajossa ja raskaissa laskentatehtävissä.
64 bittisen suorittimen arkkitehtuuri on paljon monimutkaisempi, kuin 32 bittisen, joten sillä mene kauemmin suorittaa yksinkertaista laskua. Jos olisit koodannut 10 laskutehtävää, ja laittanut suorittimet laskemaan niitä yhtäaikaa, 64 bittinen olisi ollu nopeampi.- riippuukuinlepakko
Voi olla sitten etuna jos käyttää pelkästään assembly-koodia ja näitä 256-bittisiä rekistereitä suoraan laskennassa, mutta siltikin ajan mittaaminen samalla laitteella mikä laskee sitä tehtävää on ongelmallista, ei ole kovin luotettavaa.
C kääntäjälle on hirmuinen määrä optioita. Onko käytetty samaa ohjelmaa vai käännetty erikseen 32 bittinen ja 64 bittinen versio? En nyt muista montako tavua integer tyyppi on ja muuttuuko kun ympäristö vaihtuu. printf suoritus joka kerta silmukassa tyhmää. joku muu kuin printf voi olla nopeampi. Laskutoimitus i = i 1 voidaan korvata i . Hyvin nopea laskutoimitus millä tahansa koneella. Sitä voisi laskea vaikka piin likiarvoa tai kertomaa.
Ja voihan sitä ajaa X:n alas ja ajaa ohjelma merkkipohjaisessa päätteessä. Nopeutta tulee varmaan lisää. Optimointi on ihan mielenkiintoista. Jos monimutkaisempi tehtävä esim Mandel brotin joukko erot alkaa kasvamaan.- piinviimeinendesimaali
Minulla oli kerran mielenkiintoinen idea, kun tein joskus sellaisen sovelluksen mikä muodosti graafisesti aurinkokuntia ja planeettoja, siis muodostamalla laskennallisesti niitä planeettoja kappaleiden muodostamista törmäyksistä mallintamalla planeetan muodonkin,
Entä jos laskisi tuollaista satunnaislukudataa tuollaiseen PII:n likiarvosta aina vain pidemmälle, tulisikohan joskus vastaan omaa aurinkokuntaa muistuttava vastaan :) Itse laskin aikoinaan fraktaaleja. Tein niin suuria suurennuksia mitä laskutarkkuus mahdollisti. 386 koneella kesti joskus vuorokaudenkin. Nykykoneella ohjelma ei valitettavasti toimi.
- laskevaanpäässä
Mielenvikainenhan laskee mitään fraktaaleja ja muitakaan millään muulla kuin suoraan grafiikkaprosessorin omilla rutiineillaan ja grafiikkaprosessorin muistissa.
Parhaan tehon saat kun lasket vain integer-luvuilla (olettaen että osaat laskea murtoluvut ja desimaalit kertoen integerejä)... mitään fast-fourieriakaan, hullukaan ei tee millään normaalilla desimaalilaskennalla, älä edes naurata :D:D
Ei riitä mitenkään laskentatehot vaikka olisi joku 128 coreinen Cray -supertietokone jos haluaisit täydellisen tuloksen ei sittenkään :D
Tietysti jos taskunpohjalta löytyy kolikoita ostaa kerrostalon kokoisia supertietokoneita, niin mikäs siinä :D laskevaanpäässä kirjoitti:
Mielenvikainenhan laskee mitään fraktaaleja ja muitakaan millään muulla kuin suoraan grafiikkaprosessorin omilla rutiineillaan ja grafiikkaprosessorin muistissa.
Parhaan tehon saat kun lasket vain integer-luvuilla (olettaen että osaat laskea murtoluvut ja desimaalit kertoen integerejä)... mitään fast-fourieriakaan, hullukaan ei tee millään normaalilla desimaalilaskennalla, älä edes naurata :D:D
Ei riitä mitenkään laskentatehot vaikka olisi joku 128 coreinen Cray -supertietokone jos haluaisit täydellisen tuloksen ei sittenkään :D
Tietysti jos taskunpohjalta löytyy kolikoita ostaa kerrostalon kokoisia supertietokoneita, niin mikäs siinä :DAjat ovat muuttuneet. Aikoinaan oli fraktaalit vähän muodissa ja Fractint laski niitä kokonaisluvuilla. piti vähän omaakin koodia kokeilla. Maailma on muuttunut noista ajoista. Nykykoneet laskee videoitakin kohtuullisessa ajassa. Löytyy tuubista. Hakusanaksi vaikka mandelbrot deep zoom
Ketjusta on poistettu 0 sääntöjenvastaista viestiä.
Luetuimmat keskustelut
- 904272
Onko jollakin navetassa kuolleita eläimiä
Onko totta mitä facebookissa kirjoitetaan että jonkun navetassa olisi kuolleita eläimiä? Mitä on tapahtunut?372495Minä en ala kenenkään perässä juoksemaan
Voin jopa rakastaa sinua ja kääntää silti tunteeni pois. Tunteetkin hälvenevät aikanaan, poissa silmistä poissa mielestä1042426Miksi olet riittämätön kaivatullesi?
Mistä asioista tunnet riittämättömyyden tunnetta kaipaamaasi ihmistä kohtaan? Miksi koet, että et olisi tarpeeksi hänell1062201Tiedän, että emme yritä mitään
Jos kohtaamme joskus ja tilaisuus on sopiva, voimme jutella jne. Mutta kumpikaan ei aio tehdä muuta konkreettista asian281927- 321925
Näin pitkästä aikaa unta sinusta
Oltiin yllättäen jossain julkisessa saunassa ja istuttiin vierekkäin, siellä oli muitakin. Pahoittelin jotain itsessäni91597- 291578
Aloitetaan puhtaalta pöydältä
Mukavaa iltaa mukaville. 😊 ❤️ ⚜️ Minusta ei kaikki täällä tykkää, eikä tarvitsekaan. Kun eivät ymmärrä, niin sitten ei1891575- 771366