Add nanobench, a fresh look at our microbenchmark harness.

Add nanobench, a fresh look at our microbenchmark harness.

out/Release/nanobench runs 4-5x faster on my Z620 and ~2x faster on my N5 than out/Release/bench with the same configs.

(Debug isn't really comparable.  I haven't added the Debug -> single loop check.)

BUG=skia:

[djsollen, 2014-06-25 19:52:40]

is this something you want to submit now or was this just FYI?  I think this has
real potential as a replacement for our current bench logic.

https://codereview.chromium.org/347443002/diff/90005/gyp/bench.gyp
File gyp/bench.gyp (right):

https://codereview.chromium.org/347443002/diff/90005/gyp/bench.gyp#newcode14
gyp/bench.gyp:14: 'skia_lib.gyp:skia_lib',
if skia_lib is pulled in by the bench gypi then we can remove it from here as
well.

[tfarina, 2014-06-25 20:06:25]

https://codereview.chromium.org/347443002/diff/90005/gyp/bench.gyp
File gyp/bench.gyp (right):

https://codereview.chromium.org/347443002/diff/90005/gyp/bench.gyp#newcode40
gyp/bench.gyp:40: '../bench/nanobench.cpp',
NanoBenchMain.cpp?

otherwise can it be either nanobench_main.cpp or nanobenchmain.cpp

[mtklein, 2014-06-25 20:28:08]

Yeah, I figure we land this as a place to iterate new ideas, then just plop all
this code into bench when we're satisfied that nanobench is working and better.

https://codereview.chromium.org/347443002/diff/90005/gyp/bench.gyp
File gyp/bench.gyp (right):

https://codereview.chromium.org/347443002/diff/90005/gyp/bench.gyp#newcode14
gyp/bench.gyp:14: 'skia_lib.gyp:skia_lib',
On 2014/06/25 19:52:40, djsollen wrote:
> if skia_lib is pulled in by the bench gypi then we can remove it from here as
> well.

Let me hold off on this for another CL.  I actually would prefer to reorganize
our GYPs pretty much the other way, so that each of these binaries could build
as an empty but functioning shell app if you commented out the includes.  It'd
be nice if the tool specified the tool's deps and the include brought in the
include's deps.

https://codereview.chromium.org/347443002/diff/90005/gyp/bench.gyp#newcode40
gyp/bench.gyp:40: '../bench/nanobench.cpp',
On 2014/06/25 20:06:25, tfarina wrote:
> NanoBenchMain.cpp?
> 
> otherwise can it be either nanobench_main.cpp or nanobenchmain.cpp

I prefer nanobench.cpp.  It compiles into a binary named nanobench.  There's no
Nanobench class to collide with.  Why complicate things?

[mtklein, 2014-06-25 20:55:02]

Whelp, Derek's abandoned me for a vacation.  Just going to land this.

[mtklein, 2014-06-25 20:55:12]

lgtm

[commit-bot: I haz the power, 2014-06-25 20:55:49]

CQ is trying da patch. Follow status at
 https://skia-tree-status.appspot.com/cq/mtklein@chromium.org/347443002/90005

[commit-bot: I haz the power, 2014-06-25 21:08:04]

Change committed as f372321de3d4183de5b9ca436e677e471e358f31

[tfarina, 2014-06-25 21:08:04]

https://codereview.chromium.org/347443002/diff/90005/gyp/bench.gyp
File gyp/bench.gyp (right):

https://codereview.chromium.org/347443002/diff/90005/gyp/bench.gyp#newcode40
gyp/bench.gyp:40: '../bench/nanobench.cpp',
On 2014/06/25 20:28:08, mtklein wrote:
> On 2014/06/25 20:06:25, tfarina wrote:
> > NanoBenchMain.cpp?
> > 
> > otherwise can it be either nanobench_main.cpp or nanobenchmain.cpp
> 
> I prefer nanobench.cpp.  It compiles into a binary named nanobench.  There's
no
> Nanobench class to collide with.  Why complicate things?

I don't understand why you call naming a file nanobench_main.cpp or
nanobenchmain.cpp, complicate anything. If you come later and add a class
NanoBench then that will complicate things. That is what already happens with
dump_record.

[mtklein, 2014-06-25 21:25:39]

> I don't understand why you call naming a file nanobench_main.cpp or
> nanobenchmain.cpp, complicate anything. If you come later and add a class
> NanoBench then that will complicate things. That is what already happens with
> dump_record.

Yeah, I agree.  If we add a class NanoBench, that complicates things, and we can
rename files then.  But that's not happened yet, or even planned to happen.  I'd
prefer not to guard against or even really think about problems we may not have.
 Some problems need thinking ahead to avoid, but that's not usually true of
software.