[PATCH] benchtests: Restore the clock_gettime option

[Alexander Monakov]

On Wed, 20 May 2020, H.J. Lu wrote:

> On Tue, May 19, 2020 at 3:16 PM Alexander Monakov <amonakov@ispras.ru> wrote:
> >
> > On Tue, 19 May 2020, H.J. Lu wrote:
> >
> > > On Tue, May 19, 2020 at 2:18 PM Alexander Monakov <amonakov@ispras.ru> wrote:
> > > >
> > > >
> > > >
> > > > On Tue, 19 May 2020, H.J. Lu via Libc-alpha wrote:
> > > >
> > > > > commit 7621e38bf3c58b2d0359545f1f2898017fd89d05
> > > > > Author: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
> > > > > Date:   Tue Jan 29 17:43:45 2019 +0000
> > > > >
> > > > >     Add generic hp-timing support
> > > > >
> > > > > removed the clock_gettime option.  On x86, fewer cycles doesn't
> > > > > necessarily mean faster exection due to frequency drop.  We should
> > > > > restore the clock_gettime option.
> > > >
> > > > Can you please elaborate more which x86 CPUs you have in mind here,
> > > > as since Nehalem (2008) when invariant TSC was introduced, the rdtsc(p)
> > > > instructions count at a fixed rate rather than at CPU clock rate.
> > > > And before 2008, there were no turbo frequencies and no AVX frequency drop.
> > >
> > > https://stackoverflow.com/questions/56852812/simd-instructions-lowering-cpu-frequency
> >
> > I am well aware. Again: rdtsc does not count CPU cycles on recent Intel CPUs.
> > RDTSC reads a register that increments at a fixed rate. So its increment is
> > proportional to wall clock time. When a workload is causing a reduction in
> > actual CPU frequency, RDTSC increment frequency is not affected and so it
> > remains suitable for measuring the actual wall-clock time.
> >
> > Alexander
> 
> We'd like to have it as an option on x86.

Then I would suggest rewording the proposed commit message to explain that.
As written, commit message gives a misleading/wrong motivation.

Alexander