Jump to content
  • Advertisement
Sign in to follow this  
Sambori

Boost my Ticks!

This topic is 3047 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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...

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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...

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!