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

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

Hi Noah,

>> Many benchtests run a fixed number of iterations on varying inputs (eg.
>> string of size 1 vs 10000), so you wouldn't statically know which timer to use.
>> Targets that have timer overflow issues (eg. Alpha) don't use it at all in the
>> benchtests.
>
> You could probably estimate with a static number of iterations but payloads
> can be order of magnitude different i.e long strstr inputs vs short
> memset.

Yes, the iteration count remains fixed for all subtests while the inputs (and time
taken) vary by several orders of magnitude. So a single benchmark could report
inaccurate results on small inputs due to not running long enough and on large
inputs due to running for too long...

> How about then 3 APIs?
>
> `TIMING_NOW` -> statically choose `TIMING_NOW_SHORT` vs `TIMING_NOW_LONG`
> based on iter count, then explicit timers?

I'm still not sure what you're trying to solve here - the underlying problem is not
the timers but the fixed iteration counts. We could scale iteration counts based on
input size or the time it takes for that input.

Cheers,
Wilco