> On 24 Oct 2019, at 14:49, Alexey Dokuchaev <da...@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 <d...@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
signature.asc
Description: Message signed with OpenPGP