[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#44674: 28.0.50; Adding current-cpu-time for performance tests
From: |
Stefan Monnier |
Subject: |
bug#44674: 28.0.50; Adding current-cpu-time for performance tests |
Date: |
Mon, 16 Nov 2020 10:27:29 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
Philipp wrote:
> It might be beneficial to use the higher-resolution clock_gettime with
> CLOCK_PROCESS_CPUTIME_ID if available and only fall back to clock()
> otherwise.
>
> While there, consider also implementing a function to read the
> CLOCK_MONOTONIC clock – that should be preferred over the realtime
> clock for stopwatch-style measurements.
Given that we've lived without any of it for so many years, I'm not sure
it's worth the trouble. Also since I'm not familiar with any of those
interfaces, I'd welcome it if someone else could do that if
they're interested.
Eli said:
> AFAIU, using 'clock' here is not the best idea, as there are caveats wrt to
> calling 'system', and the origin of the returned value is not well defined
> to be portable.
What do you mean by "origin" and by "calling 'system'"?
Mattias added:
>> +The return value is a pair (CPU-TICKS . TICKS-PER-SEC).
> Perhaps not ideal to cons in a timing primitive where low overhead is
> called for.
I expect that the time it takes to perform the `funcall` to get to this
function is itself larger than the time it takes to run `Fcons`, so I'm
not too worried about this overhead.
> What about just returning an integer and have a different way to get
> at TICKS-PER-SEC?
I designed it this way to keep the change as simple as possible, but
yes, we could have two separate functions.
> Ideally the returned value should be a fixnum to minimise overhead, but it
> may restrict the range on 32-bit platforms.
`make_int` will return a fixnum when possible. Are you suggesting we
modulo-truncate the integer so it fits i a fixnum? I think that on
32bit platforms this will lose too much range (I guess we could divide
instead of modulo-truncate, and lose precision instead, tho). Not sure
it's worth the trouble, tho.
In my experience measuring CPU or wall clock time for things like
benchmarks is only meaningful if it's a non-trivial amount of time (like
0.1s or more), so the added cost of Fcons or allocating a bignum
is negligible.
Stefan
- bug#44674: 28.0.50; Adding current-cpu-time for performance tests, (continued)
- bug#44674: 28.0.50; Adding current-cpu-time for performance tests, Philipp Stephani, 2020/11/16
- bug#44674: 28.0.50; Adding current-cpu-time for performance tests, Eli Zaretskii, 2020/11/16
- bug#44674: 28.0.50; Adding current-cpu-time for performance tests, Philipp Stephani, 2020/11/16
- bug#44674: 28.0.50; Adding current-cpu-time for performance tests, Eli Zaretskii, 2020/11/16
- bug#44674: 28.0.50; Adding current-cpu-time for performance tests, Lars Ingebrigtsen, 2020/11/16
bug#44674: 28.0.50; Adding current-cpu-time for performance tests, Mattias Engdegård, 2020/11/16
bug#44674: 28.0.50; Adding current-cpu-time for performance tests,
Stefan Monnier <=
- bug#44674: 28.0.50; Adding current-cpu-time for performance tests, Mattias Engdegård, 2020/11/16
- bug#44674: 28.0.50; Adding current-cpu-time for performance tests, Eli Zaretskii, 2020/11/16
- bug#44674: 28.0.50; Adding current-cpu-time for performance tests, Eli Zaretskii, 2020/11/16
- bug#44674: 28.0.50; Adding current-cpu-time for performance tests, Andreas Schwab, 2020/11/16
- bug#44674: 28.0.50; Adding current-cpu-time for performance tests, Eli Zaretskii, 2020/11/16
bug#44674: 28.0.50; Adding current-cpu-time for performance tests, Stefan Monnier, 2020/11/16
bug#44674: 28.0.50; Adding current-cpu-time for performance tests, Eli Zaretskii, 2020/11/16
bug#44674: 28.0.50; Adding current-cpu-time for performance tests, Philipp Stephani, 2020/11/16
bug#44674: 28.0.50; Adding current-cpu-time for performance tests, Eli Zaretskii, 2020/11/16
bug#44674: 28.0.50; Adding current-cpu-time for performance tests, Stefan Monnier, 2020/11/16