High res timers on variable speed cpus...
[501 byte] By [jonnin] at [2007-11-11 10:26:33] 
Does anyone know of a way to do this yet? I know I can disable the cpu speed changups on some computers, but I forsee a future where this is beyond my control. I also know I can constantly monitor the cpu speed but this introduces a woeful amount of overhead when trying to time something. Other timer methods all seem to be designed for a single frequency as well... I also could tap specific hardware (such as the ram clock speed etc) but I would prefer a portable or general solution if possible.
# 1 Re: High res timers on variable speed cpus...
What is the resolution you're looking for? I know that some systems have a constant time counter, which cannot be modified by a program or an external command shell. They aren't portable in the sense that you will find them on every platform but they are in C99, in the extended tm struct. Is that what you're after?Danny at 2007-11-11 20:58:49 >
# 2 Re: High res timers on variable speed cpus...
Possibly. Before the new cpu's I was reading the intel time stamp register that is a count of cpu clocks since boot (64 bit int) and dividing by the cpu speed (no longer constant, but the register is still there). I will look at the c99 one, do you think it would work on these systems?jonnin at 2007-11-11 20:59:56 >
# 3 Re: High res timers on variable speed cpus...
I was looking for the highest resolution I can get. clock() is worthless, it at least needs to be able to give the run time used by most functions, so around 1/10k-100k second would probably do.I tried clock and it cannot time anything that uses less than about 4 million instructions on this new cpu.
jonnin at 2007-11-11 21:00:54 >
# 4 Re: High res timers on variable speed cpus...
gettimeoday is a POSIX extension supported by many other platforms. It has a time resolution of up to a microsecond. Is this what you need?Danny at 2007-11-11 21:01:54 >
# 5 Re: High res timers on variable speed cpus...
possibly, ill give that a look as well. So far everything ive looked at is milisecond or worse. Im still on .net 2002 until we get everything moved to 64 bit then will upgrade to latest... so maybe its a non issue on newer tools.jonnin at 2007-11-11 21:02:53 >
# 6 Re: High res timers on variable speed cpus...
This does not appear to exist on my compiler? I searched the help for a while and the only thing that seems to have microsecond res is something that is now obsolete called wbemtime -- which does not appear to work. It always gives all zeros even when asked for the time of day. There are hints that managed c++ might have something, but I am afraid of the managed extensions as we still might have to move off windows at some point. I did not even want to use the wbem one but this section of code is easily replaced (designed to be replaced actually, since it *was* assembly)I will keep trying off and on. There are a couple of built in things that look promising but I have not tried them all yet. Fortunately, our embedded side is still fixed cpu speed and likely will be for a year or more, giving us time to resolve the timing issues.
jonnin at 2007-11-11 21:03:58 >
# 7 Re: High res timers on variable speed cpus...
I found a working function set:QueryPerformanceCounter and Frequency worked. Over a 60 second period (sleep function) it came out as expected to approximately 60 seconds. It also was able to time a single (c++) instruction, and does not get "lost" when the cpu changes its speeds.
First round of growing pains defeated, now to see how to get the most from dual core (now that I can profile the tests properly again..)
jonnin at 2007-11-11 21:04:56 >
# 8 Re: High res timers on variable speed cpus...
How portable are they? In which headers are they declared?Danny at 2007-11-11 21:06:00 >
# 9 Re: High res timers on variable speed cpus...
Not portable, however they are strongly recommended as the best available for win32 under visual studio. You need windows.h because it uses some *awful* structure/union mess to make 64 bit integers. Its fairly poorly done on that end. Wherever the rest of the code resides, it is pulled in by windows.h -- I will see if I can locate its true hiding place when I get back to work.
jonnin at 2007-11-11 21:06:58 >
