[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: timevar: further work

From: Akim Demaille
Subject: Re: timevar: further work
Date: Wed, 10 Oct 2018 21:53:33 +0200


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]