nonsense benchtests results

[Paul Zimmermann]

       Dear Wilco,

thank you for your answer. I understand what I'm missing is how I can make and
use another trace. And where is the "workload trace for the float version"
located (I could not find it). I'd like to document this in benchtests/README.

Best regards,
Paul

PS: if traces can't have inputs that return NaN or infinity, maybe the
benchtests framework should check it?

> From: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
> Date: Wed, 29 Jul 2020 17:32:32 +0000
> 
> Hi Paul,
> 
> > I'd like to measure the reciprocal-throughput and latency of sin, exp, pow,
> > both in single, double and quadruple precision.
> 
> Ideally we need representative traces for that. You could reuse the workload
> traces from the float version if you just want to do a quick test. You can find
> a few more traces here:
> 
> https://github.com/ARM-software/optimized-routines/tree/master/math/test/traces
> 
> > There is the ##name: workload-<name> documented in benchtests/README for that
> > (apparently, <name> is not used anywhere).
> 
> It's just a label for the json output so you can add traces from several
> workloads.
> 
> > I thus added ## name: workload-spec2017.wrf (adapted) in sinf-inputs,
> > expf-inputs, powf-inputs, and similar files for binary64 and binary128.
> 
> And you added the actual traces from the float versions too?
> 
> > However, for binary64 I get nonsense (for "sin" I tried also without "adapted",
> > and in both cases the reciprocal-throughput and latency are much too big, and
> > for "exp" the latency is smaller than the reciprocal-throughput):
> 
> If you don't use a proper trace then the latency number will be wrong. To create
> a dependency the benchmark multiplies the previous input by zero and adds it to
> the next input of the trace. So traces can't have inputs that return NaN or infinity,
> otherwise all subsequent inputs just test NaN!
> 
> Cheers,
> Wilco