Boost my Ticks!

Started by
21 comments, last by phresnel 14 years, 1 month ago
How can I query the high-resolution counter (if available) using Boost, which I want for portability. Intel TBB provides an easy way: tick_count::now(), is there an equivalent in Boost? Thanks.
Advertisement
Not really, but it seems pretty easy to define your own.

BTW, are you aware of the (sometimes serious) problems surrounding the use of high resolution timers?
Not really, I need this for physical simulation and game development...

What kind of problems?

Like how if you run on a multi-core machine, and you query the high resolution timer from some thread, that thread can be scheduled around across the different cores in the machine. Each core has its own high resolution timer, and the values can (and often will) be slightly different among each core.
ic ic...so what would be the best way to time in a high-resolution simulation?

That's a good question ;-)

Unfortunately there's not a very good answer. Some people simply opt to use high resolution timers anyway despite their limitations. Usually, the values are not that different among cores, it might not even present a problem for your application.

Some people attempt to solve this by using thread affinity to restrict the thread actually querying the high resolution timer to a single core. This guarantees that the same timer is read every single time, but obviously has some drawbacks. Do you have to dedicate an entire thread whose sole purpose is to wake up every so often querying a CPU for its time stamp? If so, you're defeating the whole purpose of the high resolution timer because you're not querying it at the exact moment you need it, just every so often. Plus it's going to involve some sort of mutual exclusion to verify that you can read it correctly. So yea, the problem kind of sucks.

However, the aforementioned problem is not even the only such problem. Another problem is due to the fact that modern processors have some fairly advanced power management capabilities. Usually these operate literally by dynamically adjusting the frequency of your processor. Since high resolution timers actually return you a number of CPU ticks, the frequency is a required piece of information in order to compute something meaningful like wall-time. Most people only query the frequency once at the beginning of the program. You could query it every single time you query the high resolution counter, which would be better, but introduces a race condition -- what if your thread gets context switched between the time you query the frequency and the time you query the timer, and ends up on a different core that happens to be at a different frequency? Or maybe the power management facilities adjust the frequency after you read it but before you read the timer?


I read something once that says the Unreal 3 engine uses timeGetTime(), if that says anything...
My approach is to count the number of frames that get rendered in roughly 1 second and readjust the dt. Works perfectly with a low resolution timer. (Note that you don't need to check the time every frame, but every 1/dt frame)
Games don't really need high resolution timers, there are good ways around.
Quote:Original post by Kambiz
My approach is to count the number of frames that get rendered in roughly 1 second and readjust the dt. Works perfectly with a low resolution timer. (Note that you don't need to check the time every frame, but every 1/dt frame)
Games don't really need high resolution timers, there are good ways around.


You sure as hell need high resolution timing if you want to do any sort of profiling...

The return value of QueryPerformanceFrequency is designed to be constant, even on computers with CPU speed throttling. According to Microsoft, it doesn't, won't, can't change while the computer is running. But hey, maybe it's bugged on certain hardware, just like QueryPerformanceCounter which isn't supposed to return different values across threads but does on some computers anyway.

Has anyone here actually encountered a situation where the return value of QueryPerformanceFrequency changed during execution? I've experienced the QPC threading problem on an Athlon64 processor, and it even caused problems for Diablo 2, but I haven't managed to reproduce the frequency bug, even while using the realtime overclocking/underclocking software that comes with ASUS boards.
Here is the point, what about profiling/benchmarking the performance of some code?

I used QueryPerformanceCounter before...as it's been used by many games such as Quake's. Now I'm looking for more portable/platform independent solution.
The solution I was hoping for is how to do it using Boost hi-res timers...with least overhead.

This topic is closed to new replies.

Advertisement