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

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>

On 1/28/16 4:00 PM, Yin Ma via cfe-dev wrote:
> 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.
It helps a lot to build on a non-NFS scratch disk.  Is your /tmp network 
mounted too? If not, I'd suggest building there.


Jon
>
> Shared build is showing huge advantage due to size reduction. I will try
> those two
>
> debug options to see how it works.
>
> Thanks,
>
> Yin
>

-- 
Jon Roelofs
jonathan at codesourcery.com
CodeSourcery / Mentor Embedded

On Thu, Jan 28, 2016 at 3:06 PM, Jonathan Roelofs <jonathan at
codesourcery.com
> wrote:
>
>
> On 1/28/16 4:00 PM, Yin Ma via cfe-dev wrote:
>
>> 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.
>>
>
> It helps a lot to build on a non-NFS scratch disk.  Is your /tmp network
> mounted too? If not, I'd suggest building there.
>
Yeah, building on a network attached storage would be pretty painful, I
imagine.

You can of course use a shared build yourself, it may be better for your
use/scenarios of course - I'm just pointing out that there's lots of us
for
which it isn't the best option, enough so that I wouldn't be confident
about changing the default.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160128/9fcfdaa4/attachment-0001.html>