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

[Noah Goldstein <goldstein.w.n@gmail.com>]

On Thu, Jan 12, 2023 at 12:32 PM Wilco Dijkstra via Libc-alpha
<libc-alpha@sourceware.org> wrote:
>
> Hi Zack,
>
> >> 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?
>
> Basically it is a lower overhead version of clock_get_time (CLOCK_MONOTONIC)
> so you can use it to benchmark even small bits of code (since it doesn't insert
> extra function calls or affect register allocation in a major way).
>
> We don't strictly need to scale the result, you could just subtract the counts.
> However it makes the result equivalent to clock_get_time and allows one to
> compute bytes copied/ns if needed or compare different CPUs.
>
> It's hard to account for the effects of interrupts or preemption. And GLIBC
> benchtests aren't all that smart either, so I often end up having to increase the
> iteration count to average out the OS effects (including frequency scaling).
> We could improve this, eg. take several samples at lower iteration counts
> and only report the fastest one.

If it's a long running benchmark (increased iteration count) then the
OS preemption
effect should scale up and the constant cost of the 2x function calls
/ going to the
OS for getting the time should scale down proportionally.

Maybe we just need two timer apis for `TIMING_NOW_LONG` and
`TIMING_NOW_SHORT`?

>
> Cheers,
> Wilco