delorie.com/archives/browse.cgi | search |
> As long as the calibration only occurs when someone is using > gettimeofday, not on every cygwin1.dll load, then that sounds fine to > me. At the end of the mail there is some benchmarking to show PerformanceCounter use is not that "slow" even in its setup (which is done on it's first call). Columns are: -original: call to the gettimeofday() by DJ as found in winsup/cygwin/times.cc (which uses GetSystemTimeAsFileTime) -new: overall use of the new gettimeofday() -new_init: a version that has a "bug" in "initialization" so that initializes itself at every call -new_old: a version thar has a "bug" in detection of Performancecounter presence to force use of original call all times are in seconds per 1 millions of consecutive calls (e.g. can be considered roughly microsecond per call) The following consideration arise: -on 98 QueryPerformanceCounter is 12.5 times faster -on 2000/XP QueryPerformanceCounter is 2-3 times slower, except 2 cases in which is 7 and 9 times slower -in the typical case QueryPerformanceCounter take 5-10us at first call and 2-4us at other calls -even in the worst case QueryPerformanceCounter takes "only" 11us This sound to me as the new function would be good... what do you think of it? My only real concern is that as it is it has an "absolute" uncertainty of 15ms on the time measurement (but only 2-4us on deltas). An approach to have some kind of syncronization would be to poll original gettimeofday() until it changes value and to "sync" on that "edge", but this would slow the first call from 5-10us down to 1-16ms, which is way too much IMHO. --------+---------+-------+--------+----------+----------+----------+----------+ Machine |compiler |OS |CPU |original |new |new_init |new_old | --------+---------+-------+--------+----------+----------+----------+----------+ CyberOne|no-cygwin|2000sp2|2xP3-450| .846679| 1.746022| 5.503428| .918950| CyberOne|MSVisualC|2000sp2|2xP3-450| .862335| 1.914982| 5.498225| .868891| NoEmOn |no-cygwin|2000sp2|P3-450 | 1.228030| 11.458962| 28.876049| 1.820429| Jastar |no-cygwin|2000sp?|P2-400 | 1.184996| 8.016424| 10.086791| 1.285417| Magic |MSVisualC|2000sp?|P3-350 | 1.190737| 3.377681| 10.157640| 1.178946| Cikku |no-cygwin|2000sp?|P2-300 | 1.401790| 4.222252| 11.412069| 1.382729| Omero |no-cygwin|XP |XP1700+ | .296723| 1.051282| 3.200104| .289188| Viri |no-cygwin|98first|P2-333 | 74.665424| 5.960425| 88.101787| 75.279405| Jex |no-cygwin|98se |P2-233 |114.010888| 9.040290|136.016347|114.065398| --------+---------+-------+--------+----------+----------+----------+----------+ -- Lapo 'Raist' Luchini lapo AT lapo DOT it (PGP & X.509 keys available) http://www.lapo.it (ICQ UIN: 529796) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |