llvm dev - Sep 2017 - Why are LLVM releases statically linked against LLVM libraries?

Sincere question!
I'm not at all suggesting this is the wrong choice or asking it to be
defended, just explained :)

Simply curious if anyone can speak as to the reasons for this
and perhaps give a sense of how strong these reasons are
or if they're just the tie-breaking reasons we came up with
because hosting /both/ seemed silly :P.
(or whatever the case may be)

I'll note the build system in general defaults to this behavior,
AFAIK it's not particular to releases, but I'm targeting releases
since in theory that's what users end up with-- the default
developer experience might have a slightly different story to tell.

As I understand it the many-shared-libraries build configuration isn't
supported,
so I think the primary "alternative" in terms of which is the default
would be using
and linking against libLLVM.

I can speculate the reasons from a technical standpoint and by
inferring from commit history...
but curious if there's a better answer to be had?

Thanks! :D

~Will

On 3 Sep 2017, at 02:41, Will Dietz via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> I can speculate the reasons from a technical standpoint and by
> inferring from commit history...
> but curious if there's a better answer to be had?
There’s a fairly noticeably performance improvement from static linking.  I
think last time I benchmarked it, building FreeBSD with dynamically linked clang
took around 20% longer than building with statically linked clang.  It’s less
clear how this differs when you have multiple parts of the toolchain sharing
LLVM libraries (clang, lld, perhaps other compilers).  There was some discussion
(I don’t remember the conclusions) of switching the tools in the FreeBSD base
system to use a dynamic libLLVM.so, because there’s a pretty noticeable
difference in binary size between static and dynamic clang + lldb + lld, and
it’s even greater if you start shipping libClang or libTooling-based tools.

Some back-of-the-envelope approximations indicate that you probably won’t win
back the performance from sharing, because both clang and lld have working sets
that are far greater than last-level caches on most systems and so the only wins
would be from sharing page-table entries (which only XNU does reliably) and from
sharing i-cache (which in C++ is unlikely, because the LLVM libraries are pretty
big and we’re unlikely to be in the same bits of the code for long enough for it
to matter.

David

2017-09-03 3:06 GMT-07:00 David Chisnall via llvm-dev <
llvm-dev at lists.llvm.org>:
> On 3 Sep 2017, at 02:41, Will Dietz via llvm-dev <llvm-dev at
lists.llvm.org>
> wrote:
> >
> > I can speculate the reasons from a technical standpoint and by
> > inferring from commit history...
> > but curious if there's a better answer to be had?
>
> There’s a fairly noticeably performance improvement from static linking.
> I think last time I benchmarked it, building FreeBSD with dynamically
> linked clang took around 20% longer than building with statically linked
> clang.  It’s less clear how this differs when you have multiple parts of
> the toolchain sharing LLVM libraries (clang, lld, perhaps other
> compilers).  There was some discussion (I don’t remember the conclusions)
> of switching the tools in the FreeBSD base system to use a dynamic
> libLLVM.so, because there’s a pretty noticeable difference in binary size
> between static and dynamic clang + lldb + lld, and it’s even greater if you
> start shipping libClang or libTooling-based tools.
>
> Some back-of-the-envelope approximations indicate that you probably won’t
> win back the performance from sharing, because both clang and lld have
> working sets that are far greater than last-level caches on most systems
> and so the only wins would be from sharing page-table entries (which only
> XNU does reliably) and from sharing i-cache (which in C++ is unlikely,
> because the LLVM libraries are pretty big and we’re unlikely to be in the
> same bits of the code for long enough for it to matter.
>
I'll add that if you add LTO in the mix, the difference in performance
between a lot of small shared libraries and a statically linked clang can
be even higher.

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