From owner-svn-src-head@freebsd.org Thu Oct 24 12:49:10 2019 Return-Path: Delivered-To: svn-src-head@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CFFA416C0F9; Thu, 24 Oct 2019 12:49:10 +0000 (UTC) (envelope-from danfe@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46zRrk55q2z3DHC; Thu, 24 Oct 2019 12:49:10 +0000 (UTC) (envelope-from danfe@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1033) id A7547C845; Thu, 24 Oct 2019 12:49:10 +0000 (UTC) Date: Thu, 24 Oct 2019 12:49:10 +0000 From: Alexey Dokuchaev To: Enji Cooper Cc: Dimitry Andric , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r353937 - in head/share: man/man5 mk Message-ID: <20191024124910.GA93913@FreeBSD.org> References: <201910231702.x9NH2jQv045130@repo.freebsd.org> <2B855247-5097-442D-8D4A-77D68D2F6186@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2B855247-5097-442D-8D4A-77D68D2F6186@gmail.com> User-Agent: Mutt/1.11.4 (2019-03-13) X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2019 12:49:10 -0000 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