svn commit: r353937 - in head/share: man/man5 mk
Dimitry Andric
dim at FreeBSD.org
Sat Oct 26 14:34:22 UTC 2019
> On 24 Oct 2019, at 14:49, Alexey Dokuchaev <danfe at FreeBSD.org> wrote:
>
> On Wed, Oct 23, 2019 at 11:31:41AM -0700, Enji Cooper wrote:
>>> On Oct 23, 2019, at 10:02, Dimitry Andric <dim at freebsd.org> wrote:
>>> New Revision: 353937
>>> URL: https://svnweb.freebsd.org/changeset/base/353937
>>>
>>> Log:
>>> Build toolchain components as dynamically linked executables by default
>
> What are the benefits of the new order?
The advantages and disadvantages of dynamic linking are a contentious
and almost religious issue, so I hope you don't mind that I will not go
into this.
>>> In this day and age, we have boot environments, virtual machine
>>> snapshots, cloud backups, and other much more reliable methods to
>>> restore systems to working order. So I think the time is ripe to flip
>
> What about those of us who cannot use BEs, VMs, and other "cloudy" tech
> because, well, they might not work as well and reliably as one might think?
There are many possibilities, such as making backups, using
WITHOUT_SHARED_TOOLCHAIN (and hoping that you can compile/link your way
out of a botched installation), or even using NO_SHARED.
>> Using dynamic binaries instead of static binaries might actually regress
>> performance in a way you don't expect, depending on -j values, etc. Static
>> binaries avoid the dynamic linker, which (obviously) results in a perf hit
>> at scale [...]
>
> Very good point.
But if you take this point to its logical conclusion, then you should
link everything statically, and never use dynamic linking at all. :)
>> Did you calculate the perf trade offs for the static binaries at low -j vs
>> high -j, system and user time, etc?
>
> I'd like to know the answer to this question (and the results) as well.
I only tested -j24 on a 32-core system, but I could probably repeat the
experiment with lower and higher -j values:
* host system (and dynamic linker): head r346082 (2019-04-10)
* base/head checkout at r354065
* clang and lld compiled from r354065, dynamically linked:
text data bss dec hex filename
69007497 52320 290469 69350286 0x422338e bin-dynamic/cc
45708182 35280 320613 46064075 0x2bee1cb bin-dynamic/ld
* clang and lld compiled from r354065, statically linked:
text data bss dec hex filename
70828318 71656 2592977 73492951 0x46169d7 bin-static/cc
47533406 54776 2623121 50211303 0x2fe29e7 bin-static/ld
* built world with __MAKE_CONF and SRCCONF set to /dev/null, and CC,
CXX, CPP and LD set to point to either the dynamic or static binaries
* verified that the cross-tools stage did /not/ attempt to bootstrap the
compiler and linker
* repeated experiment 7 times, for each case
* measured real, user and system time of each experiment
Results for real time:
---------------------------------------------------------------------------
x static-real.txt
+ dynamic-real.txt
N Min Max Median Avg Stddev
x 7 1851.71 1892.11 1868.79 1868.6829 13.569253
+ 7 1882.95 1940.74 1912.9 1912.6886 17.510156
Difference at 95.0% confidence
44.0057 +/- 18.2444
2.35491% +/- 0.985013%
(Student's t, pooled s = 15.6641)
Results for user time:
---------------------------------------------------------------------------
x static-user.txt
+ dynamic-user.txt
N Min Max Median Avg Stddev
x 7 31734.75 32055.47 31983.16 31942.131 118.2333
+ 7 32957 33282.1 33224.25 33150.727 137.84805
Difference at 95.0% confidence
1208.6 +/- 149.569
3.7837% +/- 0.47584%
(Student's t, pooled s = 128.416)
Results for user time:
---------------------------------------------------------------------------
x static-sys.txt
+ dynamic-sys.txt
N Min Max Median Avg Stddev
x 7 2434.98 2661.22 2461.95 2516.3843 100.88134
+ 7 2545.07 2813.8 2655.65 2682.5243 116.80319
Difference at 95.0% confidence
166.14 +/- 127.11
6.60233% +/- 5.1964%
(Student's t, pooled s = 109.133)
So ~2.3% difference in real time, which is not too bad I think. There
are probably opportunities to improve the performance of the dynamic
linker, which would be beneficial to every program in the system.
-Dimitry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 223 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20191026/2d462227/attachment.sig>
More information about the svn-src-head
mailing list