svn commit: r365836 - head/share/mk

[Steffen Nurpmeso]

Warner Losh wrote in
 <CANCZdfqxXn0o2tYTXWpKPTQpc9iHp7DzFH-BSghdy+P9N9PXJg at mail.gmail.com>:
 |On Thu, Sep 17, 2020, 11:25 AM Jessica Clarke <jrtc27 at freebsd.org> wrote:
 |>> On 17 Sep 2020, at 18:23, Jessica Clarke <jrtc27 at freebsd.org> wrote:
 |>>
 |>>> On 17 Sep 2020, at 18:05, Rodney W. Grimes <freebsd at gndrsh.dnsmgr.net>
 |> wrote:
 |>>>
 |>>>> On Thu, Sep 17, 2020 at 9:39 AM Steffen Nurpmeso <steffen at sdaoden.eu>
 |> wrote:
 |>>>>
 |>>>>> Alex Richardson wrote in
 |>>>>> <202009171507.08HF7Qns080555 at 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)