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
|