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

[Philipp Stephani <p.stephani2@gmail.com>]

Am Mo., 16. Nov. 2020 um 16:27 Uhr schrieb 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.

It's definitely not a pressing concern, but the current approach does
give wrong results if a leap second happens or on other occasions. See
e.g. https://go.googlesource.com/proposal/+/master/design/12914-monotonic.md
for why Go introduced monotonic clock measurements. Other languages
had the distinction between wall clocks and monotonic clocks for a
long time as well (e.g. Java System.nanoTime).

>  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.

I wouldn't mind doing it, if there's general agreement that it's worth having.
But it would really just be:
1. clock_gettime(CLOCK_MONOTONIC_ID)
2. check for errors
3. make_lisp_time