Announcement

Collapse
No announcement yet.

The Speed Of LLVM's LLD Linker Continues Looking Good

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • The Speed Of LLVM's LLD Linker Continues Looking Good

    Phoronix: The Speed Of LLVM's LLD Linker Continues Looking Good

    LLVM's LLD linker still isn't too widely used yet on Linux systems, but the performance of this linker alternative to GNU Gold and GNU ld are quite compelling...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    i would like to use it but there is no arch linux package

    Comment


    • #3
      Is it reliable? When gold was new there were lots of packages it didn't work with, there's still a few that it doens't work with

      If I recompile my system will there be many failures?

      Comment


      • #4
        Originally posted by FireBurn View Post
        Is it reliable? When gold was new there were lots of packages it didn't work with, there's still a few that it doens't work with

        If I recompile my system will there be many failures?
        afaik its even more reliable than gold

        Comment


        • #5
          Did they enable threaded linking when comparing to gold or did they only enable that for lld?

          Also peak memory consumption is interresting. Linking a debug version chromium uses 12Gbyte of memory (and the output of the latest versions has grown to 2Gbytes, from 100Gbyte of object files and archives).
          Last edited by carewolf; 27 February 2017, 03:58 PM.

          Comment


          • #6
            Isn't the speed of a linker the most useless metric possible? Should not the code quality more valuable?

            Comment


            • #7
              Originally posted by lowflyer View Post
              Isn't the speed of a linker the most useless metric possible? Should not the code quality more valuable?
              As long as it works correctly, the code quality is identical - this is a Linker, not a Compiler. And why is speed a useless metric, do you have an idea how many development builds are done in between releases?

              Comment


              • #8
                Originally posted by lowflyer View Post
                Isn't the speed of a linker the most useless metric possible? Should not the code quality more valuable?
                Actually, the speed of a linker is paramount to code quality. Every time a developer wants to test a change they must re-link the program. If that takes over a minute that can easily cut the developer's time on task in half, and with half as many effective man-hours on development, half as much work can be conducted on improving the code, period.

                Comment


                • #9
                  Originally posted by discordian View Post

                  As long as it works correctly, the code quality is identical - this is a Linker, not a Compiler. And why is speed a useless metric, do you have an idea how many development builds are done in between releases?
                  Well, when I see what todays linkers do to the code, this is not completely true anymore. And yes, I *do* have a very serious idea about how many builds are done in between releases.

                  Comment


                  • #10
                    Originally posted by linuxgeex View Post

                    Actually, the speed of a linker is paramount to code quality. Every time a developer wants to test a change they must re-link the program. If that takes over a minute that can easily cut the developer's time on task in half, and with half as many effective man-hours on development, half as much work can be conducted on improving the code, period.
                    I agree with you on the general idea. But when I see that a chromium debug build is linked in under 45 seconds I have to question your calculations with the man-hours. man-seconds would be more appropriate.

                    Comment

                    Working...
                    X