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

[Stefan Monnier <monnier@iro.umontreal.ca>]

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