search for: thousandsd

Not going into all the detail, but from my side the big question is whether the benchmarks inner loop is small/fine grained enough that stabilization with google benchmark doesn't lead to dozens of seconds benchmark runtimes. Given that you typically see thousandsd or millions of invocations for small functions... > On May 29, 2018, at 2:06 PM, Michael Kruse via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Thanks for your remarks. > > 2018-05-27 5:19 GMT-05:00 Dean Michael Berris <dean.berris at gmail.com>: >> I think y...

...llvm.org> wrote: > Not going into all the detail, but from my side the big question is > whether the benchmarks inner loop is small/fine grained enough that > stabilization with google benchmark doesn't lead to dozens of seconds > benchmark runtimes. Given that you typically see thousandsd or millions of > invocations for small functions... > Google benchmarks executes the kernel at max 1e9 times or until CPU time is greater than the minimum time or the wallclock time is 5x minimum time, by default min time is 0.5s but we can change it using "MinTime(X)" or "--...

Thanks for your remarks. 2018-05-27 5:19 GMT-05:00 Dean Michael Berris <dean.berris at gmail.com>: > I think you might run into artificial overhead here if you’re not careful. In particular you might run into: > > - Missed in-lining opportunity in the benchmark. If you expect the kernels to be potentially inlined, this might be a problem. For the kind of benchmarks we have in

> On 26 May 2018, at 06:09, Michael Kruse via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > 2018-05-25 13:49 GMT-05:00 Pankaj Kukreja via llvm-dev > <llvm-dev at lists.llvm.org>: >> Hi, >> I am adding some benchmarks to the test-suite as a part of my GSoC project. >> I am planning to use the google benchmark library on some benchmarks. I >> would