[llvm-dev] Why are LLVM releases statically linked against LLVM libraries?

[Mehdi AMINI via llvm-dev]

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>