bug#44674: 28.0.50; Adding current-cpu-time for performance tests

[Mattias Engdegård]

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.