Re: [boost] [Boost.tracer] library request

Subject: Re: [boost] [Boost.tracer] library request
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-01-20 16:20:00

----- Original Message ----- 
From: "Andrey Semashev" <andrey.semashev_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, January 20, 2010 7:15 PM
Subject: Re: [boost] [Boost.tracer] library request

> 
>> I've used simpler implementations of things like this before and always
>> had an issue with nested trace points (usually nested function calls
>> where each function contains a trace point). When the nesting is deep
>> enough, the cumulative overhead of all the tracing functionality made
>> the data unreliable except for the inner-most trace points. It would be
>> interesting to know which of Boost.Chrono, Boost.Tracer, and Boost.Log
>> handle this the best.
> 
> As for Boost.Log, there's no difference in how many nested functions you 
> call within the timed scope. Every log record (or trace point, as you 
> would call it) simply acquires the actual timer value, and the 
> complexity of this operation is constant.

Hi,
I think the questions was related to the time reported by the outer stopclocks. How reliable is this data? How many time is related to the specific code and how many to the fact we are logging in inner blocks? Are tour mechanism able to make the difference?

Another issue is what time do we want to measure. Do we want to measure the time between elapsed between two time points start/stop or the time spent by the executed code between these time points? Note that we will need a thread specific Clock for the second case.

Boost.Chrono provides two scoped classes that allows to suspend resume what in  Boost.Chrono I call a stopwatch.

This can be used to suspend the stopwatch counting. Here follows two use cases
void f1()
{
     static stopwatch<>::reporter t;
     // ...

     // call to some function we don't want to measure
     {
        stopwatch_suspender<stopwatch<>::reporter> _(t);
        external_function();
     }
}
void f2()
{
     static stopwatch<>::reporter t;
     // ...

     // do something we don't want to measure          {
        stopwatch_suspender<stopwatch<>::reporter> _(t);
        // do something we don't want to measure     
        {
            stopwatch_resumer<stopwatch<>::reporter> _(t);
            // do something we want to measure
        }
     }
}
Of course this do not respond to your requirement, but there is something we can  learn from this examples. We can suspend the time.

So we need to define a thread specific Clock that is able to be suspended. The stopwatch reporters can take advantage of this facility and in this case the first thing the reporters must do is to suspend the time of this suspendable and thread specific Clock. 

I think I can adapt the current implementation to take care of this kind of Clocks. I will implement such suspendable Clock, and see how different are the measures. What will be more difficult is to implement a thread specific clock as this depend on whether the platform provides it or not. 

Some platforms provide already this kind of Clocks, e.g. "If _POSIX_THREAD_CPUTIME is defined, implementations shall support clock ID values obtained by invoking pthread_getcpuclockid(), which represent the CPU-time clock of a given thread. Implementations shall also support the special clockid_t value CLOCK_THREAD_CPUTIME_ID, which represents the CPU-time clock of the calling thread when invoking one of the clock_*() or timer_*() functions. For these clock IDs, the values returned by clock_gettime() and specified by clock_settime() shall represent the amount of execution time of the thread associated with the clock. ". I don't know if Windows or other platforms provide such a clock type. Any hints would be appreciated.

Even if we don't count some time while reporting we couldn't avoid to spend some time to make this counting possible. So the measure could not be completly reliable, but imo it could be acceptable compared to the time taken by the reporting.  I hope that the time spent to avoid counting the reporting would not be bigger than the time to report ;-)

Boost provides also a kind of stopwatches that are able to cumulate the samples and report only at the end of the program some statistical data, as min, max, mean ... This kind of watches are no subject to the time spent reporting, but cumulating the samples.

Thanks for signaling this issue.
Vicente