Warner Losh wrote in <canczdfqxxn0o2tytxwpkptqpc9ihp7dzfh-bsghdy+p9n9p...@mail.gmail.com>: |On Thu, Sep 17, 2020, 11:25 AM Jessica Clarke <jrt...@freebsd.org> wrote: |>> On 17 Sep 2020, at 18:23, Jessica Clarke <jrt...@freebsd.org> wrote: |>> |>>> On 17 Sep 2020, at 18:05, Rodney W. Grimes <free...@gndrsh.dnsmgr.net> |> wrote: |>>> |>>>> On Thu, Sep 17, 2020 at 9:39 AM Steffen Nurpmeso <stef...@sdaoden.eu> |> wrote: |>>>> |>>>>> Alex Richardson wrote in |>>>>> <202009171507.08hf7qns080...@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) _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
