[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 10:10:14 +0200 |
User-agent: |
KMail/5.1.3 (Linux/4.4.0-137-generic; KDE/5.18.0; x86_64; ; ) |
Hi Akim,
> With respect to wall clock:
>
> - nothing in getrusage. You suggest gettimeofday, but it’s
> not monotonic, clock_gettime(CLOCK_MONOTONIC,…) is a better
> option.
OK, point taken.
> 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
$ ./measure 10000
tms_utime: 0.000000
monotonic: 0.000064
$ ./measure 100000
tms_utime: 0.000000
monotonic: 0.001127
$ ./measure 1000000
tms_utime: 0.010000
monotonic: 0.011327
$ ./measure 3000000
tms_utime: 0.020000
monotonic: 0.023167
$ ./measure 10000000
tms_utime: 0.050000
monotonic: 0.049540
So, very obviously, the resolution of times() is 20 milliseconds (!).
> - getrusage: 1µs on modern platforms, possibly 1ms
> (https://stackoverflow.com/a/12480485/1353549)
1µs on modern platforms? No. Again, you need to measure it.
$ ./measure2 1000
tms_utime: 0.000000
monotonic: 0.000021
resources: 0.000000
$ ./measure2 10000
tms_utime: 0.000000
monotonic: 0.000131
resources: 0.000000
$ ./measure2 100000
tms_utime: 0.000000
monotonic: 0.000573
resources: 0.000000
$ ./measure2 1000000
tms_utime: 0.010000
monotonic: 0.011352
resources: 0.012000
$ ./measure2 3000000
tms_utime: 0.030000
monotonic: 0.036984
resources: 0.032000
$ ./measure2 10000000
tms_utime: 0.040000
monotonic: 0.040968
resources: 0.040000
$ ./measure2 500000
tms_utime: 0.000000
monotonic: 0.001559
resources: 0.000000
$ ./measure2 700000
tms_utime: 0.000000
monotonic: 0.008029
resources: 0.008000
$ ./measure2 600000
tms_utime: 0.000000
monotonic: 0.007116
resources: 0.008000
$ ./measure2 1100000
tms_utime: 0.010000
monotonic: 0.012702
resources: 0.012000
$ ./measure2 500000
tms_utime: 0.000000
monotonic: 0.005821
resources: 0.004000
So, the resolution of getrusage() is 4 ms. Slightly better than times(),
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.
Bruno
measure.c
Description: Text Data
measure2.c
Description: Text Data
- 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 <=
- Re: timevar: further work, Bruno Haible, 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, 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