Announcement

Collapse
No announcement yet.

The Mold Linker Is Great & Set To Become Even Better

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

  • #11
    I've been using mold for speeding up linking for my Rust projects and it's been great! I also want to use it as a linker for Zig but there seems to be an issue with it at the current moment.

    Comment


    • #12
      Originally posted by NobodyXu View Post
      When performing LTO, mold fallback to using llvm/gcc to do the LTO, because LTO means the object files contains intermediate compiler-internal IR instead of binary code, and you have to pass them into a compiler to optimize and generate machine code, so using mold with LTO makes no sense.
      I found this old Phoronix article from 2022

      Mold 1.1 most notably now offers native Link-Time Optimization (LTO) support. Mold previously diverted to ld.bdf/ld.lld when encountering IR intended for LTO-capable linkers while now it can handle the intermediate representation itself. The LTO support is implemented with a linker plug-in interface similar to that of GNU ld and GNU gold. Mold's initial LTO support is focused on completeness and rather than performance, which for now at least means it's only "marginally faster" than the other linkers.​
      and the Release Note linked in the article states

      Native LTO (link-time optimization) support has been added. mold used to invoke ld.bfd or ld.lld if it encountered a GCC IR (intermediate representation) file or an LLVM IR file to delegate the task to the LTO-capable linkers, respectively. Now, mold handles IR files directly. This feature is implemented using the linker plugin API which is also used by GNU ld and GNU gold. Note that the LTO support has been added for completeness and not for speed. mold is only marginally faster than the other linkers for LTO builds because not linking but code optimization dominates.​
      And this article from June 2022

      Mold 1.3 continues improving its link-time optimization (LTO) support with now working more reliably under heavy load rather than aborting occasionally under high load on Linux. Mold 1.3 also can now be built with GCC 12 with LTO enabled, fixes an LTO issue with 32-bit hosts, and other changes.
      So I'm getting the impression that it does its own LTO, based on the IR output from the compiler that uses it?
      Last edited by Azpegath; 07 February 2024, 09:41 AM.

      Comment


      • #13
        Originally posted by ssokolow View Post

        There are plans to extend the commercial version of mold (sold) from only supporting macOS/iOS to also supporting Windows, if you're OK with paying for a linker. I'm not sure if their "We are considering relicensing the sold linker as free software rather than as a commercial product, given the recent developments with the official Apple linker. Since Apple's linker has gained speed, it's difficult to obtain a sufficient number of users to sustain this project." applies to that too.

        (mold currently operates under a "make people using paid operating systems pay for their linker to subsidize development of the version for free platforms" model. Note that the sold README is currently a bit stale in that it still says mold is AGPLed rather than MITed.)
        Crap. When I read this article, I immediately thought "oh good, that guy found himself a revenue stream so he can keep soldiering on". I guess not, that's a shame

        Comment


        • #14
          Originally posted by bug77 View Post

          Crap. When I read this article, I immediately thought "oh good, that guy found himself a revenue stream so he can keep soldiering on". I guess not, that's a shame
          seriously just a linker is not really something anyone would spend money on. Even for a whole compiler suite the days have long sailed decades ago, ... You will be surprised how many users don't even want to pay for their Linux distribution ;-)
          Last edited by rene; 07 February 2024, 01:43 PM.

          Comment


          • #15
            Originally posted by Azpegath View Post

            I don't understand the premise of the question.
            LTO binaries are not really linked together. The compiler does the "linking" by doing the last compiling step. So in that case any linker speed improvements would be gone.

            Comment


            • #16
              Originally posted by Azpegath View Post

              So I'm getting the impression that it does its own LTO, based on the IR output from the compiler that uses it?
              Why would you get that impression? The link you quoted just said it used to just call the other linker (which would then call the compiler), now it can call the compiler directly itself instead. A linker is not a compiler, it can not handle LTO binaries.

              Comment


              • #17
                Thanks Azpegath , so it's now using linker plugin.

                But my point remains - with LTO, it's essentially performing optimization at link-time using the compiler and then doing the codegen, I don't think it can speed it up a lot.

                Linker plugin or jot, no one is going to reimplement all the code in LLVM/GCC for performing optimization, so it just can't help much with LTO.

                If you want a faster LTO release build, then you would probably want to use ThinLTO from clang, it's multithreaded and should be faster than fat LTO which is single thread but optimizes stuff better.

                Comment


                • #18
                  Originally posted by carewolf View Post

                  LTO binaries are not really linked together. The compiler does the "linking" by doing the last compiling step. So in that case any linker speed improvements would be gone.
                  I don’t think that’s true. Even if LTO means that instead of linking many objects together you hand them back to the link-time frontend and all you get from the final stage of the backend (LTRANS, in GCC terminology) is a single object (which, btw, moght not be true anymore given that partitioned/parallel LTO exists) — it’s still an object which needs to be relocated, sections need to be laid out in memory (and possibly rearranged and GC’ed), the symbol tables need to be computed, in short, it needs to be linked.
                  Last edited by intelfx; 08 February 2024, 04:06 AM.

                  Comment


                  • #19
                    Originally posted by rene View Post

                    seriously just a linker is not really something anyone would spend money on. Even for a whole compiler suite the days have long sailed decades ago, ... You will be surprised how many users don't even want to pay for their Linux distribution ;-)
                    I know people and companies are as cheap as they get. Still, it's no reason for guys doing this kind of work to go unpaid... Remember heartbleed?

                    Comment


                    • #20
                      Originally posted by rene View Post

                      seriously just a linker is not really something anyone would spend money on. Even for a whole compiler suite the days have long sailed decades ago, ... You will be surprised how many users don't even want to pay for their Linux distribution ;-)
                      I would. Linking a debug build of a small to medium sized project takes 15 minutes on Windows, which basically makes debugging at work impossible, I have to do all debugging during home office. If I can pay for a linker that cuts these 15 minutes down to a few seconds, I'd buy it, unless it costs thousands of dollars for a license.

                      Comment

                      Working...
                      X