Sorry for asking this, but which parts in the Thrift Library rely on
timers?
The timeGetTime() thing sounds good and linking against winmm.dll
should not cause problems. But I am wondering where winmm.dll gets its
time information from and if you could access it at a lower level?
- Patrick
Am 27.05.2009 um 23:14 schrieb Rush Manbert <[email protected]>:
I posted this to the dev list, but I know that there are people who
probably only read this list that might have an interest in the
subject, so I'm posting it here too.
Hi all,
I have moved my Boostified Thrift C++ library code to my Windows XP
box and I now have the concurrency test running. It's slow as
anything, but I'm hoping that's because it's a 5 year old single CPU
Athlon 64. I know my new code is as fast as the current library on
the Mac.
It turned out that one of the biggest headaches in Windows was the
system timer. I read a lot of Internet posts and went through three
implementations before getting one that is acceptable. There are,
however, tradeoffs and I was hoping that interested and
knowledgeable parties here might offer some opinions/insight.
The Windows system timer is just basically crappy. The millisecond
epoch time clock provided by the C runtime library really updates at
about 60 hz, and they just change it to whatever the current
millisecond count should be. And when the system gets busy (lots of
threads) the update becomes very haphazard.
The highest precision timer is the performance counter, which runs
at some frequency that is subdivided off the CPU clock or a
peripheral clack. On my system it runs at about 3.5 Megahertz, so
it's plenty fast. But it has its own problems. From what I have
read, it can slow down because of power save modes on the computers,
and each core in a multi core machine has its own counter. This
means that if your process gets moved between cores, the timer
reading can change, and it can possibly appear to go backward. I
believe we could get around that by remembering the last time value
that was returned, and just not letting time go backward. For the
purposes of Thrift, I think that would work. I don't know how to
handle it if the timer can really slow down, though.
The last one that I tried, after reading about the nasties in the
performance counter, is timeGetTime(). This gives the count of
milliseconds since Windows was started. As long as you calibrate it
against the epoch time on the first access (same thing has to be
done if you use the performance counter), it seems to give good
results with millisecond accuracy. However, in order to use it you
must link against Winmm.lib/dll. This appears to be a safe choice,
as the dll is supplied with all Windows systems.
So at this point, I'm planning to go with timeGetTime(), making it a
requirement that all Windows apps that use Thrift be linked against
Winmm.dll. Do I hear any well reasoned objections or alternatives?
Thanks,
Rush
