On 1/31/13 10:33 AM, Till Schneidereit wrote:
Do we think the planned optimizations cause the gains through PGO to
be less pronounced?
It... depends. There are a few things at play here.
First of all, our current profiling at least for DOM and layout stuff is
largely looking for the wallet where the light is good, that is to say
happening on Mac. Which happens to be the one desktop platform on which
we don't do PGO.
As a result, code micro-optimized based on those profiling results tends
to inline a lot of things (in many cases forcing inlining via
MOZ_ALWAYS_INLINE where the compiler wasn't otherwise doing it) and hope
for the best. This works pretty well for microbenchmarks; how it works
at scale is an interesting question that we don't have a great answer to
yet because we don't have good things to measure. The flip side of that
is that we've been a bit more resistant to the "write the code and let
PGO sort it out" approach some have advocated, so turning off PGO won't
be a total disaster for such code.
Second, in any testcase that involves both jitcode and C++ code, turning
off PGO will only affect the C++ code, of course. So to the extent that
we speed up the C++ parts of the app relative to the jitcode, turning
off PGO becomes less of a hit in testcases that involve both. Of course
as we optimize the JIT the balance swings in the other direction.
The real benefit of PGO is its ability to somewhat easily optimize the
actual workload you care about instead of microbenchmarks.... For
microbenchmarks proper we can always make them faster manually; the
question is at what cost.
If not, then slowdown in benchmarks and associated
PR loss would be the same whenever we finally pulled the plug on PGO,
right?
Even if we posit the slowdown is the same, the PR loss is not.
Say browser A takes time T to run a test, browser B takes time 1.2T and
browser C takes time 0.8T.
Say browsers B and C both suffer a 10% regression on that test. Now the
times are:
A: T, B: 1.32T, C: 0.88T
From a PR point of view, the key part is that browser B is now 30%
slower than A, but C is still 12% faster. So it's not clear to me that
there would be any particularly bad PR for C at all.
-Boris
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
