Re: timevar: further work

[Akim Demaille]

Hey!

> Le 10 oct. 2018 à 10:10, Bruno Haible <address@hidden> a écrit :
> 
> Hi Akim,
> 
>> With respect to precision:
> 
>>  - times returns a clock_t, in system dependent clock ticks.
>>    Resolution is unclear, but I think I understood from various
>>    place that it’s typically 1µs.
> 
> No, you can't assume that. You need to measure it. Here's what I get
> on today's mainstream architecture (Linux 4.x, x86_64 CPU from Intel):
> 
> $ ./measure 1000
> tms_utime: 0.000000
> monotonic: 0.000015

You’re right, I stayed at the level of the theoretical precision
rather than in practice.

> So, very obviously, the resolution of times() is [10] milliseconds (!).
[…]
> So, the resolution of getrusage() is 4 ms. Slightly better than times(),

I’m surprised by this.  I would have bet both shared the same
basic implementation.

> bit still orders of magnitude worse than CLOCK_MONOTONIC.



>> With respect to what you called multiplicity (i.e., time spent
>> in subprocesses or threads):
>> 
>> - getrusage offers two choices:
>>  - RUSAGE_SELF: the calling process and its threads.
>>  - RUSAGE_CHILDREN: main and subprocesses that have been wait’ed.
>>  - Linux offers RUSAGE_THREAD, which is just about the current
>>    thread.  I don’t think we care about this.
>>    (https://linux.die.net/man/2/getrusage)
> 
> Good. Do you want 'timevar' to support RUSAGE_SELF and RUSAGE_CHILDREN,
> at the user's choice, or do you want to pick one for the user?
> 
> In summary, I think the user needs to have the choice:
>  - For low-precision timings, offer getrusage with RUSAGE_CHILDREN or
>    optionally RUSAGE_SELF as an alternative.
>  - For high-precision timings, offer CLOCK_MONOTONIC and don't call
>    neither getrusage nor times (because the point of high-precision
>    timings is to have minimal system call overhead).
> 
> And this choice needs to be made at runtime. It would be silly to have
> to recompile a program just to measure longer vs. shorter tasks.

You lost me here.  CLOCK_MONOTONIC is about wall time, the ‘real’ time
(sorry Albert, I didn’t mean that), not time spend on the behalf of the
process.  Maybe there’s an API I missed?

I think that at this stage we want usr/sys via getrusage and wall via
CLOCK_MONOTONIC.  The choice between proper time and self+children
seems a reasonable option to offer, but if we are to keep just one,
I’d stick with the one we have currently: including subprocesses.