Re: bug fix for hp-timing.h (aarch64)

["Zack Weinberg" <zack@owlfolio.org>]

On Thu, Jan 12, 2023, at 1:07 PM, Wilco Dijkstra wrote:
> Hi Zack,
>
>> I'm surprised to hear you say that.  To me, 16 seconds is an absurdly _long_
>> interval for use of hp-timing.h.  For anything longer than a few tens of
>> milliseconds, the overhead of two system calls is negligible, but both CPU
>> frequency changes and getting descheduled in the middle of the
>> measurement become serious concerns.  So it seems more appropriate to
>> me to use clock_gettime with a per-process or per-thread clock ID for
>> measurements on the scale of tens of seconds.
>
> On AArch64 the counter is absolutely solid - it's fixed frequency and system
> wide monotonically increasing. So there are no issues with varying clock
> frequency or rescheduling to a different core, you get elapsed time at
> nanosecond accuracy.

... but that's not what you _want_ for a benchmark!  You don't want the time to tick up while the benchmark process is preempted (not executing on _any_ core), for instance.  Or am I misunderstanding what this is used for?

zw