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: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Mattias Engdegård <mattiase <at> acm.org>, Eli Zaretskii <eliz <at> gnu.org>, 44674 <at> debbugs.gnu.org
Subject: bug#44674: 28.0.50; Adding current-cpu-time for performance tests
Date: Mon, 16 Nov 2020 19:39:35 +0100

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

Previous Next

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