thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rush Manbert <r...@manbert.com>
Subject Windows Timers - Seeking Opinions
Date Wed, 27 May 2009 21:14:35 GMT
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

Mime
View raw message