Re: svn commit: r353937 - in head/share: man/man5 mk
On Tue, Oct 29, 2019 at 08:04:07AM +0100, Dimitry Andric wrote: > On 27 Oct 2019, at 17:59, Alexey Dokuchaev wrote: > > > > On Sat, Oct 26, 2019 at 04:34:14PM +0200, Dimitry Andric wrote: > ... > >> I only tested -j24 on a 32-core system, but I could probably repeat the > >> experiment with lower and higher -j values: [...] > >> > >> So ~2.3% difference in real time, which is not too bad I think. > > > > Well, I'd say it's acceptable. :-/ > > I also tested at low (-j4) and high (-j32) levels. It turns out that at > low -j levels, the difference is less pronounced, just ~1.1% in real > time. And at high -j levels, it is more pronounced, ~4.3% in real time. > > Note also that at high -j levels, the difference in system time seems > to get more influence, e.g. at low -j the difference is ~4.5%, while at > high -j the difference is ~7.2%. I guess it is because dynamic linking > uses more syscalls. Yeah, it would be definitely nice if we could optimize runtime linker. Thanks for conducting these tests by the way, much appreciated, Dimitry! ./danfe ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r353937 - in head/share: man/man5 mk
On 27 Oct 2019, at 17:59, Alexey Dokuchaev wrote: > > On Sat, Oct 26, 2019 at 04:34:14PM +0200, Dimitry Andric wrote: ... >> I only tested -j24 on a 32-core system, but I could probably repeat the >> experiment with lower and higher -j values: [...] >> >> So ~2.3% difference in real time, which is not too bad I think. > > Well, I'd say it's acceptable. :-/ I also tested at low (-j4) and high (-j32) levels. It turns out that at low -j levels, the difference is less pronounced, just ~1.1% in real time. And at high -j levels, it is more pronounced, ~4.3% in real time. Note also that at high -j levels, the difference in system time seems to get more influence, e.g. at low -j the difference is ~4.5%, while at high -j the difference is ~7.2%. I guess it is because dynamic linking uses more syscalls. At -j4: Results for real time: --- x j4-static-real.txt + j4-dynamic-real.txt N Min MaxMedian AvgStddev x 7 5508.58 5548.05 5533.25 5530.2829 12.323855 + 7 5514.685660.1 5591.25 5593.5143 59.98042 Difference at 95.0% confidence 63.2314 +/- 50.4309 1.14337% +/- 0.912329% (Student's t, pooled s = 43.2985) Results for user time: --- x j4-static-user.txt + j4-dynamic-user.txt N Min MaxMedian AvgStddev x 7 19525.34 19607.74 19593.1 19582.78 29.037717 + 7 20178.84 20348.11 20214.28 20235.057 57.31409 Difference at 95.0% confidence 652.277 +/- 52.9155 3.33087% +/- 0.272077% (Student's t, pooled s = 45.4318) Results for system time: --- x j4-static-sys.txt + j4-dynamic-sys.txt N Min MaxMedian AvgStddev x 7 1622.63 1634.98 1629.87 1629.1229 4.7234017 + 7 1672.25 1722.23 1704.49 1703.1729 15.724862 Difference at 95.0% confidence 74.05 +/- 13.5224 4.54539% +/- 0.833228% (Student's t, pooled s = 11.6099) At -j32: Results for real time: --- x j32-static-real.txt + j32-dynamic-real.txt N Min MaxMedian AvgStddev x 7 1689.19 1735.36 1707.32 1707.8471 16.500078 + 7 1754.98 1812.57 1777.96 1781.6329 19.554159 Difference at 95.0% confidence 73.7857 +/- 21.0718 4.32039% +/- 1.25627% (Student's t, pooled s = 18.0917) Results for user time: --- x j32-static-user.txt + j32-dynamic-user.txt N Min MaxMedian AvgStddev x 7 38545.36 38802.6 38609.87 38641.009 105.11904 + 7 39430.93 39924.98 39856.91 39769.979 185.3612 Difference at 95.0% confidence 1128.97 +/- 175.5 2.92169% +/- 0.457446% (Student's t, pooled s = 150.68) Results for system time: --- x j32-static-sys.txt + j32-dynamic-sys.txt N Min MaxMedian AvgStddev x 7 2752.81 2809.97 2781.46 2781.4986 21.86523 + 7 2906.22 3151.93 2932.59 2981.5757 103.79842 Difference at 95.0% confidence 200.077 +/- 87.3629 7.19314% +/- 3.15079% (Student's t, pooled s = 75.0073) -Dimitry signature.asc Description: Message signed with OpenPGP
Re: svn commit: r353937 - in head/share: man/man5 mk
On Sat, Oct 26, 2019 at 04:34:14PM +0200, Dimitry Andric wrote: > > On 24 Oct 2019, at 14:49, Alexey Dokuchaev wrote: > > 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. OK. :-) > > 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. WITHOUT_SHARED_TOOLCHAIN sounds good, I hope it won't go away one day. > > Very good point. [about regressed performance] > > But if you take this point to its logical conclusion, then you should > link everything statically, and never use dynamic linking at all. :) Toolchain is special: many people prefer (or have to) build their ports and stuff; even those who prefer binary packages may need to test their ports in a tinderbox or p*re. In other words, I don't mind Firefox being dynalinked because I launch it once a month, contrary to the compiler. > I only tested -j24 on a 32-core system, but I could probably repeat the > experiment with lower and higher -j values: [...] > > So ~2.3% difference in real time, which is not too bad I think. Well, I'd say it's acceptable. :-/ > There are probably opportunities to improve the performance of the > dynamic linker, which would be beneficial to every program in the > system. Now that's a good point; I look forward to it! Thanks for replying, ./danfe ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r353937 - in head/share: man/man5 mk
> On 24 Oct 2019, at 14:49, Alexey Dokuchaev wrote: > > On Wed, Oct 23, 2019 at 11:31:41AM -0700, Enji Cooper wrote: >>> On Oct 23, 2019, at 10:02, Dimitry Andric 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: textdata bssdec hex filename 69007497 52320290469 69350286 0x422338e bin-dynamic/cc 45708182 35280320613 46064075 0x2bee1cb bin-dynamic/ld * clang and lld compiled from r354065, statically linked: textdata bssdec 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 MaxMedian AvgStddev x 7 1851.71 1892.11 1868.79 1868.6829 13.569253 + 7 1882.95 1940.741912.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 MaxMedian AvgStddev 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 MaxMedian AvgStddev x 7 2434.98 2661.22 2461.95 2516.3843 100.88134 + 7 2545.072813.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
Re: svn commit: r353937 - in head/share: man/man5 mk
On Wed, Oct 23, 2019 at 11:31:41AM -0700, Enji Cooper wrote: > > On Oct 23, 2019, at 10:02, Dimitry Andric 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? > > Summary: > > Historically, we have built toolchain components such as cc, ld, etc as > > statically linked executables. One of the reasons being that you could > > sometimes save yourself from botched upgrades, by e.g. recompiling a > > "known good" libc and reinstalling it. > > 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? > 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. > 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. ./danfe ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r353937 - in head/share: man/man5 mk
On Wed, Oct 23, 2019 at 05:02:45PM +, Dimitry Andric wrote: > Author: dim > Date: Wed Oct 23 17:02:45 2019 > New Revision: 353937 > URL: https://svnweb.freebsd.org/changeset/base/353937 > > Log: > Build toolchain components as dynamically linked executables by default > > Summary: > Historically, we have built toolchain components such as cc, ld, etc as > statically linked executables. One of the reasons being that you could > sometimes save yourself from botched upgrades, by e.g. recompiling a > "known good" libc and reinstalling it. > > 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 > this default, and link the toolchain components dynamically, just like > almost all other executables on FreeBSD. > > Maybe at some point they can even become PIE executables by default! :) They have been on HardenedBSD for a few years now. :) Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 signature.asc Description: PGP signature
Re: svn commit: r353937 - in head/share: man/man5 mk
> On Oct 23, 2019, at 10:02, Dimitry Andric wrote: > > Author: dim > Date: Wed Oct 23 17:02:45 2019 > New Revision: 353937 > URL: https://svnweb.freebsd.org/changeset/base/353937 > > Log: > Build toolchain components as dynamically linked executables by default > > Summary: > Historically, we have built toolchain components such as cc, ld, etc as > statically linked executables. One of the reasons being that you could > sometimes save yourself from botched upgrades, by e.g. recompiling a > "known good" libc and reinstalling it. > > 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 > this default, and link the toolchain components dynamically, just like > almost all other executables on FreeBSD. > > Maybe at some point they can even become PIE executables by default! :) There might be a different reason for this being the case than the one posed. 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, at the potential cost of the in-memory image. Static binaries could also better optimize away less optimal code paths, which could result in worse performing code. Did you calculate the perf trade offs for the static binaries at low -j vs high -j, system and user time, etc? Cheers, -Enji PS Thank you for keeping the SHARED_TOOLCHAIN option. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r353937 - in head/share: man/man5 mk
Author: dim Date: Wed Oct 23 17:02:45 2019 New Revision: 353937 URL: https://svnweb.freebsd.org/changeset/base/353937 Log: Build toolchain components as dynamically linked executables by default Summary: Historically, we have built toolchain components such as cc, ld, etc as statically linked executables. One of the reasons being that you could sometimes save yourself from botched upgrades, by e.g. recompiling a "known good" libc and reinstalling it. 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 this default, and link the toolchain components dynamically, just like almost all other executables on FreeBSD. Maybe at some point they can even become PIE executables by default! :) Reviewed by: kib MFC after:2 weeks Differential Revision: https://reviews.freebsd.org/D22061 Modified: head/share/man/man5/src.conf.5 head/share/mk/src.opts.mk Modified: head/share/man/man5/src.conf.5 == --- head/share/man/man5/src.conf.5 Wed Oct 23 16:57:11 2019 (r353936) +++ head/share/man/man5/src.conf.5 Wed Oct 23 17:02:45 2019 (r353937) @@ -1710,8 +1710,8 @@ as a set-user-ID root program. Set to not build the .Bx 4.4 legacy docs. -.It Va WITH_SHARED_TOOLCHAIN -Set to build the toolchain binaries as dynamically linked executables. +.It Va WITHOUT_SHARED_TOOLCHAIN +Set to build the toolchain binaries as statically linked executables. The set includes .Xr cc 1 , .Xr make 1 Modified: head/share/mk/src.opts.mk == --- head/share/mk/src.opts.mk Wed Oct 23 16:57:11 2019(r353936) +++ head/share/mk/src.opts.mk Wed Oct 23 17:02:45 2019(r353937) @@ -166,6 +166,7 @@ __DEFAULT_YES_OPTIONS = \ SENDMAIL \ SERVICESDB \ SETUID_LOGIN \ +SHARED_TOOLCHAIN \ SHAREDOCS \ SOURCELESS \ SOURCELESS_HOST \ @@ -210,7 +211,6 @@ __DEFAULT_NO_OPTIONS = \ OPENLDAP \ REPRODUCIBLE_BUILD \ RPCBIND_WARMSTART_SUPPORT \ -SHARED_TOOLCHAIN \ SORT_THREADS \ SVN \ ZONEINFO_LEAPSECONDS_SUPPORT \ ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
