How to use boost to track real time instead of user+sys? - c++

I'm using boost::timer to time a section of my code. If I run the code with one thread:
$ time ./runfoo 1
Took 2.08s
real 0m2.086s
user 0m1.611s
sys 0m0.475s
2.08 is the output of t.elapsed().
Yet if I run the code with 4 threads:
$ time ./runfoo 4
Took 2.47s
real 0m1.022s
user 0m1.834s
sys 0m0.628s
It seems to be tracking user+sys time, not real time.
How do I make it track real time? I'm using Boost 1.46. To be more specific, the timer is in the main thread, which just calls a function that ends up using the multiple threads.
EDIT: The relevant source looks something like this:
boost::asio::io_service ios;
boost::thread_group pool;
boost::asio::io_service::work work(ios);
pool.create_thread(boost::bind(&boost::asio::io_service::run, &ioService));
pool.create_thread(boost::bind(&boost::asio::io_service::run, &ioService));
pool.create_thread(boost::bind(&boost::asio::io_service::run, &ioService));
pool.create_thread(boost::bind(&boost::asio::io_service::run, &ioService));
{
boost::timer t;
function_which_posts_to_ios(ios);
printf("Took %.2fs\n", t.elapsed();
}
As to what output I expect, I'd like the program in the 2nd run to print "Took 1.02s" instead of "Took 2.47s", as 1.02s was the actual amount of seconds that elapsed.

It appears that you are using the deprecated Version 1 timers where the semantics of elapsed() was not consistent across platforms, wall-clock time on some and CPU time on others. In the Version 2 cpu_timer, the elapsed() method returns a struct which has distinct members for real, user, and system time.
If you cannot use the Version 2 API, you can use boost::posix_time instead to measure wall clock time. See c++ boost get current time in milliseconds.

Related

API to capture thread's CPU time

I want to measure the CPU time, not elapsed time on a thread. For example, if a thread is waiting or sleeping, it shouldn't count as CPU time because the thread is not in runnable state. So I got the following link to get CPU time. However, it seems to be capturing the elapsed time instead based on my test below (I expect cpu_time_used should be close to 0 but it is actually 2).What am I missing?
https://www.gnu.org/software/libc/manual/html_node/CPU-Time.html
#include <time.h>
clock_t start, end;
double cpu_time_used;
start = clock();
std::this_thread::sleep_for (std::chrono::seconds(2));
end = clock();
cpu_time_used = ((double) (end - start)) / CLOCKS_PER_SEC;
Note that clock() measures in units of core-time, i.e. CLOCKS_PER_SEC clock() ticks represent one second of computation on one processor, so it indicates the amount of time used by the process over all threads. So, if there is another thread running during the sleep it will still be increasing the clock count -- if there are two threads in total the clock count will indicate 2 seconds have elapsed, like you have shown. If the sleeping thread is the only thread, you get a small amount of time, like #NateEldredge reports. On Linux you can query or setup a timer on CLOCK_THREAD_CPUTIME_ID instead, like #KamilCuk said.

I'm looking to improve or request my current delay / sleep method. c++

Currently I am coding a project that requires precise delay times over a number of computers. Currently this is the code I am using I found it on a forum. This is the code below.
{
LONGLONG timerResolution;
LONGLONG wantedTime;
LONGLONG currentTime;
QueryPerformanceFrequency((LARGE_INTEGER*)&timerResolution);
timerResolution /= 1000;
QueryPerformanceCounter((LARGE_INTEGER*)&currentTime);
wantedTime = currentTime / timerResolution + ms;
currentTime = 0;
while (currentTime < wantedTime)
{
QueryPerformanceCounter((LARGE_INTEGER*)&currentTime);
currentTime /= timerResolution;
}
}
Basically the issue I am having is this uses alot of CPU around 16-20% when I start to call on the function. The usual Sleep(); uses Zero CPU but it is extremely inaccurate from what I have read from multiple forums is that's the trade-off when you trade accuracy for CPU usage but I thought I better raise the question before I set for this sleep method.
The reason why it's using 15-20% CPU is likely because it's using 100% on one core as there is nothing in this to slow it down.
In general, this is a "hard" problem to solve as PCs (more specifically, the OSes running on those PCs) are in general not made for running real time applications. If that is absolutely desirable, you should look into real time kernels and OSes.
For this reason, the guarantee that is usually made around sleep times is that the system will sleep for atleast the specified amount of time.
If you are running Linux you could try using the nanosleep method (http://man7.org/linux/man-pages/man2/nanosleep.2.html) Though I don't have any experience with it.
Alternatively you could go with a hybrid approach where you use sleeps for long delays, but switch to polling when it's almost time:
#include <thread>
#include <chrono>
using namespace std::chrono_literals;
...
wantedtime = currentTime / timerResolution + ms;
currentTime = 0;
while(currentTime < wantedTime)
{
QueryPerformanceCounter((LARGE_INTEGER*)&currentTime);
currentTime /= timerResolution;
if(currentTime-wantedTime > 100) // if waiting for more than 100 ms
{
//Sleep for value significantly lower than the 100 ms, to ensure that we don't "oversleep"
std::this_thread::sleep_for(50ms);
}
}
Now this is a bit race condition prone, as it assumes that the OS will hand back control of the program within 50ms after the sleep_for is done. To further combat this you could turn it down (to say, sleep 1ms).
You can set the Windows timer resolution to minimum (usually 1 ms), to make Sleep() accurate up to 1 ms. By default it would be accurate up to about 15 ms. Sleep() documentation.
Note that your execution can be delayed if other programs are consuming CPU time, but this could also happen if you were waiting with a timer.
#include <timeapi.h>
// Sleep() takes 15 ms (or whatever the default is)
Sleep(1);
TIMECAPS caps_;
timeGetDevCaps(&caps_, sizeof(caps_));
timeBeginPeriod(caps_.wPeriodMin);
// Sleep() now takes 1 ms
Sleep(1);
timeEndPeriod(caps_.wPeriodMin);

Best option to profile CPU use in my program?

I am profiling CPU usage on a simple program I am writing. I have different algorithms I want to try, and I also want to know what's the impact on the total system performance.
Currently, I am using ualarm() to execute some instructions at 30Hz; every 15 of those interruptions (every 0.5s) I record the CPU time with getrusage() (in useconds), so I have an estimation on the total cpu time of cpu consumption on that point in time. But to get context, I also need to know the total time elapsed in the system in that time period, so I can have the % of which is used by my program.
/* Main Loop */
while(1)
{
alarm = 0;
/* Waiting Loop: */
for(i=0; !alarm; i++){
}
count++;
/* Do my things */
/* Check if it's time to store cpu log: */
if ((count%count_max) == 0)
{
getrusage(RUSAGE_SELF, &ru);
store_cpulog(f,
(int64_t) ru.ru_utime.tv_sec,
(int64_t) ru.ru_utime.tv_usec,
(int64_t) ru.ru_stime.tv_sec,
(int64_t) ru.ru_stime.tv_usec);
}
}
I have different options, but I don't know which one will provide the most exact result:
Use ualarm for the timing. Currently it's programmed to signal every 0.5 seconds, so I can take those 0.5 seconds as the CPU time. Seems quite obvious to use, but it's the best option?
Use clock_gettime(CLOCK_MONOTONIC): it provides readings with a nanosec resolution.
Use gettimeofday(): provides readings with a usec resolution. I've found opinions against using it.
Any recommendation? Thanks.
Possible solution is to use system function time and don't using busy loop (like #Hasturkun say) in your program. Call in console:
time /path/to/my/program
and after execution of it you get something like:
real 0m1.465s
user 0m0.000s
sys 0m1.210s
Not sure about precision, if it is enough for you.
Callgrind is possibly the best application for profiling C/C++ code under linux. Use it with pride:)

What function to use for waiting?

I want my program to display a random number for 10 seconds; I can generate the number, but the timer doesn't work for me!!
I have tried to use this code:
void MemoryGame::sleep(unsigned int mseconds)
{
clock_t goal = mseconds + clock();
while (goal > clock());
}
...
sleep(500);
Isn't clock() the correct function here? Or do I overlook something else?
Every OS I've come across provides a sleep. Why not just use the OS for the given number of milliseconds? Your CPU will thank you for not keeping it busy doing nothing.
If you want to sleep for a number of seconds (10?), POSIX provides a sleep(unsigned int seconds) function. To sleep for an interval specified using fractions of a second, the usleep function provides this functionality.
The functions reside in #include <unistd.h>, and on most OS:s you should be able to type e.g. man 3 sleep to get some help.
On the Windows side, there is the Sleep(DWORD milliseconds) function.
Don't busy-wait (e.g. while(t<t1);) unless you have a very special need to do so.

Boost timed_wait leap seconds problem

I am using the timed_wait from boost C++ library and I am getting a problem with leap seconds.
Here is a quick test:
#include <boost/thread.hpp>
#include <stdio.h>
#include <boost/date_time/posix_time/posix_time.hpp>
int main(){
// Determine the absolute time for this timer.
boost::system_time tAbsoluteTime = boost::get_system_time() + boost::posix_time::milliseconds(35000);
bool done;
boost::mutex m;
boost::condition_variable cond;
boost::unique_lock<boost::mutex> lk(m);
while(!done)
{
if(!cond.timed_wait(lk,tAbsoluteTime))
{
done = true;
std::cout << "timed out";
}
}
return 1;
}
The timed_wait function is returning 24 seconds earlier than it should. 24 seconds is the current amount of leap seconds in UTC.
So, boost is widely used but I could not find any info about this particular problem. Has anyone else experienced this problem? What are the possible causes and solutions?
Notes: I am using boost 1.38 on a linux system. I've heard that this problem doesn't happen on MacOS.
UPDATE: A little more info: This is happening on 2 redhat machines with kernel 2.6.9. I have executed the same code on an ubuntu machine with kernel 2.6.30 and the timer behaves as expected.
So, what I think is that this is probably being caused by the OS or by some mis-set configuration on the redhat machines.
I have coded a workaround that adjusts the time to UTC and than get the difference from this adjustment and add to the original time. This seens like a bad idea to me because if this code is executed on a machine without this problem, it might be 24s AHEAD. Still could not find the reason for this.
On a Linux system, the system clock will follow the POSIX standard, which mandates that
leap seconds are NOT observed! If you expected otherwise, that's probably the source of the discrepancy you're seeing. This document has a great explanation of how UTC relates to other time scales, and the problems one is likely to encounter if one relies on the operating system's concept of timekeeping.
Is it possible that done is getting set prematurely and a spurious wakeup is causing the loop to exit sooner than you expected?
Ok, here is what I did. It's a workaround and I am not happy with it but it was the best I could come up with:
int main(){
typedef boost::date_time::c_local_adjustor<boost::system_time> local_adj;
// Determine the absolute time for this timer.
boost::system_time tAbsoluteTime = boost::get_system_time() + boost::posix_time::milliseconds(25000);
/*
* A leap second is a positive or negative one-second adjustment to the Coordinated
* Universal Time (UTC) time scale that keeps it close to mean solar time.
* UTC, which is used as the basis for official time-of-day radio broadcasts for civil time,
* is maintained using extremely precise atomic clocks. To keep the UTC time scale close to
* mean solar time, UTC is occasionally corrected by an adjustment, or "leap",
* of one second.
*/
boost::system_time tAbsoluteTimeUtc = local_adj::utc_to_local(tAbsoluteTime);
// Calculate the local-to-utc difference.
boost::posix_time::time_duration tLocalUtcDiff = tAbsoluteTime - tAbsoluteTimeUtc;
// Get only the seconds from the difference. These are the leap seconds.
tAbsoluteTime += boost::posix_time::seconds(tLocalUtcDiff.seconds());
bool done;
boost::mutex m;
boost::condition_variable cond;
boost::unique_lock<boost::mutex> lk(m);
while(!done)
{
if(!cond.timed_wait(lk,tAbsoluteTime))
{
done = true;
std::cout << "timed out";
}
}
return 1;
}
I've tested it on problematic and non-problematic machines and it worked as expected on both, so I'm keeping it as long as I can't found a better solution.
Thank you all for your help.