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: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-11-11 20:22:47

----- Original Message ----- 
From: "John Bytheway" <jbytheway+boost_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Thursday, November 11, 2010 8:40 PM
Subject: Re: [boost] [Review] Formal Review of Proposed Boost.Chrono Library Starts TOMORROW

> On 11/11/10 09:54, vicente.botet wrote:

> 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.

Oh I forget to say that for thread_clock I use clock_gettime also with the id obtained with pthread_getcpuclockid.

>>> 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).

Yes this will be very useful. No, I could not include this kind in function in Boost.Chrono, but I encourage other to provide it :)

Vicente