thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Casagrande, Norman" <nor...@last.fm>
Subject RE: Windows Timers - Seeking Opinions
Date Thu, 28 May 2009 17:52:13 GMT
I am probably missing something, but have you tried boost::date_time
library?

boost::posix_time::ptime now =
boost::posix_time::microsec_clock::local_time();

How does it compare in terms of efficiency?
--
Norman


> -----Original Message-----
> From: Rush Manbert [mailto:rush@manbert.com]
> Sent: 27 May 2009 22:15
> To: thrift-user@incubator.apache.org
> Subject: Windows Timers - Seeking Opinions
> 
> 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