On 2012-10-11 4:34 PM, Mike Hommey wrote:
On Thu, Oct 11, 2012 at 02:26:33PM -0400, Rafael Ávila de Espíndola wrote:
On 10/11/2012 02:33 AM, Mike Hommey wrote:
On Wed, Oct 10, 2012 at 05:57:53PM -0400, Justin Lebar wrote:
By "turning off Linux PGO testing", you really mean "stop making and
distributing Linux PGO builds," right?
The main reason I'd want Linux PGO is for mobile. On desktop Linux,
most users (I expect) don't run our builds, so it's not a big deal if
they're some percent slower.
Many people have made claims about that at several different occasions.
Can we once and for all come up with actual data on that?
That being said, PGO on Linux is between 5 and 20% improvement on our
various talos tests. That's with the version of gcc we currently use,
which is 4.5. I'd expect 4.7 to do a better job even, especially if we
added lto to the equation (and since we are now building on x86-64
machines, we wouldn't have to worry about memory usage ; link time could
be a problem, though).
Also note that disabling PGO currently also means disabling the
optimizations we do on omni.ja (central directory optimizations and
reordering). This is somehow covered by bug 773171.
I wouldn't be surprised if most of the pgo benefit is because of bad
inline decisions by gcc. If we can narrow the gap by adding
MOZ_ALWAYS_INLINE, then maybe we can drop pgo.
A non-unsignificant part of the performance improvements PGO gives come
from code reordering to improve branch prediction. Presumably, we can
use NS_LIKELY/NS_UNLIKELY to improve some branches manually.
Don't both of these proposals map to tons of manual work? I'm not
convinced that doing either of those would necessarily be easier than
finding and fixing the PGO bug at hand.
Ehsan
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
