Sign in to follow this  
Sambori

Boost my Ticks!

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
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
You could also use OpenMPs timer, which comes at zero library-dependency cost (works on g++, xlc++, icc, msvc, linux, windows).

I have coded this nano-wrapper around it so that I don't sprinkle OpenMP-calls unnecessarily in my code, and so I can easily replace it at any time.

I mean, in the end you have to leave stdc++ anyways if you want a reliable high resolution timer (and in that, boost is not part of stdc++ as is OpenMP ;))

Share this post


Link to post
Share on other sites
I strongly support the use of OpenMP's timing library. I decided "enough is enough" and actually did a benchmark a couple years ago testing accuracy and reliability of every timer I could get my hands on, on every platform, and OpenMP's came out WAAY WAAY above everyone elses.

Share this post


Link to post
Share on other sites
Maybe off topic, but instead of starting anew thread, since this one is already getting into it...in case of a reliable mutli-core API, what would be the best in terms of portability and capabilities for a standard C++ application?

TBB or OpenMP?

Is TBB tied somehow to Intel's hardware/CPUs?

What're the problems of using OpenMP in C++ program?

TBB seems to have an overhead when doing simple stuff such as for/loop threading in terms of code and performance...



Share this post


Link to post
Share on other sites
Multi-threading a game or simulation system...

But is TBB cpu-portable? I mean Intel/AMD?

Is it efficient? Overhead?

Share this post


Link to post
Share on other sites
Quote:
Original post by Sambori
Multi-threading a game or simulation system...

But is TBB cpu-portable? I mean Intel/AMD?

Is it efficient? Overhead?


Yes. Yes. Yes. As with other possibilities.

Share this post


Link to post
Share on other sites
Quote:
Original post by Sambori
Maybe off topic, but instead of starting anew thread, since this one is already getting into it...in case of a reliable mutli-core API, what would be the best in terms of portability and capabilities for a standard C++ application?

TBB or OpenMP?

Is TBB tied somehow to Intel's hardware/CPUs?

What're the problems of using OpenMP in C++ program?

TBB seems to have an overhead when doing simple stuff such as for/loop threading in terms of code and performance...


OpenMP is the cross platform choice and by cross platform I mean really cross platform not just different OS's running on Intel / AMD hardware.

Share this post


Link to post
Share on other sites
Are these timing issues with multiple cores, and so on something I have to worry about in my simple games?
I can understand for complicated physics simulation that you need a reliable timer, but does it really matter in simple platformers, shoot em ups, small games made by one person?

Share this post


Link to post
Share on other sites
Quote:
Original post by marsong
Are these timing issues with multiple cores, and so on something I have to worry about in my simple games?
I can understand for complicated physics simulation that you need a reliable timer, but does it really matter in simple platformers, shoot em ups, small games made by one person?


Maybe not, but on the other hand if it really is that simple to where high resolution timer doesn't matter, why can't you just use timeGetTime() and be happy with millisecond resolution?

Share this post


Link to post
Share on other sites
Quote:
Original post by cache_hit
Quote:
Original post by marsong
Are these timing issues with multiple cores, and so on something I have to worry about in my simple games?
I can understand for complicated physics simulation that you need a reliable timer, but does it really matter in simple platformers, shoot em ups, small games made by one person?


Maybe not, but on the other hand if it really is that simple to where high resolution timer doesn't matter, why can't you just use timeGetTime() and be happy with millisecond resolution?


Back in the day when I was on Windows, timeGetTime() had only a resolution of like 25 milliseconds (i.e. only 40 ticks per second, which is only 0.04th of 1000ms) or so.

Share this post


Link to post
Share on other sites
Quote:
Sambori
TBB seems to have an overhead when doing simple stuff such as for/loop threading in terms of code and performance...


I have overseen this.

I guess any threading library has an overhead on loop parallelization. You even have an overhead when you are using industry standard threads (i.e. pthreads) directly.

This is why should parallelize as soon as possible in the call-graph, so that each thread has as much to do as possible. When in doubt, measure. Sometimes, parallelization is just not worthwile.

On the other hand, when you often use "mini-threads", you might want to consider to keep them all alive all the time, and give them food from time to time, thus avoiding a lot of overhead.

Anyways, note that you don't need to use the whole OpenMP system just because you want the timer. You can use the timer, and nothing else, if you want.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this