Most active commenters

    ←back to thread

    383 points hkalbasi | 16 comments | | HN request time: 0.611s | source | bottom
    Show context
    pzmarzly ◴[] No.42815005[source]
    Ever since mold relicensed from AGPL to MIT (as part of mold 2.0 release), the worldwide need for making another fast linker has been greatly reduced, so I wasn't expecting a project like this to appear. And definitely wasn't expecting it to already be 2x faster than mold in some cases. Will keep an eye on this project to see how it evolves, best of luck to the author.
    replies(5): >>42815102 #>>42815606 #>>42816517 #>>42819089 #>>42819826 #
    1. secondcoming ◴[] No.42815102[source]
    Maybe I'm holding it wrong, but mold isn't faster at all if you're using LTO, which you probably should be.
    replies(6): >>42815189 #>>42815221 #>>42815904 #>>42816102 #>>42816403 #>>42840365 #
    2. 0x457 ◴[] No.42815189[source]
    I think we're talking about non-release builds here. In those, you don't want to use LTO, you just want to get that binary as fast as possible.
    3. ◴[] No.42815221[source]
    4. compiler-guy ◴[] No.42815904[source]
    Mold will be faster than LLD even using LTO, but all of its benefits will be absolutely swamped by the LTO process, which is, more or less, recompiling the entire program from high-level LLVM-IR. That's extremely expensive and dwarfs any linking advantages.

    So the benefit will be barely noticable. As another comment points out, LTO should only be used when you need a binary optimized to within an inch of its life, such as a release copy, or a copy for performance testing.

    replies(1): >>42817272 #
    5. Arelius ◴[] No.42816102[source]
    Yeah, if you're development process requires LTO you may be holding it wrong....

    Specifically, if LTO is so important that you need to be using it during development, you likely have a very exceptional case, or you have some big architectural issues that are causing much larger performance regressions then they should be.

    replies(4): >>42816339 #>>42816648 #>>42823665 #>>42824951 #
    6. benatkin ◴[] No.42816339[source]
    Being able to choose a middle ground between development/debug builds and production builds is becoming increasingly important. This is especially true when developing in the browser, when often something appears to be slow in development mode but is fine in production mode.

    WebAssembly and lightweight MicroVMs are enabling FaaS with real time code generation but the build toolchain makes it less appealing, when you don't want it to take half a minute to build or to be slow.

    7. benatkin ◴[] No.42816403[source]
    Agreed. Both fast and small are desirable for sandboxed (least authority) isomorphic (client and server) microservices with WebAssembly & related tech.
    8. jcalvinowens ◴[] No.42816648[source]
    If you're debugging, and your bug only reproduces with LTO enabled, you don't have much of a choice...
    replies(1): >>42817282 #
    9. paulddraper ◴[] No.42817272[source]
    Username checks out.

    And factual.

    replies(1): >>42819468 #
    10. paulddraper ◴[] No.42817282{3}[source]
    Sure, for that 1% of the time.
    replies(1): >>42817685 #
    11. thesz ◴[] No.42817685{4}[source]
    ...which takes these remaining 99% of a development time...
    replies(1): >>42819472 #
    12. saagarjha ◴[] No.42819468{3}[source]
    I'm waiting for 'linker-guy to weigh in, personally.
    13. saagarjha ◴[] No.42819472{5}[source]
    Surely your LTO bugs are not so easy to fix that they take less time to resolve than linking itself does.
    14. IshKebab ◴[] No.42823665[source]
    > you're development process requires LTO you may be holding it wrong....

    Not necessarily. LTO does a very good job of dead code elimination which is sometimes necessary to fit code in microcontroller memory.

    15. josephg ◴[] No.42824951[source]
    > Yeah, if you're development process requires LTO you may be holding it wrong....

    I spent a few months doing performance optimisation work. We wanted to see how much performance we could wring out of an algorithm & associated data structures. Each day I’d try and brainstorm new optimisations, implement them, and then A/B test the change to see how it actually affected performance. To get reliable tests, all benchmarks were run in release mode (with all optimisations - including LTO - turned on).

    16. account42 ◴[] No.42840365[source]
    You should be using LTO where incremental build times are a concern, i.e. for development builds.

    And for realease builds link time is hardly a concern.