llvm dev - Jan 2016 - Proposal: Enable BUILD_SHARED_LIBS=ON by default for debug build.

Hello, 

 

I understand shared linked is currently a lot slower than static linked.

However, for debug build, where speed is not required. Shared link has 

A lot of advantage. 

 

Static linked clang/llvm on linux is 17G, shared build is only 1.5G. On a
mainstream 

linux host machine with 12G memory, only -j1 can be used to finish final
linking step. 

With -j8 the linux will link the linking. With 17G footprint, copying from
build folder

to install folder is also very slow. So it is very reasonable to set 

BUILD_SHARED_LIBS=ON as default for debug build because it would improve
usability

and performance. 

 

Thanks,

 

Yin 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160128/f1f3d6b4/attachment.html>

On Thu, Jan 28, 2016 at 2:34 PM, Yin Ma via cfe-dev <cfe-dev at
lists.llvm.org>
wrote:
> Hello,
>
>
>
> I understand shared linked is currently a lot slower than static linked.
>
> However, for debug build, where speed is not required. Shared link has
>
> A lot of advantage.
>
>
>
> Static linked clang/llvm on linux is 17G, shared build is only 1.5G.
>
Assuming you're talking about a debug build, you can probably get that down
a lot with at least -fdebug-types-section or with -gsplit-dwarf.

> On a mainstream
>
> linux host machine with 12G memory, only –j1 can be used to finish final
> linking step.
>
If you use Ninja, I believe it has a separate pool limit you can tweak for
linking (but, again, with -fdebug-types-section or -gsplit-dwarf, you might
make the link steps more palatable (-gsplit-dwarf is probably the
better/more important choice, though))

But I'd be surprised if the limit is that low - are you using gold? Or
binutils ld? Gold is a good/better choice here, and usually I only end up
using about a GB of RAM per linking process I Think.

> With –j8 the linux will link the linking. With 17G footprint, copying from
> build folder
>
> to install folder is also very slow.
>
Solid state, on spinning disks? Solid state would help a bit.

> So it is very reasonable to set
>
> BUILD_SHARED_LIBS=ON as default for debug build because it would improve
> usability
>
> and performance.
>
The thing is, the performance tradeoff also hits test execution time. At
least last time I checked (granted, on a 32 core, 64GB of RAM machine) the
build time improvement (on a clean build) with shared libs was not saved by
a single execution of the regression test suite (which took longer than the
savings). Let alone on an incremental build... if I remember my numbers
correctly.

Not sure whether it's the right call to change the default - people can
change their own settings easily enough.

- Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160128/4cca8af1/attachment.html>

Hi David,

 

I assume you have a powerful machine. Our drive space is on network mounted 

machined by IT department. The machine is default Ubuntu setup with 8 cores. 

Shared build is showing huge advantage due to size reduction. I will try those
two

debug options to see how it works. 

 

Thanks,

 

Yin

 

From: David Blaikie [mailto:dblaikie at gmail.com] 
Sent: Thursday, January 28, 2016 2:43 PM
To: Yin Ma
Cc: llvm-dev; cfe-dev
Subject: Re: [cfe-dev] Proposal: Enable BUILD_SHARED_LIBS=ON by default for
debug build.

 

 

 

On Thu, Jan 28, 2016 at 2:34 PM, Yin Ma via cfe-dev <cfe-dev at
lists.llvm.org <mailto:cfe-dev at lists.llvm.org> > wrote:

Hello, 

 

I understand shared linked is currently a lot slower than static linked.

However, for debug build, where speed is not required. Shared link has 

A lot of advantage. 

 

Static linked clang/llvm on linux is 17G, shared build is only 1.5G.

 

Assuming you're talking about a debug build, you can probably get that down
a lot with at least -fdebug-types-section or with -gsplit-dwarf.

 

On a mainstream 

linux host machine with 12G memory, only –j1 can be used to finish final linking
step.

 

If you use Ninja, I believe it has a separate pool limit you can tweak for
linking (but, again, with -fdebug-types-section or -gsplit-dwarf, you might make
the link steps more palatable (-gsplit-dwarf is probably the better/more
important choice, though))

But I'd be surprised if the limit is that low - are you using gold? Or
binutils ld? Gold is a good/better choice here, and usually I only end up using
about a GB of RAM per linking process I Think.

 

With –j8 the linux will link the linking. With 17G footprint, copying from build
folder

to install folder is also very slow. 

 

Solid state, on spinning disks? Solid state would help a bit.

 

So it is very reasonable to set 

BUILD_SHARED_LIBS=ON as default for debug build because it would improve
usability

and performance.


The thing is, the performance tradeoff also hits test execution time. At least
last time I checked (granted, on a 32 core, 64GB of RAM machine) the build time
improvement (on a clean build) with shared libs was not saved by a single
execution of the regression test suite (which took longer than the savings). Let
alone on an incremental build... if I remember my numbers correctly.

Not sure whether it's the right call to change the default - people can
change their own settings easily enough.

- Dave

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160128/56eb7d62/attachment.html>