Re: Confusing Performance Numbers

[Phil Blundell <pb@pbcl.net>]

On Tue, 2013-11-12 at 15:31 +0000, Richard Purdie wrote:
> I also totalled the time in each task type, the output is below. The
> numbers there are interesting as the strip patch seems to add 100s to
> do_populate_sysroot. There doesn't seem to be a big difference in
> compile time.

That's probably to be expected: the amount of disk bandwidth you save by
not copying the symbols into the sysroot (and into sstate) is almost
certainly going to be outweighed by the time it takes to strip the files
in the first place.  So that set of numbers at least does seem
believable.

In theory at least, adding -Wl,-s to BUILD_LDFLAGS could give you the
stripping behaviour at lower cost since the linker could avoid writing
out the symbol table in the first place.  But I'm not entirely sure how
this option is actually implemented within the linker (or whether ld.bfd
and ld.gold do the same thing in that respect) and it's entirely
possible that it might be no better in practice.  

Using -march=native for natives is an interesting idea, though even if
this was a win on a single machine it might obviously be a net loss in
the presence of a shared sstate cache.  Of course, the vast majority of
-native binaries are run so seldom that their impact on the overall
build performance is going to be negligible: the ones that dominate are
going to be the toolchain.  One idea that I've seen suggested from time
to time (but never actually tried out) is that it might be a win under
some circumstances to do a 2-stage bootstrap of gcc-native and then use
that gcc-native to build gcc-cross as well as all other native packages.
If you were building everything from scratch every time then it's hard
to imagine this being a real benefit unless your distribution bundled
compiler was spectacularly rubbish, but if you assume that these gccs
will come out of sstate for most builds then it starts to seem more
plausible that this might be worth doing.

p.