[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: timevar: further work
From: |
Bruno Haible |
Subject: |
Re: timevar: further work |
Date: |
Wed, 10 Oct 2018 23:50:17 +0200 |
User-agent: |
KMail/5.1.3 (Linux/4.4.0-137-generic; KDE/5.18.0; x86_64; ; ) |
Hi Akim,
> 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.
OK.
> > 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.
A "jiffie" duration is 4 ms nowadays [1] but it was 10 ms many years ago [2].
Since the times() call produces its output in units of 1/HZ seconds and HZ
is a constant (defined to 100 in <sys/param.h>), the Linux or glibc
implementors could not change it.
[1]
https://unix.stackexchange.com/questions/51978/when-do-jiffies-increment-how-a-process-runs-in-a-jiffy
[2] https://elinux.org/Kernel_Timer_Systems
> > 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
> ...
> I think that at this stage we want usr/sys via getrusage and wall via
> CLOCK_MONOTONIC.
Ah, I was thinking we would need to distinguish two cases: low-precision
timings, for programs that run > 1 sec, and high-precision timings, for
programs that run < 1 sec. Yeah, probably we don't to distinguish them.
Just make sure that the user understands that the wall clock timings
have microsecond resolution wheras the user+system time values have
a lower resolutions. Since they are in the same line of output, it's
not obvious to understand.
What would be the best way to clarify this? By using an appropriate
number of decimal digits?
Execution times (seconds)
read : 0.091 (19%) usr 0.080 (80%) sys 0.090242 (18%)
wall
read: scan : 0.043 ( 9%) usr 0.080 (80%) sys 0.123492 (26%)
wall
read: parse : 0.056 (10%) usr 0.000 ( 0%) sys 0.052384 (10%)
wall
work : 0.333 (70%) usr 0.000 ( 0%) sys 0.353432 (71%)
wall
work: phase 1 : 0.301 (64%) usr 0.000 ( 0%) sys 0.307234 (64%)
wall
work: phase 2 : 0.139 (28%) usr 0.000 ( 0%) sys 0.144232 (29%)
wall
output : 0.043 ( 9%) usr 0.020 (20%) sys 0.040233 ( 8%)
wall
total time : 0.474 0.100 0.492343
Or by using column headers?
Execution times (seconds)
CPU user CPU system wall clock
(4 ms res.) (4 ms res.) (1 µs res.)
read : 0.091 (19%) 0.080 (80%) 0.090242 (18%)
read: scan : 0.043 ( 9%) 0.080 (80%) 0.123492 (26%)
read: parse : 0.056 (10%) 0.000 ( 0%) 0.052384 (10%)
work : 0.333 (70%) 0.000 ( 0%) 0.353432 (71%)
work: phase 1 : 0.301 (64%) 0.000 ( 0%) 0.307234 (64%)
work: phase 2 : 0.139 (28%) 0.000 ( 0%) 0.144232 (29%)
output : 0.043 ( 9%) 0.020 (20%) 0.040233 ( 8%)
total time : 0.474 0.100 0.492343
Bruno
- Re: timevar: further work, Akim Demaille, 2018/10/02
- Re: timevar: further work, Bruno Haible, 2018/10/04
- Re: timevar: further work, Akim Demaille, 2018/10/10
- Re: timevar: further work, Akim Demaille, 2018/10/10
- Re: timevar: further work, Bruno Haible, 2018/10/10
- Re: timevar: further work, Bruno Haible, 2018/10/10
- Re: timevar: further work, Akim Demaille, 2018/10/10
- Re: timevar: further work,
Bruno Haible <=
- Re: timevar: further work, Akim Demaille, 2018/10/11
- Re: timevar: further work, Bruno Haible, 2018/10/11
- Re: timevar: further work, Akim Demaille, 2018/10/11
- Re: timevar: further work, Akim Demaille, 2018/10/11
- Re: timevar: 1/3: expect that getrusage is available, Akim Demaille, 2018/10/12
- Re: timevar: 1/3: expect that getrusage is available, Bruno Haible, 2018/10/12
- Re: timevar: 1/3: expect that getrusage is available, Akim Demaille, 2018/10/13
- Re: timevar: 1/3: expect that getrusage is available, Bruno Haible, 2018/10/13
- Re: timevar: 2/3: improve the output format, Akim Demaille, 2018/10/12
- Re: timevar: 2/3: improve the output format, Bruno Haible, 2018/10/12