de ettől függetlenül ez még mindig egy külső függőség (a shelltől), míg amit én írtam az UNIX-okon kívül is működik, ott is ahol ez az operátor nincs.
Mottó: Ha valaki a szilikonmellével dicsekszik, az olyan, mintha azzal dicsekedne, hogy hibátlanul elfingotta a Für Elise-t. :-)
- Ha ez megnyugtat, PIC18 platformon (8 bit) 64MHz-es órajellel is megcsinálom gyorsabban.
- Nem *nix-ra néhány abszolút üdítő kivétellel nem írtam programot már 25 éve. Windowsra is cygwin alatt írok. ;)
Tekintve, hogy itt az egész file valószínűleg belefér egy szektorba, így kb. maradhatunk annál, hogy elméletileg gyorsabb az egyszerre beolvasós, gyakorlatilag meg kb. nem az. Illetve elhanyagolhatóan pici mértékben.
Ha ez egy "versenyprogram" vagy benchmark akar lenni...annak elég picinke.
Viszont a teljes rendszer ismerete nélkül még egy ilyen kis feladatról sem lehet semmit biztosan állítani. Példa:
Az asciiart.txt 2626 bájt hosszú. Lehet olyan fs alattad, ahol - ennél a méretnél még - az inode tárolja a dir+file elemet. De olyan is, ahol nem, ráadásul 1k logikai blokkmérettel (itt legyen 2 szektor) dolgozik. Az első 1, a második 4 fs műveletet igényel. Közben meg ott csücsül a világ leglassabb entitása a printf(). A második esetben már jobban jársz, ha nem várod ki a teljes beolvasást! Ennek ellenére majdnem mindegy, mert a cache tényleg mindent visz.
Fokozzuk egy kicsit a feszültséget! Van egy rendszerem, amely >80M processzt futtat naponta. A CPU upgrade előtt olyan nagy volt a terhelés, hogy az 5 perc periódusidőt meg kellett növelni, hogy a kiosztott feladatok le tudjanak futni. Utána annyira fürge lett, hogy az 5 perc lejárta előtt végezhet a feladatokkal, aztán pihen egy kicsit. Ok, tehát gyorsabb. És mi van akkor, ha ez a pici program pont az 5 perces periódus elején fut, amikor csúcsterhelés van? (A rendszer diszket is használ! ;)) Na, ilyenkor meg akár a cache is kiürülhet két olvasás között.
A "semmi" futásidejű programokat nem lehet shellben for ciklussal megmérni, mert a process indítás, a script futásidő, stb. akármennyi is lehet. Majdnem azt írtam, hogy szór, de inkább laza a korreláció. ;)
Fogtam a parancsot és csináltan egy N sor hosszú scriptet, azaz lineáris végrehajtást. Ugyanazon a rendszeren a futtató shell függvényében (csh, bash, ksh) 1:2 arányban változhat a végrehajtási idő.
Másik rendszeren a két program futásideje 1:1,1 arányú volt, lineárisan meg 1,1:1.
Még a user és system idők változását és arányait magyarázni sem nagyon lehet, nemhogy megérteni!
Nem is csoda, mert a "real 0m0.002s" értéket a méréstechnikában úgy hívják: zaj. :-D
Ha sok zajt összeadsz, akkor is zajt kapsz.
Szóval ilyet beépített hardver timerrel lehet mérni, ami <1us felbontást tesz lehetővé. A POWER architektúra rendelkezik ilyennel, de mintha 15 éve a linux/Intel viszonylatban olvastam volna hasonlót, bár azt nem használtam. Ezzel az eszközzel olyat is meg tudtam mérni, hogy a memóriába töltött adatbázis három tábájának átlagos lekérdezési ideje 120, 160 és 220ns.
Ennél a kis C programnál a mérési pontokat a main() elején és végén kell elhelyezni. A kapott eredményhez már hozzá lehet adni a programindítás idejét. Hasonlóan mérhető hardverrel is, ha van egy bit gpio. A mérés elején bebillented a bitet, a végén vissza. A jelenséget 1500 forintos logikai analizátorral pontosan meg tudood mérni, esetleg szkóppal.
Retro gépeim: Atlas 604 (100MHz PowerPc 604, 1996), Alix 1D (AMD Geode LX800), bookpc (VIA C3 1GHz), p615 (POWER 4+ 1GHz, 2004)
Ebből most mértem egyet az Alix/FreeBSD 10.3 konfiguráción: 10m40s, tehát a mérésednél 5x lassabb.
Ja, és folyamatosan értem mi a feladat, de asszem már régen túlnőttünk rajta. ;)