On Thu, Sep 24, 2009 at 3:01 AM, Johan Nilsson
Does it happen due to the multi-process and multi-thread mode by windows?
No, it happens because the actual resolution of the timer under Windows is platform-dependent, and on your platform ~15ms. If the exection takes less time, you'll see 0 elapsed.
I do not know how to solve it. My program is quite strict on the time consumed by the computer.
Run the program's main body many times and divide the total time with the number of executions.
Yes, the around 15ms resolution of the default Windows timer is too coarse IMHO, given the multi-GHz CPUs of today. If what you time fully happens between two ticks, the timer says zero indeed. http://en.wikipedia.org/wiki/Andrew_Koenig wrote a few years back a nice 6 article series on benchmarking (was it Byte, DrDoobs, CUJ, or OOC, I don't recall), and showed you can spin until the clock ticks (up to 15ms worth..., was around 30,000 iterations at that time, in Java code), do your short op, then spin again until the next clock tick, and by approximating the time a spin iter takes, you can get a fairly accurate measurement. Also talked about taking N samples, throwing out the extremes, and then taking the median I think. Windows does support a high resolution timer, but I could never find a good impl to re-use, and it's not portable of course. I wish Boost provided such a high res timer in a portable manner :) --DD