Yes, that was one of them.
This article is interesting, from an official source, and recent:
http://software.intel.com/en-us/articles/measure-code-sections-using-the-enhanced-timer/
It appears that the Enhanced Timer is what tick_count uses, which
makes me think that maybe the "Beware of QueryPerformanceCounter()"
article is out of date. If the multi-core stuff is not an issue, then
for our (Thrift internals) purposes a clock slowdown may not matter.
The use within the library is to wait with a timeout, so you're at the
mercy of the OS implementation for that, no matter what. The test
pattern is generally that the main thread starts a test thread, then
waits for the test thread to reach some known point where it waits,
then signals the test thread to continue to the next wait point, etc.
The test thread records progress by setting the value of a variable
that the two threads share. The controlling thread calls wait with a
short timeout, just to cede the CPU and give the thread under test a
chance to run, but it does that in a loop that times out in hundreds
or thousands of milliseconds. If time appeared to slow down during
those tests it shouldn't matter.
I still have both the timeGetTime() and QueryPerformanceCounter()
implementations in Util.cpp, selectable at compile time. I guess all I
need now is a multi-core notebook running XP or Vista. I might be able
to come up with one of those from our QA group. Or maybe I can scare
up a volunteer from the list to do some testing.
- Rush
On May 28, 2009, at 8:38 PM, Chad Walters wrote:
Hmm, is this one of the articles you looked at?
http://www.virtualdub.org/blog/pivot/entry.php?id=106
That is definitely a bit off-putting.
Not sure about the power save mode issue, but I think someone told
me that
tbb::tick_count gets the value from the same CPU each time.
http://www.threadingbuildingblocks.org/documentation.php
From the TBB reference manual:
7 Timing
Parallel programming is about speeding up wall clock time, which is
the real
time that
it takes a program to run. Unfortunately, some of the obvious wall
clock
timing
routines provided by operating systems do not always work reliably
across
threads,
because the hardware thread clocks are not synchronized. The library
provides
support for timing across threads. The routines are wrappers around
operating
services that we have verified as safe to use across threads.
From the TBB tutorial:
8 Timing
...
Unlike some timing interfaces, tick_count is guaranteed to be safe
to use
across
threads. It is valid to subtract tick_count values that were created
by
different
threads. A tick_count difference can be converted to seconds.
The resolution of tick_count corresponds to the highest resolution
timing
service on
the platform that is valid across threads in the same process. Since
the CPU
timer
registers are not valid across threads on some platforms, this means
that
the
resolution of tick_count can not be guaranteed to be consistent across
platforms.
I'd be interested to see whether this works for you.
Chad
On 5/28/09 8:31 AM, "Rush Manbert" <[email protected]> wrote:
Hi Chad,
It uses QueryPerformanceCounter on Windows. I'm going to go back and
test my QPF code again. It's possible (oh so remotely possible ;-)
that I screwed something up.
Best regards,
Rush
On May 27, 2009, at 4:06 PM, Chad Walters wrote:
<snip>
2. Did you look at Intel's Threading Building Blocks tick_count
implementation?
