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

[Wilco Dijkstra <Wilco.Dijkstra@arm.com>]

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.

Cheers,
Wilco