Delphi - Důvěryhodnost GetTickCount
Dobrý den,
snažím se optimalizovat program psaný v jazyce Pascal. Jedná se o konzolovou aplikaci. Na počátku zjistím čas systému pomocí GetTickCount a na konci provedu odečet od konečného času získaného opět GetTickCount. Je tato metoda zjišťování délky trvání algoritmů důvěryhoná, je systémový čas lineární?
Důvod otázky:
Program využívá funkce Random(), ale ne funkci Randomize, takže měření by mělo probíhat se stejnou tabulkou náhodných čísel. Používal jsem 4 lokální proměnné Boolean. Po nějaké době jsem je přestal používat v programu, ale nechal jsem je nadeklarované. Prováděl jsem měření pomocí výše uvedené metody.
Měření s nevyužívanými proměnnými: 4875, 4859 (Tyto dvě hodnoty se střídají)
Měření bez nevyužitých proměnných: 4968, 5000, 5109, 4969, 4984, atd. (Téměř každé měření jinou hodnotu)
Děkuji
inac bolo by dobre keby uvadzal cely kod, ptz vykyvy 150ms uz normalne nie su, takze ma nejaku haluz asi v programe.
Nejedná se o kód programu, ale výsledky jsou stejné.
program Project1;
Moje výsledky: 4891, 5381...
no IMHO vzdy nameras rozny cas, lebo pocas behu tvojho programu ti moze vytazovat procesor aj nieco ine, takze tvoj program sa bude vykonavat dlhsie.
Počítal jsem s tím, že to bude pokaždé jiné, ale pořád jsem nezjistil, proč na to má vliv zadeklarování nebo nezadeklarování proměnné, která není používaná? (Viz. citace v prvním příspěvku => Změna 250ms)
Nema to na to vplyv (prvykrat to bolo urcite testovane za inych podmienok)
Znamená to tedy, že nelze program optimalizovat pouhým zjišťováním délky jeho trvání?
Alebo z ineho pohladu. Vykyv 100ms u 5000ms trvania je 2%, u optimalizacie sa bavime o desiatkach percent, inac by som to nenazyval optimalizaciou ale len zbytocnou robotou. 2% mozes zanedbat. Az to zoptimalizujes ze to bude mat hodnoty okolo 3000 namiesto 5000, tak TO bude optimalizacia ;))
Děkuji za pomoc, zkusil jsem to s odpojenými USB a hodnoty byly sobě blíže. Měření provádím jen s malou částí konečné množiny prvků, program poté poběží desítky hodin. Pro jeden den dělají 2% půl hodiny, to je podle mě dost, každá minuta dobrá.
2% je stejne nezmysel, napis to v assembleri s podporou SSE a pojde to mozno aj 4x rychlejsie.
O tom moc dobře vím, každopádně děkuji za radu.
v paralelnych vypoctoch je tvoja sila :)
Hurá na Umíme to s Delphi, 51. díl – vlákna a paralelní programování
Máš to nějaké pomalé... Java 1.6.0, stará E6300.
Furt to mas pomale.
0 ms :)
Zaujimave je to len s realnym kodom ktory fakt nieco zlozite rata.
0 ms mas proto, ze ty tam pro zmenu nemas ten cyklus
No jasně tak tomuhle kodu neverim ani kozu.
Například Oracle level optimalizeru +2 by te s tim nekam poslal - while by nespoustel, protoze proc by to kurva taky delal, kdyz to pak nikde nepouzivas, tim chci rict ze zatimco vy si tu hrajete buhvinaco, tak kompilator s tim dela buhvico. Ja napriklad vim, ze v Oracle se ti na to while za urcitych okolosti vysere a to pak to tu muzete asi tezko srovávat.
Vsak jasně, kdybych tam dal VM argument -server (možná by stačila i tiered compilation), pravděpodobně by se to while vůbec nevykonalo...
Inac nie som si isty ci do long v jave ulozis 10^9 (neviem zhlavy nechce sa mi to hladat), takze si mozno tych cyklov robil napr. 100x menej apod
Uložíš, nerobil...
Pomale to ma proto, ze decrementuje primo ten extended. Pokud to, stejne jako ty, pretypuje na LongInt (v Delphi na Int64), pak to trva stejne jako u tebe
Zkousel jsem, jestli se nejak projevi Do While a Repeat - Until a ne
A kdyz I nadeklaruju jako LongInt misto Int64 (protoze to uz je hodne velky kalibr), tak jsem s casem na 437ms.
Jaký máš HW?
V Javě vlastně stačí normal int. Teď jsem na 850ms, níž už to na mojem HW asi nesrazím...
Hardware? Lenovo ThinkPad T61
Stejné výsledky jsem na tom notebooku dostal i ve VirtualBoxu.
Pokud si to chces zkusit spustit u sebe, zde je zkompilovany EXE vcetne zdrojaku:
qqq-rar
358 na i5-2410M