On 2013-01-31 11:03 AM, Till Schneidereit wrote:
On Thu, Jan 31, 2013 at 4:42 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com> wrote:
On 2013-01-31 10:33 AM, Till Schneidereit wrote:
In the long run, 1 and 3 are the same. If we know we're going to turn
it off, why not bite the bullet and do it now?
Because we're still missing plenty of optimizations in our code
to be fast in microbenchmarks. It would be quite huge pr loss if we
suddenly
were 10-20% slower in benchmarks.
But we're getting better (that last spike is because bz managed to
effectively optimize out one test).
http://graphs.mozilla.org/graph.html#tests=[[73,1,1]]&sel=none&displayrange=365&datatype=running
Do we think the planned optimizations cause the gains through PGO to
be less pronounced? If not, then slowdown in benchmarks and associated
PR loss would be the same whenever we finally pulled the plug on PGO,
right?
I'm not sure what you mean. If we get 10% slower in Dromaeo by disabling
PGO and take a patch which makes us 20% faster regardless of PGO, then we
should expect an approximate 10% win as a result. But generally, the game
of trying to beat the compiler in its optimizations is futile, since they
can outsmart most programmers on their worst day. :-)
Sure. What I was asking is precisely if the optimizations we're
betting on will have the property of not being affected by PGO. If we
take a patch now that makes us 10% faster with PGO enabled and then
later lose 10% by switching off PGO, then the PR effect will be the
same as switching off PGO right now. If, OTOH, we switch off PGO while
at the same time pushing patches that get us back all of the
performance we lost through it, we shouldn't have any PR fallout at
all.
The optimizations that we usually work on are orthogonal to the
optimizations performed by the PGO compiler.
Cheers,
Ehsan
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
