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.
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.
Vastaukset 56
Vanhimmat
siis tavun koko 4 tavua, piti sanomani
Äh. Kokonaisluvulle varattu 4 tavua molemmissa.
Ei varmuudella sanoen pidä paikkaansa. 64bit ympäristö ei tuota eto silmukkaa pyöritä kuin vajaat 2 sekuntia. mitähän muuta lienet sössinyt.
Kokonaisluvulle+(int)+varatun+tavun+koon+saa+selville+printf("%d",+sizeof(int));
Ilman tuota tulostusta aika on 0.015 sekuntia, revippä siitä, sähläri.
Niin? Ilman sitä tulostusta. Sen tiesinkin jo, kiitosta vaan "avusta". Korjataanko me nykyään kaikki käyttöjärjestelmän bugit niin että muutetaan kaikkien ohjelmien koodia??
No, nyt koodi on
int i = 0;
while(i < 2147483647)
i;
ja se kellottuu 3.86 sekunnissa i7 3.8GHz Xubuntu Linux 64.
Voisit käydä testaamassa onlinekääntäjällä tuota tekemääni koodia, jossa on mukana myös ajanotto: http://tpcg.io/hoWTU1
Muuttele lukuja mielesi mukaan. ja huomaa onlinekääntäjä on selvästi hitaampi kuin tämä oma koneeni.
Huomaa nyt helvetissä tuo int tyyppinen muuttuja on vai 16 bittinen, silmukkasi ylittää sen reippaasti, joten se on viallinen.
8 bittinen luku 0-265
16 bittinen 256 x 256
Kato siitä esimerkistä mikä siinä pitää oikeesti olla.
Noinko testaat ohjelmiasi? Hah hah.
En varmasti, mutta muuten ei noita jästipäitä saa ymmärtämään yhtään mitään.
Mutta toisaalta mikäs tuossa on vikana, sopii tähän tapaukseen pirun hyvin.
Huomaa minä olen ammattilainen, ja kannattaa ottaa opiksi jos rahkeet siihen riittää.
Eihän teistä kukaan pystynyt edes tuohon, joten Hah hah vaan itelles.
Mistäs se juho sai päähänsä että minä tuossa ohjelmaa testaan, teitä tahvojahan minä yritän opettaa.
Yrität opettaa vääriä lukuja. On ihan yleistä tietoa että suurin POSIX int = 2147483647. Linux on POSIX yhteensopiva ollut aina. Laitoinhan jo linkin tästä? https://en.wikipedia.org/wiki/Unix_time
Linux on ollut 32 bittinen alusta asti. Linuxissa max int = 2147483647. Unsigned int = 4294967294.
Microsoft trollit pysykööt pois palstalta. Teidän koodaustaidot tiedetään vuosien kokemuksella.
Mitäs vittua se tähän nuo POSIX liittyy, kun rajat antaa c -kieli ja sen muuttujat. POSIX saa olla mitä ikinä onkaan. Kyllä näyttää olevan lapsosella kasvojen menetys kova paikka, olisit tutustunut asiaan ensin, siinä käy näin kun rupeaa sähläämään puuta heinään.
Paraskin tietäjä, se on kuule parempi kun alat nöyrtymään parempies edessä, tai pysyt yhtä tyhmänä koko ikäsi.
"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ä!"
Nyt kun tätä keskustelua on jo käytä vähän matkaa, en yhtään ihmettele jos sinun järkesi ei riitä käsittämään yhtään mitään. C kieli ei onnistu sellaisella menttaliteetilla että, tee mitä teet Jeesus hoitaa loput.
C kieli ei määrittele datatyyppien kokoa. Linuxissa (x86 ja AMD64) int on ollut aina 32 bittiä. Se liittyy nimenomaan POSIX standardiin.
https://usrmisc.wordpress.com/2012/12/27/integer-sizes-in-c-on-32-bit-and-64-bit-linux/
Eikö tällä palstalla kukaan tiedä mitään? Pelkkiä Microsoft trolleja jotka pyytävät testaamaan koodia websovelluksilla koska eivät edes Linuxia osaa käyttää.
"Nyt kun tätä keskustelua on jo käytä vähän matkaa, en yhtään ihmettele jos sinun järkesi ei riitä käsittämään yhtään mitään."
Korjasin ongelman itse ennen kun sinä aloit täällä vaahtoamaan. Oletko ihan aito Microsoft koodaaja? Vuosien kokemus purkkakoodista antaa valtuudet aukoa päätä Linux ja Unix koodaajille jotka tietävät mitä tekevät? Sinä kun olet ilmeisesti varannut koodillasi 64 bittiä (long int) kaikille 32 bittiin (int) mahtuville kokonaisluvuille tähän asti, niin saatat positiivisesti yllättyä kun vaihdat purkkakoodisi long int muuttujat int tyyppisiksi. Ohjelmasi vievät siten vähemmän muistia ja toimivat muutenkin nopeammin.
Mikähän mahto olla prossun kellotaajuus?
tarkoitatko tehtaan ilmoittamaa? 3.40 GHz
Lisätään tähän nyt vielä kaiken sekoilun päätteeksi, että tavun koko on määritelty Linuxissa siten että 1 tavu on 8 bittiä joten 4 tavua on siis 32 bittiä. Kun ohjelma käyttää int tyyppistä muuttujaa, sen koko on 32 bittiä ja näin samaa ohjelmaa voi verrata kohtuullisen reilusti sekä 32 bittisessä että 64 bittisessä koneessa.
Jos ohjelma käyttäisi liukulukuja float tai double, jotka ovat 8 tavuisia (64 bittiä) niin silloin tietysti 64 bittinen prosessori ja käyttöjärjestelmä on ylivertainen.
Tämän ohjelman tarkoitus ei ole todeta itsestäänselvyyksiä kuten että 32 bittinen prosessori on hitaampi 64 bittisen datan kanssa. Tarkoitus on testata eri prosessorien tehoja 32 bittisellä datalla, jonka voisi myös toteuttaa halutessaan niin että bitit alkavat 00000000000000000000000000000000 ja päättyvät 11111111111111111111111111111111 ja tämän välisen ajan voisi sitten kellottaa. Ohjelmaa testatakseni halusin kuitenkin että suoritus kestäisi keskimäärin 10 sekuntia vanhalla koneella, enkä osannut arvata että printf hidastaisi ohjelmaa uudemmassa koneessa niin että suoritus kestääkin 50 sekuntia.
Ainakin tästä oppi sen että prosessorin tehoja mitatakseen pitää käyttää vain lukuja ja unohtaa kaikki muut datatyypit, eikä mitään tulostuksia mukaan. Tämä johtuu siitä että tulosteet ja merkkijonot muutenkin tulevat käyttöjärjestelmältä ja sen toteutus ei juurikaan riipu prosessorista.
Korjataan vielä, float on 4 tavua ja double on 8. Datatyyppien koot 64bit Linuxissa:
char: 1 tavua (8 bittiä)
int: 4 tavua (32 bittiä)
long: 8 tavua (64 bittiä)
float: 4 tavua (32 bittiä)
double: 8 tavua (64 bittiä)
Kylläpä osaat sotkea, (int: 4 tavua (32 bittiä))
Mistä hitosta sinä noita saat päähäsi, kaikki menee päin persettä
int on vai 16 bittinen jolla voidaan esittää luvut [−32,767, 32,767]
unsigned int 16 bittinen jolla voidaan esittää luvut [[0, 65535]
Jospa korjailet kaiken vielä kertaalleen, saattas sattua tuuria matkaan, mene tiedä vaikka osa olisi sitten oikein.
"int on vai 16 bittinen jolla voidaan esittää luvut [−32,767, 32,767]"
LOL.
"On systems where the representation of Unix time is as a signed 32-bit number, the representation will end after the completion of 2,147,483,647"
https://en.wikipedia.org/wiki/Unix_time
Suurin luku 4 tavuisella (32bit) datatyypillä int on siis 2,147,483,647.
(unsigned int = tuo luku x2)
En sano pahalla mutta sinä et tiedä ohjelmoinnista ilmeisesti mitään. Mukava "väitellä" tasoistesi koodaajien kanssa. !=
Minusta kun näytti se sinun sotkusi C -kielen koodilta, jossa int tyyppinen muuttuja on 16 biittinen. Mitäs koodia se sitten oli, jotai sellaista sinä mainitsit että "Raapustin C kielellä", ja C -kielen muuttujat olisi hyvä osata https://fi.wikibooks.org/wiki/C /Muuttujat , sähläämällä puutaheinää siitä ei mitään tule.
Sinun hommasi kusi niin pahasti, että nyt on kai ihan pakko sönköttää unixin time ja kellot tähän, jollakin tavalla kuuluvaksi, kun niillä tekijöillä ei ole osaa eikä arpaa tekemässäsi räpellyksessä ja sen toimivuudessa.
"Suurin luku 4 tavuisella (32bit) datatyypillä int on siis 2,147,483,647.
(unsigned int = tuo luku x2)"
Onnistuuko sinulla yhtään mikään, tuotakin olet hokenut kokoajan, ymmärtämättä siitä mitään, jospa yritä vielä kerran
long int tyyppinen muuttuja voi saada avon välillä [−2147483648…2147483647] jos sinä mitenkään voit tämän käsittää INT ja LONG INT on eri muuttuja tyyppejä vaikka molemmat onkin kokonaislukuja (integer).
JA
kun LONG INT tyyppisen muuttuja negatiiviset luvut poistetaan siitä tulee tyypiltään
UNSIGNED LONG INT eli etumerkitön kokonaisluku joka voi saada arvot [0…4294967295].
Nyt voisit ihan itse selvittää kuinka int tyyppinen muuttuja käyttäytyy kun sen arvoalue ylitetään, mutta luulen ettet kuitenkaan osaa sitä tehdä niin minä tein sinulle tuonne mallin: https://goo.gl/ao9p6p
Vielä haluan huomauttaa ihan erikseen, kun olen havaintojeni mukaan huomannut sinut varsin yksikertaiseksi, että kun muuttujan arvoalue ylitetään se pyörähtää ympäri, miten luulet sinun INT muuttujan pystyvän käsittelemään LONG INT muuttujan arvoaluetta. Siinä ei tosiaankaan auta yhtään minkä tyyppistä muuttujaa käytetään kellonajan laskennassa.
Ei+jumalauta+sentään.+Ei+muuttujan+tyyppi+riipu+siitä+mitä+dataa+sillä+käsitellään!+Datatyyppi+varaa+toivon+mukaan+oikeat+rekisterit+prosessorista+joka+nopeuttaa+ohjelman+toimintaa+huomattavasti.+Intel+386+arkkitehtuuri+oli+32+bittinen+ja+Linux+kirjoitettiin+nimenomaan+sille+prosessorille.+Miksi+ihmeessä+Torvalds+olisi+tehnyt+int+datatyypistä+16+bittisen?+Linux+on+alusta+asti+käyttänyt+32+bittistä+int+muuttujaa+ja+sitä+se+on+edelleen+64+bittisissä+jakeluissa.
"C -kielen muuttujat olisi hyvä osata https://fi.wikibooks.org/wiki/C /Muuttujat , sähläämällä "
Oma linkkisi kertoo että
"Muuttujien arvoalueet ovat suuntaa antavia. Todellisuudessa arvoalueet ovat järjestelmäriippuvaisia, koska eri arkkitehtuureilla muuttujatyypit vievät eri määrän tavuja. Oikean muuttujan vaatiman tavujen määrän saa selville sizeof()-operaattorilla."
Ehkä kannattaa lopettaa tuo "neuvominen" tässä vaiheessa. Alat itse opettelemaan niitä perusasioita niin voit sitten ehkä tulevaisuudessa "opettaa". C kieli on vain kieli, käyttöjärjestelmä tai pikemminkin käytetty kääntäjä päättää millaista konekieli tulee olemaan. Se mitä et ymmärrä edelleenkään, POSIX standardi vaatii int datatyypille vähintään 65535 eli 16 bittiä, mutta tämä on VÄHIMMÄISVAATIMUS. Se ei tarkoita että int pitäisi olla aina 16 bittiä vaan että sen pitää VÄHINTÄÄN olla 16 bittiä. Linux on alusta asti käyttänyt 32 bittiä datatyypissä int. Tarvittaessa konekielisen ohjelman maksimin voi testata virtualisoimalla, mutta useimmat meistä luottavat siihen että gcc kääntäjä osaa hommansa. Jos C koodissa varataan int datatyyppi, Linuxissa sen kooksi tulee 32 bittiä gcc kääntäjällä.
Sähläri sählää mitä sattuun, käännä 16 biittisenä, jospa se auttaa tehoja lisäävästi 64 biittisessä ympäristössä, voisit sählätä kunolla ja kääntäsit 8 biittisenä, niin nousee tehot myös 32 bittisessä ympäristössä.
eikun, eikun, eikun . . . .
Sää et siis tiedä ohjelmoinnista mitään. Älkää muut lukeko tän Urbon juttuja.
No niin, nyt meni trolli hommiksi, avuttomuusko iski noin pahasti.
" Ajan ohjelmaa shell skriptin avulla jossa date komento kirjoittaa aikaleiman tekstitiedostoon ennen ohjelman suoritusta, sekä sen jälkeen, lopuksi aikaleimat tulostetaan cat komennolla."
Buahaahhahhaa!
Ei ihme että tollaisia aikoja sitten tulee, ja vielä ihmettelee suu auki, että mitä.
Joo katsos kun datatyyppi int on 32 bittinen ja suurin luku siihen on 2,147,483,647. Ilman printf funktiota 64bittinen i7 3.40GHz suorittaa (0 - suurin luku) toistolauseen ajassa 3.86 sekuntia.
Ohjelman suorituksen aika ei riipu siitä mitä shell skriptiä käyttää. Et tiennyt?
En tajunnut tuosta höykäsen pöläystä, oli niin sekavasti kerrottu, mitä lienet tarkoittanut.
Mutta yritän arvata, tuon silmukan suoritusaika on sama, riippumatta siitä millä tavalla sen kostoa mittaat. No ei, mutta sinun omaperäinen sählääminen antaa selvästi vääriä tuloksia, minne ne 50 sekunnin ajat nyt katosi kun minä tulin kertomaan miten se aika tulee mitata, nekö tuossa nyt on lyhentyneet 3.86 sekuntiin.
Sähläämällä tuosta ei tule lasta eikä paskaakaan.
"Joo katsos kun datatyyppi int on 32 bittinen ja suurin luku siihen on 2,147,483,647"
Koita nyt lopultakin uskoa tuo ei ole INT se on LONG INT tyyppinen muuttuja joka voi noin isoja arvoja sisältää.
Ei vit... tu. Naamapalmu. Ei se aika sen takia lyhentynyt että aikaleimat otetaan toisella tavalla... vaan siksi että otin luupista printf funktion pois. Microsoft koodaja tulee tänne pätemään eikä tiedä sitä vähää, mikä on Linuxissa int datatyypin koko. Ymmärrä nyt hyvä ihminen että sinä et ole avuksi. Et ollut missään vaiheessa. Mene jonnekin muualle vuodattamaan tuota paskaasi.
Jos tuo toimii ilman tulostusta i7:lla paljon nopeammin voisiko olla, että 64-bittisessä versiossa konsolitulostus ei ole kovin optimaalinen ? Itse lisäykseen kuluva aika voi olla pieni murto-osa siitä ajasta mikä tulostukseen menee ja itse tulostus on 64-bittisessä versiossa PAAAAAAAALJON hitaampi.
Voi olla myös niin, että tuo numeron konvertointi tulostukseen on se hidastava tekijä. Kokeilepa vielä ajaa alkuperäinen koodi 64-bittisessä ilman numeron konvertointia vaikka tyyliin printf("100\n");
Testailen+kun+nyt+tiedän+mistä+kenkä+puristaa.+Testailaa+tekin+jos+on+aikaa.+C+koodi+on+tosi+yksinkertainen+ja+se+on+tarkoituskin.+Idea+on+siis+testata+samaa+C+koodia+eri+prosessorilla.
Vastasin sulle tuohon toiseen ketjuun minkä teit ohjelmointipuolelle:
https://keskustelu.suomi24.fi/t/15179399/64bit-i7-hitaampi-kuin-32bit-dualcore
Lisäyksenä+vielä+sellainen,+että+intin+koko+voi+olla+erilainen+eri+systeemeissä+ja+64-bittisen+luvun+käsittely+on+huomattavasti+hitaampaa+kuin+32-bittisen.+Kannattaisi+lisätä+molempiin+versioihin+ennen+silmukkaa+koon+tarkistus+tyyliin+printf("%d\n",+sizeof(int));
On tarkastettu jo. Molemmissa int on 32 bittiä.
Hitto se on LONG INT eikä INT
Äläpäs sekoita. C-kielessä ei ole taattua, että int olisi tietyn mittainen. Ainoastaan eri pituisten kokonaislukujen keskinäiset suhteet on määrätty siten, että short <= int <= long. Int voi tosiaankin olla 32-bittinen. Esmes eräässä omassa ohjelmassani (Qt-ohjelma, jota käytän pääasiassa Linuxilla) on käytetty int-tyyppisiä muuttujia ja ne ovat todistetusti 32-bittisiä.
Jossain toisessa systeemissä int voi hyvinkin olla 16-bittinen. Jossain oikein raskaassa systeemissä se saattaisi olla vaikka 64-bittinen. Jos halutaan juuri tietyn pituisia kokonaislukuja on parempi käyttää standardityyppejä uint8_t, uint16_t, uint32_t ja uint64_t (tai vastaavia etumerkillisiä versioita).
Joo, näin on ja nämä määrittelyt on esitelty stdint.h kirjastossa, joka täytyy sitten sisällyttää ohjelmaan mukaan.
#include <stdint.h>
Vielä tuo jäi vaivaamaan sen verran että on hyvä määritellä muuttuja long int tyyppiseksi silloin kun tarvitsee 32 biittisen muuttujan, eikä luottaa siihen että järjestelmä hoitaa asian.
Tai vaihtoehtoisesti käyttää stdintin taatun kokoisia tyyppejä. Järjestelmästä riippuen long int voi olla myös 64-bittinen, jolloin tulisi tuhlattua muistia jos haluaa vain 32-bittisen luvun.
Onhan lisäksi vielä long long int sekoittamassa soppaa. Ja muistelen lukeneeni, että jossain systeemissä olisi vielä ollut short long int.
Onko näin? Kappas vaan int on 32 bittiä!
/usr/include/stdint.h
...
/* Exact integral types. */
/* Signed. */
/* There is some amount of overlap with <sys/types.h> as known by inet code */
#ifndef __int8_t_defined
# define __int8_t_defined
typedef signed char int8_t;
typedef short int int16_t;
typedef int int32_t;
# if __WORDSIZE == 64
typedef long int int64_t;
# else
__extension__
typedef long long int int64_t;
# endif
#endif
/* Unsigned. */
typedef unsigned char uint8_t;
typedef unsigned short int uint16_t;
#ifndef __uint32_t_defined
typedef unsigned int uint32_t;
# define __uint32_t_defined
#endif
#if __WORDSIZE == 64
typedef unsigned long int uint64_t;
#else
__extension__
typedef unsigned long long int uint64_t;
#endif
...
Mitä lukee kohdassa typedef int ?? vinkki: int32
On se mielenkiintoista, miten joku jaksaa väittää vielä vastaan. Itsestäänselvä asia Linux koodaajille. Microsoft koodaajat laukkaavat palstalla laput silmillä, ei ihme että Windows on paskaa.
Älähän nyt hirnu hevonen, vaikka C99 ISO-standardi mahdollistaakin joissakin tapauksissa
tilanteen jossa kaksi kokonaislukutyyppiä ovat samankokoiset, mutta eivät ole yhteensopivia.
ELI edelleenkään et voi käyttää ja olettaa että int korvaa long tyypin, joten tyypitykset pitää hoitaa aivain kuten ennen C99 ISO-standardin tuloa, vaikka se toikin mukanaan uusia ominaisuuksia.
JOTEN
int on 16 bittinen
ja
long int 32 bittinen
Missä modernissa käyttöjärjestelmässä int on max 16 bittinen? Linuxissa ei ainakaan, eikä muuten ole Windowsissakaan, eikä taatusti ole OSX int myöskään. MS-DOSiinko koodailet?
WINDOWS:
"INT A 32-bit signed integer. The range is -2147483648 through 2147483647 decimal.
This type is declared in WinDef.h as follows:
typedef int INT;"
https://msdn.microsoft.com/en-us/library/windows/desktop/aa383751(v=vs.85).aspx
LINUX:
"When you compile and execute the above program, it produces the following result on Linux
...
Storage size for int : 4"
https://www.tutorialspoint.com/cprogramming/c_data_types.htm
"Table 2-1 Size and alignment of base data types in OS X
...
int 4 bytes"
https://developer.apple.com/library/content/documentation/Darwin/Conceptual/64bitPorting/transition/transition.html
Kerro nyt, mihin käyttöjärjestelmään kirjoitat koodia tänä päivänä, jossa int olisi max 16 bittiä eli 2 tavua? Vai etkö osaa myöntää olleesi täysin väärässä?
Linux aina vaikea. Kannattaa poistaa moinen kura koneelta heti.
Kurahousu-windowstrollille tiedoksi: Linux EI ole vaikea EIKÄ kuraa! Joten poista itsesi HETI täältä p*skaa jauhamasta!
Ei se kellotaajuudesta tai intin koosta ole kiinni.
Linuxin time komennolla saat selville, kauanko ohjelmasi oli ajossa, user moodissa, järjestelmä moodissa, ja real aika sisältä edellisten lisäksi myös sen kauanko se oli blokattuna odottamassa ajoon pääsemistä.
Selvästi suurin osa ajasta tuota ohjelmaa ajaessa se on blokattuna, eli käyttöjärjestelmä ei päästä sitä ajoon, koska print komento aiheuttaa järjestelmäktusun ja se jää sen vuoksi odottamaan. Tässä voisi olla taustalla se, että näytön / konsolin päivitys on vain määrätyn ajan väliein, joten kun se tekee print komennon, se varmaankin jää odottamaan siihen seuraavan näytön päivitykseen asti.
Jos pipettää koko ohjelman tulostuksen tiedostoon, suoritus ei kestä kuin sekunnin mopommallakin koneella.
Eli tämä ohjelma ei niinkään mittaa prossun nopeutta, vaan koko käyttöjärjestelmän toimintaa. Voisiko syynä olla muut ajossa olevat ohjelmat, tai jokin eri asetus konsolin päivitysnopeudelle.
real
On se aika jonka voi katsoa vastaavan samaa kun sinä itse mittaisit käytettyä aikaa sekuntikelon kanssa. ELI SE KOKONAISAIKA
user
Tämä saattaa olla suurempikin kokonais-aika, yhtäaikaisen säkeistetyn suorituksen johdosta, ELI PROSSUJEN YHTEEN LASKETTU TYÖAIKA.
sys
on muistin allokointia tai jotain CPUn ulkopuolella ytimessä tapahtunutta ajan tappoa.
real = user sys
No väärinhän tuo meni
real = (user / (suoritukseen osallistuneiden säikeiden määrä) sys
usein tuo user on kuitenkin vain yhden säikeen aika, java saattaa säikeistää enemän ja saa tämän user ajan näyttämään kokonais aikaa isommalta. Jos se on isompi, silloin tehtävään on osallistunut useampi säie.
ja vielä tuohon
sys
on sillä tavalla tapettua aikaa jolla ei ole päällekäisyyttä, kuten levyn luku/kirjotus, näytölle tulostus tai jotain muuta.
Huomioi, että
real voi olla enempikin kuin user sys, koska real sisältää myös kaikkien muiden samaan aikaan ajossa olleiden ohjelmien ajoajan. Eli se on kuten aluksi sanoitkin, sama kuin itse mittaisit sekunttikellolla aikaa. Esim. tuon printtikomennon aikana, käyttöjärjestelmä voi vaihtaa välissä jonkun muun prosessin ajoon, jos käyttäjän pyytämää toimintoa ei voi heti toteuttaa.
Itse ymmärsin, että sys meinaa kernel moodissa tälle prosessille kulunutta aikaa.
Eli, kun käyttäjän sovellus tekee jonkin järjestelmäkutsun, niin tulee keskeytys ja käyttöjärjestelmä pääsee ajoon. Tämä olisi sys aikaa sitten?
Esim. itse sain eilen tälle ohjelmalle tällaiset luvut:
real 0m10.738s
user 0m0.766s
sys 0m1.172s
Huomaa, että real on paljon enempi kuin user sys, eli käyttöjärjestelmä ei päästänyt ohjelmaa ajoon, vaan se oli jäähyllä odottamassa suurimman osan aikaa. ;)
Aivan, tuota real aikaa saa kertymään, jos esimekiksi, häiritsee tulostamista ruudulle, heiluttelemalla samassa ikkunassa hiiren kursori.