[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: |
Mattias Engdegård |
Subject: |
bug#44674: 28.0.50; Adding current-cpu-time for performance tests |
Date: |
Mon, 16 Nov 2020 17:14:16 +0100 |
16 nov. 2020 kl. 16.27 skrev Stefan Monnier <monnier@iro.umontreal.ca>:
> 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.
Perhaps, but the lower the overhead, the shorter the intervals that can
effectively be measured. It would be a shame to build pointless latency into
the calling interface from the get-go.
> `make_int` will return a fixnum when possible. Are you suggesting we
> modulo-truncate the integer so it fits i a fixnum?
As you say it's not worth doing so for 32 bits, but in case a full value would
require 64 bits, we should at least consider truncating it to 63.
The values returned from clock, clock_gettime etc are generally wrapping, which
means that the user would need to know how to mask the difference in case the
timer wraps during a measured interval. This can neatly be side-stepped by
providing a function for computing the duration from two sample points, eg,
(cpu-time-duration CPU-TIME-1 CPU-TIME-2)
which would apply the necessary modulo-reduction and return the duration in
seconds as a float. That way, we save the user the trouble to do
(/ (logand (- CPU-TIME-2 CPU-TIME-1)
(1- (ash 1 CPU-TIMER-BITS))
(float CPU-TIMER-FREQ))
and having to retrieve two system constants.
> 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.
Being able to measure short intervals without too much noise can be quite
useful. Of course, CPU time is sometimes measured with much less resolution
than real time which sets an effective lower limit; 100 Hz used to be the norm
but it should be better these days.
- 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, Mattias Engdegård, 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, 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
bug#44674: 28.0.50; Adding current-cpu-time for performance tests, Stefan Monnier, 2020/11/16