On 2013-01-22 5:27 PM, Mike Hommey wrote:
FWIW, IIRC my experiments last time we had this problem, LTCG alone
accounts for less than a third of the performance boost we get from
PGO on Talos.
Did you happen to measure how big the linker got in memory doing only LTCG?
joe
On Wed, Jan 23, 2013 at 03:38:05PM -0500, Joe Drew wrote:
On 2013-01-22 5:27 PM, Mike Hommey wrote:
FWIW, IIRC my experiments last time we had this problem, LTCG alone
accounts for less than a third of the performance boost we get from
PGO on Talos.
Did you happen to measure how big the
On 2013-01-23 3:38 PM, Joe Drew wrote:
On 2013-01-22 5:27 PM, Mike Hommey wrote:
FWIW, IIRC my experiments last time we had this problem, LTCG alone
accounts for less than a third of the performance boost we get from
PGO on Talos.
Did you happen to measure how big the linker got in memory
Status update #3:
It seems like with PGO disabled for all of the above modules, we've now
decreased the linker max vmem size by about 500MB, which is nice. There is
one PGO build bustage
https://tbpl.mozilla.org/php/getParsedLog.php?id=19006659tree=Mozilla-Inbound
which has been re-triggered,
On Tue, Jan 22, 2013 at 7:35 AM, Mike Hommey m...@glandium.org wrote:
On Tue, Jan 22, 2013 at 01:30:50PM +0100, Mike Hommey wrote:
On Mon, Jan 21, 2013 at 11:32:34PM -0500, Ehsan Akhgari wrote:
Second status update:
The numbers from disabling PGO on image, accessible and webrtc are
How are the perf numbers looking?
One of the reasons for asking is that I expect RDF to be part of the
startup and window-open codepaths, at least.
I'm not overly concerned, but wanted to make sure we look.
Axel
On 22.01.13 15:06, Ehsan Akhgari wrote:
Status update #3:
It seems like with
On 1/22/2013 9:28 AM, Axel Hecht wrote:
How are the perf numbers looking?
One of the reasons for asking is that I expect RDF to be part of the
startup and window-open codepaths, at least.
I would not expect PGO to optimize any of the RDF code for speed, even
if they were in the startup
On 22/01/2013 15:36, Benjamin Smedberg wrote:
On 1/22/2013 9:28 AM, Axel Hecht wrote:
How are the perf numbers looking?
One of the reasons for asking is that I expect RDF to be part of the
startup and window-open codepaths, at least.
I would not expect PGO to optimize any of the RDF code for
On 2013-01-22 9:45 AM, Marco Bonardo wrote:
On 22/01/2013 15:36, Benjamin Smedberg wrote:
On 1/22/2013 9:28 AM, Axel Hecht wrote:
How are the perf numbers looking?
One of the reasons for asking is that I expect RDF to be part of the
startup and window-open codepaths, at least.
I would not
OK, everyone. Both mozilla-central and mozilla-inbound are *temporarily*
reopened now. Please be gentle.
Cheers,
--
Ehsan
http://ehsanakhgari.org/
On Tue, Jan 22, 2013 at 9:06 AM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote:
Status update #3:
It seems like with PGO disabled for all of the
On Wed, Jan 23, 2013 at 4:31 AM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote:
But note that unless a given code path is examined throughout the
profiling phase of a PGO build, PGO will probably have negligible effect on
it, if any. The PGO compiler looks for hot code paths and tries to
On 2013-01-22 4:40 PM, Robert O'Callahan wrote:
On Wed, Jan 23, 2013 at 4:31 AM, Ehsan Akhgari ehsan.akhg...@gmail.com
mailto:ehsan.akhg...@gmail.com wrote:
But note that unless a given code path is examined throughout the
profiling phase of a PGO build, PGO will probably have
On 21/01/2013 21:47, Ehsan Akhgari wrote:
1. mozilla-central/inbound will remain closed to all check-ins except
the ones that do not add any code which gets linked into libxul on Windows.
Both inbound and central are APPROVAL REQUIRED as of now, any patches
that don't touch libxul can land
Exactly what control do we have over what gets PGOed? In particular:
1) Are we able to exclude particular object files or libraries from PGO
when we link libxul, reducing PGO memory usage for the final link? I think
you said yes on IRC.
2) Are we able to collect a set of object files, link them
On Tue, Jan 22, 2013 at 10:52:39AM +1300, Robert O'Callahan wrote:
Exactly what control do we have over what gets PGOed? In particular:
1) Are we able to exclude particular object files or libraries from PGO
when we link libxul, reducing PGO memory usage for the final link? I think
you said
On Mon, Jan 21, 2013 at 10:56:28PM +0100, Mike Hommey wrote:
On Tue, Jan 22, 2013 at 10:52:39AM +1300, Robert O'Callahan wrote:
Exactly what control do we have over what gets PGOed? In particular:
1) Are we able to exclude particular object files or libraries from PGO
when we link
Status update: we have landed three patches on mozilla-inbound which
disable PGO on the following directories (rdf/, image/ and accessible/)
and I have triggered PGO builds on top of them to see how much they can
shave off of the linker's vmem usage. Randel is also working on taking
some
Second status update:
The numbers from disabling PGO on image, accessible and webrtc are in, and
the linker max vmem size is down by only ~200MB, which is quite
disappointing, especially since according to Randell, putting webrtc
outside of libxul should buy us something around 600MB...
So, as
18 matches
Mail list logo
