Re: [boost] [Review] Formal Review of Proposed Boost.Chrono Library Starts TOMORROW

Subject: Re: [boost] [Review] Formal Review of Proposed Boost.Chrono Library Starts TOMORROW
From: John Bytheway (jbytheway+boost_at_[hidden])
Date: 2010-11-11 14:40:58

On 11/11/10 09:54, vicente.botet wrote:
> From: "John Bytheway" <jbytheway+boost_at_[hidden]>
>> On 10/11/10 00:04, vicente.botet wrote:
<snip>
>> For example
>> 
>> uint64_t const big = uint64_t(1)<<62; typedef duration<uint64_t,
>> ratio<1, big>> D1; typedef duration<uint64_t, ratio<1, big-1>> D2; 
>> D1 d1(0); D2 d2(0); auto d = d1+d2;
>> 
>> Will the above compile?  > If so, what is the type of d?
> 
> No. there is an overflow. The following compile-time error is
> obtained:

Good.

>>>> What is its intended purpose?  It seems to violate the type
>>>> system somewhat by returning a double rather than an 'inverse
>>>> duration'.
>>> 
>>> What would you expect as result?
>> 
>> Unless you returned something from Boost.Units there really isn't
>> a sensible option (and I'm certainly not suggesting you return
>> something from Boost.Units).
> 
> You are right. Whithout the correct units the result has no sense.
> For coherency, I think that I should be forced to remove this
> overloading, and let Stopwatch make his internal computation.

Thanks; that makes me feel better :).

>>>> You seem to be guaranteeing that high_resolution_clock is a
>>>> typedef of one of the other two clocks?  Wouldn't it be better
>>>> to leave open the possibility that it uses some other, more
>>>> high-resolution clock?
>>> 
>>> Yes I could. I don't see nothing in the standard that forbids it.
>>> Do you have a better implementation for high-resolution_clock
>>> and for which platform? I could include it if you have one.
>> 
>> For Windows there's QueryPerformanceCounter and 
>> QueryPerformanceFrequency that people are always suggesting for use
>> in Boost.Timer.
> 
> Boost.chrono uses already them. I will add the following table as
> requested.
<snip>

Cool.

For POSIX process/thread times, I note the existence of
clock_gettime(CLOCK_PROCESS_CPUTIME_ID) and
clock_gettime(CLOCK_THREAD_CPUTIME_ID) which are possibly candidates for
the process / thread timings.  At the same time, their man page says
they're unreliable on SMP systems, so probably not useful.

>> I believe there are similar things on other platforms.  One thing
>> I would like is a common interface akin to libfftw's getticks.
>> (See the "Cycle Counters" part of
>> http://www.fftw.org/download.html).  This is also in arbitrary
>> units, not seconds, though, and I'm not sure how many of the
>> underlying APIs have a known compile-time precision.
> 
> Without the processor speed the getticks() function is not of utility
> for the Chrono framework. If the user know the processor speed in Mhz
> at compile-time s/he can define a cycle_count_clock in a simple way
> as follows:

Right; I see that.  My point was that the implementation of getticks
itself has lots of platform-specific code in it, and something
equivalent might be usefully added to Boost (but probably not in
Boost.Chrono).

>>> There is Boost.Stopwatch which will be reviewed 1Q/2Q 2011 that 
>>> should cover the needs. Please take a look at and let me know if
>>> you fid there what you are looking for.
>> 
>> I tried, but the documentation link on LibrariesUnderConstruction 
>> doesn't seem to work (I get a blank page).
> 
> I don't get  blank page. Please could you try
> http://svn.boost.org/svn/boost/sandbox/chrono/libs/stopwatches/doc/html/index.html

Yes, that works.  Thanks.

John