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. > > Ehsan > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
