This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Add cacos benchmark inputs

On 4 October 2013 22:50, Joseph S. Myers <> wrote:
> I think it's a mistake to do any sort of syncing of inputs that requires
> manual copying of data from one place to another.  That is, if you want to

Yes, I'm still trying to figure out the best way to represent inputs
that may be suitable for both types of tests.  One of the problems I'm
having is to make sure that I don't end up making the benchmark suite
a 'math benchmark suite'.

> use for benchmark inputs (bearing in mind that they are
> unrepresentative - so if you did some form of randomized benchmarking to
> get an overall score, rather than doing many runs with one input, then
> many with another inputs, with consequent branch prediction implications,
> then the unrepresentative inputs would need down-weighting, and probably

That would be necessary if these inputs have a really deviation from
the average case.  However in that case I would prefer to explicitly
mention that case separately, like we do for the slow multiple
precision paths.  Also, I think from a microbenchmark point of view it
would be much more useful to show the variation in performance than to
come up with a single average case number.  The current benchmark
output is not adequate for such an output, but that should be the end
goal IMO.  That obviously brings us to graphs, like WIll Newton and
Ondrej suggested in the past.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]