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] Converted benchmark to benchtest.

On 6 June 2014 01:24, OndÅej BÃlka <> wrote:
>>   "pthread_rwlock_test": {
>>    "rwlock": {
>>     "duration": 2.87958e+09,
>>     "iterations": 2.7688e+07,
>>     "max": 172.944,
>>     "min": 97.516,
>>     "mean": 104.001
>>    },
>>    "rdlock": {
>>     "duration": 2.88252e+09,
>>     "iterations": 2.7022e+07,
>>     "max": 252.66,
>>     "min": 101.541,
>>     "mean": 106.673
>>    }
>>   }
> It is that you must always look for ways that could make benchmark
> invalid.
> Also I noticed that this takes long to run, did you also noticed that?

The standard benchmarks run only for BENCH_DURATION time and the above
was for 1 second, so I'm not sure how I should be concluding whether
it 'takes long' or not.

> That is true to some extend, but lets assume that we check this patch in
> other way and commit your benchmark. Do you thing that next time when
> there comes a patch touching rdlocks somebody will do a comparison if
> nobody did it first time?

Why not?  That is the point of the microbenchmarks - if there is a
significant change in a function and there's a microbenchmark for it,
the submitter should post the before and after results of the change.
Since we don't have any disagreement over the approach and the
generated code also is not a problem (as you pointed out in your other
response) there should be no problem with getting the benchmark in and
letting Andi use it to compare the before and after results.

I don't even mind waiting for Andi to revert with results before
committing the benchmark if that's what you want.


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