Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Visual C++ PGO linker memory usage

483 views
Skip to first unread message

Ted Mielczarek

unread,
May 16, 2013, 3:15:48 PM5/16/13
to Mozilla Platform Development
Hello friends,

TL;DR: PGO on MSVC is now opt-in per-source-directory.

Today I landed a patch[1] that significantly lowered the memory usage of
the Visual C++ linker during PGO builds, which has been a consistent
pain point for us. The ever-wonderful Ehsan got in touch with a VC++
program manager at Microsoft who got him in touch with some engineers
who offered some concrete proposals on how to mitigate our problem.

The crux of the workaround is that only source files compiled for PGO
usage (using -GL to enable link-time-codegen on MSVC) contribute
significantly to the linker's memory usage. The Microsoft engineer's
suggestion was to use a tool called pgomgr[2] to dump statistics about
what code is actually being exercised in our profiling scenario (and
thus most able to benefit from the optimizations) and identify code for
which we could disable PGO. After a bit of data-wrangling (details are
in the bug) we decided that the best solution would be to make PGO on
MSVC an opt-in optimization, so I picked an arbitrary threshold and
enabled PGO only in the directories that have significant amounts of
code run in our profiling scenario. Any new directory that needs PGO
enabled will need to have "MSVC_ENABLE_PGO := 1" in its Makefile to turn
it on.

A Try run of this patch showed promising results, significantly lowering
the linker memory usage and not regressing any Talos results. As an
additional bonus it seems to have significantly sped up the build time
for Windows PGO builds.

Longer-term this should buy us more time for a real solution, as new
directories won't automatically contribute to the problem. We heard from
Microsoft that they are working on a 64-to-32-bit cross-toolchain, which
is the only real silver bullet for this problem, but they don't have any
timeline to give us. Hopefully this work buys us enough time for that to
materialize without having to expend significant effort working against
our toolchain or disabling PGO.

Yrs,
-Ted

1. https://bugzilla.mozilla.org/show_bug.cgi?id=871712
2. http://msdn.microsoft.com/en-us/library/2kw46d8w%28v=vs.80%29.aspx

Mike Hommey

unread,
May 16, 2013, 4:48:48 PM5/16/13
to Ted Mielczarek, Mozilla Platform Development
On Thu, May 16, 2013 at 03:15:48PM -0400, Ted Mielczarek wrote:
> Longer-term this should buy us more time for a real solution, as new
> directories won't automatically contribute to the problem. We heard from
> Microsoft that they are working on a 64-to-32-bit cross-toolchain, which
> is the only real silver bullet for this problem, but they don't have any
> timeline to give us. Hopefully this work buys us enough time for that to
> materialize without having to expend significant effort working against
> our toolchain or disabling PGO.

They also mentioned having fixed some memory usage issues, so this also
will help in the meantime, provided they release these fixes some day.

Mike

Boris Zbarsky

unread,
May 16, 2013, 5:03:41 PM5/16/13
to
On 5/16/13 3:15 PM, Ted Mielczarek wrote:
> TL;DR: PGO on MSVC is now opt-in per-source-directory.

This is awesome. Thank you, Ehsan and Ted, for getting this sorted out!

-Boris

papa...@gmail.com

unread,
May 20, 2013, 6:04:24 PM5/20/13
to
Woohoo! Great.

Jonas Sicking

unread,
May 23, 2013, 8:06:02 PM5/23/13
to Boris Zbarsky, dev-platform
Yes, this is indeed great stuff! Thank you so much for your work!

/ Jonas
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
0 new messages