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
|