You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@thrift.apache.org by Rush Manbert <ru...@manbert.com> on 2009/05/27 23:14:35 UTC
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
Re: Windows Timers - Seeking Opinions
Posted by Rush Manbert <ru...@manbert.com>.
Hi Norman,
Plain old boost::date_time was my first attempt, but it uses the
counter that updates at 60 hz. That's the only reason I looked at
anything else.
Best regards,
Rush
On May 28, 2009, at 10:52 AM, Casagrande, Norman wrote:
> 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
>
>
>>
RE: Windows Timers - Seeking Opinions
Posted by "Casagrande, Norman" <no...@last.fm>.
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
Re: Windows Timers - Seeking Opinions
Posted by Rush Manbert <ru...@manbert.com>.
Thanks. I saw that one because the Wikipedia page links to it. I
didn't use it because you get into the same multi-core and power save
issues that QPF has without any OS support. But it's a pretty cool
little chunk of code.
Best regards,
Rush
On May 28, 2009, at 11:22 AM, Michael Andrews wrote:
> The FFTW project has a nice header with portable cycle counters.
>
> http://www.fftw.org/cycle.h
>
> Michael
>
Re: Windows Timers - Seeking Opinions
Posted by Michael Andrews <ma...@liveops.com>.
The FFTW project has a nice header with portable cycle counters.
http://www.fftw.org/cycle.h
Michael
________________________________
From: Rush Manbert <ru...@manbert.com>
Reply-To: <th...@incubator.apache.org>
Date: Thu, 28 May 2009 08:01:01 -0700
To: <th...@incubator.apache.org>
Subject: Re: Windows Timers - Seeking Opinions
Hi Patrick,
On May 27, 2009, at 4:18 PM, Patrick Schlangen wrote:
> Sorry for asking this, but which parts in the Thrift Library rely on
> timers?
Used in ThreadManager, TimerManager, and TFileTransport. Also used in
the tests, particularly after I modified them to remove race
conditions and added new tests. (Waiting for threads under test to do
something.)
>
>
> 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?
Some interesting links about the various timers:
http://www.virtualdub.org/blog/pivot/entry.php?id=106
http://www.b500.com/~hplus/misc/simple-timer.html
http://www.b500.com/~hplus/pc-timers.html
Those are some of the things I read while trying to put something
together. After reading your reply, I did a search for windows time
stamp counter and came up with this:
http://en.wikipedia.org/wiki/Time_Stamp_Counter
On that page, there is a link that is titled "Using the Processor
Clocks" that links to an Intel document that discusses the different
timers. This is the most recently published document that I have seen,
except for Microsoft docs. The "Enhanced Timer" section suggests that
QueryPerformanceCounter should really be constant frequency. I will
take another look at my code that uses it, and test it again.
The "Using the Multimedia Function timeGetTime" section doesn't tell
you what the nultimedia timer really is, so I don't know how to access
it at a lower level. You also need to specify the resolution that you
want, so the code looks like this:
timeBeginPeriod((UINT)1);
tickCount = timeGetTime();
timeEndPeriod((UINT)1);
Best regards,
Rush
Re: Windows Timers - Seeking Opinions
Posted by Rush Manbert <ru...@manbert.com>.
Hi Patrick,
On May 27, 2009, at 4:18 PM, Patrick Schlangen wrote:
> Sorry for asking this, but which parts in the Thrift Library rely on
> timers?
Used in ThreadManager, TimerManager, and TFileTransport. Also used in
the tests, particularly after I modified them to remove race
conditions and added new tests. (Waiting for threads under test to do
something.)
>
>
> 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?
Some interesting links about the various timers:
http://www.virtualdub.org/blog/pivot/entry.php?id=106
http://www.b500.com/~hplus/misc/simple-timer.html
http://www.b500.com/~hplus/pc-timers.html
Those are some of the things I read while trying to put something
together. After reading your reply, I did a search for windows time
stamp counter and came up with this:
http://en.wikipedia.org/wiki/Time_Stamp_Counter
On that page, there is a link that is titled "Using the Processor
Clocks" that links to an Intel document that discusses the different
timers. This is the most recently published document that I have seen,
except for Microsoft docs. The "Enhanced Timer" section suggests that
QueryPerformanceCounter should really be constant frequency. I will
take another look at my code that uses it, and test it again.
The "Using the Multimedia Function timeGetTime" section doesn't tell
you what the nultimedia timer really is, so I don't know how to access
it at a lower level. You also need to specify the resolution that you
want, so the code looks like this:
timeBeginPeriod((UINT)1);
tickCount = timeGetTime();
timeEndPeriod((UINT)1);
Best regards,
Rush
Re: Windows Timers - Seeking Opinions
Posted by Patrick Schlangen <p....@mac.com>.
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 <ru...@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