thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Schlangen <p.schlan...@mac.com>
Subject Re: Windows Timers - Seeking Opinions
Date Wed, 27 May 2009 23:18:40 GMT
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 <rush@manbert.com>:

> 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