GNU bug report logs - #44674
28.0.50; Adding current-cpu-time for performance tests

Previous Next

Full log

View this message in rfc822 format

From: Mattias Engdegård <mattiase <at> acm.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 44674 <at> debbugs.gnu.org, Philipp Stephani <p.stephani2 <at> gmail.com>
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 <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.