From owner-svn-src-all@freebsd.org Thu Sep 17 23:16:30 2020 Return-Path: Delivered-To: svn-src-all@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 700C93F0D5D; Thu, 17 Sep 2020 23:16:30 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BstBj3Xgpz3XVv; Thu, 17 Sep 2020 23:16:29 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: by sdaoden.eu (Postfix, from userid 1000) id B3AA716057; Fri, 18 Sep 2020 01:16:27 +0200 (CEST) Date: Fri, 18 Sep 2020 01:16:26 +0200 From: Steffen Nurpmeso To: Warner Losh Cc: Jessica Clarke , "Rodney W. Grimes" , Alex Richardson , src-committers , svn-src-all , svn-src-head Subject: Re: svn commit: r365836 - head/share/mk Message-ID: <20200917231626.ki99z%steffen@sdaoden.eu> In-Reply-To: References: <202009171705.08HH5CtE014644@gndrsh.dnsmgr.net> <307760E0-1208-4F4C-AD7D-9E0A3C1B3A3B@freebsd.org> Mail-Followup-To: Warner Losh , Jessica Clarke , "Rodney W. Grimes" , Alex Richardson , src-committers , svn-src-all , svn-src-head User-Agent: s-nail v14.9.19-127-g67fa13b6 OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. X-Rspamd-Queue-Id: 4BstBj3Xgpz3XVv X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of steffen@sdaoden.eu designates 217.144.132.164 as permitted sender) smtp.mailfrom=steffen@sdaoden.eu X-Spamd-Result: default: False [-1.53 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.96)[-0.965]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; NEURAL_HAM_LONG(-0.95)[-0.953]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sdaoden.eu]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.31)[-0.311]; RCPT_COUNT_SEVEN(0.00)[7]; MID_CONTAINS_FROM(1.00)[]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15987, ipnet:217.144.128.0/20, country:DE]; MAILMAN_DEST(0.00)[svn-src-all,svn-src-head] X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2020 23:16:30 -0000 Warner Losh wrote in : |On Thu, Sep 17, 2020, 11:25 AM Jessica Clarke wrote: |>> On 17 Sep 2020, at 18:23, Jessica Clarke wrote: |>> |>>> On 17 Sep 2020, at 18:05, Rodney W. Grimes |> wrote: |>>> |>>>> On Thu, Sep 17, 2020 at 9:39 AM Steffen Nurpmeso |> wrote: |>>>> |>>>>> Alex Richardson wrote in |>>>>> <202009171507.08HF7Qns080555@repo.freebsd.org>: |>>>>>|Author: arichardson |>>>>>|Date: Thu Sep 17 15:07:25 2020 |>>>>>|New Revision: 365836 |>>>>>|URL: https://svnweb.freebsd.org/changeset/base/365836 |>>>>>| |>>>>>|Log: |>>>>>| Stop using lorder and ranlib when building libraries |>>>>>| |>>>>>| Use of ranlib or lorder is no longer necessary with current linkers |>>>>>| (probably anything newer than ~1990) and ar's ability to create an |>>>>> object |>>>>>| index and symbol table in the archive. |>>>>>| Currently the build system uses lorder+tsort to sort the .o files |> in |>>>>>| dependency order so that a single-pass linker can use them. |> However, |>>>>>| we can use the -s flag to ar to add an index to the .a file which |> makes |>>>>>| lorder unnecessary. |>>>>>| Running ar -s is equivalent to running ranlib afterwards, so we can |>>>>> also |>>>>>| skip the ranlib invocation. |>>>>> |>>>>> That ranlib thing yes (for long indeed), but i have vague memories |>>>>> that the tsort/lorder ordering was also meant to keep the things |>>>>> which heavily interdepend nearby each other. (Luckily Linux |>>>>> always had at least tsort available.) |>>>>> This no longer matters for all the platforms FreeBSD supports? |>>>>> |>>>> |>>>> tsort has no notion of how dependent the modules are, just an order |> that |>>>> allows a single pass through the .a file (otherwise you'd need to list |> the |>>>> .a file multiple times on the command line absent ranlib). That's the |>>>> original purpose of tsort. tsort, lsort, and ranlib all arrived in 7th |>>>> edition unix on a PDP-11, where size was more important than proximity |> to |>>>> locations (modulo overlays, which this doesn't affect at all). |>>>> |>>>> There were some issues of long vs short jumps on earlier architectures |> that |>>>> this helped (since you could only jump 16MB, for example). However, |> there |>>>> were workarounds for this issue on those platforms too. And if you |> have a |>>>> program that this does make a difference, then you can still use |>>>> tsort/lorder. They are still in the system. |>>>> |>>>> I doubt you could measure a difference here today. I doubt, honestly, |> that |>>>> anybody will notice at all. |>>> |>>> The x86 archicture has relative jmps of differning lengths, even in |> long mode |>>> there is support for rel8 and rel32. |>> |>> That's irrelevant though for several reasons: |>> |>> 1. The compiler has already decided on what jump instructions to use |> based on |>> the requested code model (unless you're on RISC-V and using GNU bfd ld |> as |>> that supports linker relaxations that actually delete instruction |> bytes). |>> |>> 2. The linker is still free to reorder input sections however it likes, |> it |>> doesn't have to follow the order of the input files (and the files |> within |>> any archive). |> |> Hm actually that's only true for archives; it needs to respect the \ |> order of |> files on the command line for things like crti.o to work. But regardless, |> the |> other points (and this one, partially) still hold. |> |>> 3. If you care about those kinds of optimisations you should use |> link-time |>> optimisation which will likely do far more useful things than just |> optimise |>> branches, but again isn't constrained by the order of the input files, |> it |>> can lay out the code exactly how it wants. |>> |>> Not to mention that this is just a topological sort, not a clustering |> sort. |> | |Yea. I doubt you'd be able to measure a difference on anything in our tree. Very interesting, thank you all. Profiling based sort order, impressive even. I thought more about cache hotness and, simply, keeping interdependent things together as such. But well, caches are so big today, and everything is dynamically linked, i only jerk a bit due to that runtime cost myself. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)