Rush, Not an area of expertise for me but I had a couple questions:
1. What problems were there using the Boost timer library? 2. Did you look at Intel's Threading Building Blocks tick_count implementation? Chad On 5/27/09 8:14 AM, "Rush Manbert" <[email protected]> wrote: 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
