rui314

mold supports LTO out of the box.

Thanks, I really wish you become a billionaire :)

I don't know the details, but once it is proven that achieving lld/mold/sold-level performance is technically feasible, it shouldn't be extremely hard to achieve similar success for macOS.

But it is no longer updated, is it?

Essentially, yes, but that’s because Apple’s new linker is so much faster than it was. You can use it instead.

The sold linker is no longer commercial software; it's been relicensed under the MIT license.

CRT object files which contain process startup routines are not in a fixed directory. Unfortunately compilers have to be hard-coded to contain an appropriate directory name.

It caused a flame war, so #1 factor is not negligible.

I could buy bikes too, but as you wrote that's not enough to make a living. This is my full time project. I could earn a mid 6 figure salary if I work for a big tech, and I think I'm creating a more valuable program than I did when I was working for a big tech, and in return I make money that counts in "fancy bicycle" unit... I think it's not wrong to say it didn't work quite well.

It didn't work. If it is available as open-source, they don't _need_ a different license. Anyway, it's off-topic.

Author here. I'm amused that I opened HN thinking that https://docs.google.com/document/d/1kiW9qmNlJ9oQZM6r5o4_N54s... (which I posted today) might come to the front page and found this post instead.

So the chibicc book is not available yet. I'm busy working on the other project (the mold linker) and don't have time to work on it. That being said, I believe the repo is still very valuable for those who want to learn how easy it is to implement a simple C compiler. chibicc's each commit was carefully written so that you can read one commit at a time. I'd recommend starting from the initial commit and observe how each feature (`if`, `for`, local variables, global variables, etc.) is implemented by following each commit.

I don’t know much about the European job market, but you can see lots of examples of US job positions and their salaries at websites such as https://www.levels.fyi.

I'm not sure if io_uring can improve mold's performance, as it has to access random locations while copying file contents to apply relocations. Currently, we mmap all input files and an output file and use memcpy to copy file contents.

I'm just not a native English speaker.

That's not for you then, but some people have to rebuild Chrome-scale programs dozens of times a day, and mold is created for such people.

It can create Mac executables, but mold/macOS is still in pre-alpha and no one should expect it to work for their programs. Once it becomes out of beta, I'll release it as mold 2.0, so please wait for it.

That's an even crazier goal which is probably 100x harder than writing a 10x faster linker. But I believe it's technically doable. At least, the world needs more crazy people who believe it is technically doable and take it as a challenge. If I get $$$ by selling the mold project to a big tech, I might be able to create a team with that money to tackle that crazy goal...

I want to write a book about linkers so that the knowledge I earned during the development of the lld and mold linkers wouldn't lost, but I don't have enough time to do that!

None of gold, lld or mold can replace GNU ld entirely because they don't cover all features that GNU ld has.

I didn't take it as an offense, so don't say sorry! I just wanted to say that if a senior dev wants to earn $1M in a few years, they can just find a job and do whatever assigned to them there. They didn't have to take a risk of starting a completely new ambitious open-source project to earn that much.

I don't have a plan, and that's not what I can plan. They can plan in theory, but I believe that's very unlikely to happen.

It's being discussed (https://github.com/rui314/mold/issues/117) but haven't reached any conclusion. The problem is that the jobserver protocol assumes that one process is one job, and its model doesn't fit very well to programs such as mold.

We do support ELF (Unix) already, and we are working on Mach-O (macOS/iOS/watchOS/etc) now. Once Mach-O is finished, we'll be working on PE/COFF (Windows).

mold/macOS aims to be a drop-in replacement for the Apple's ld. I don't think it supports all the feature you mentioned already, as it is still pre-Alpha. But we are working on it to make it "just work".

I wouldn't be surprised. In mold, if we have more than one choices to implement a feature, I always take the one that scales well for more cores even if it doesn't perform the best on low-core count machines.

My assumption is that future machines will have more cores than we have today on average, so I'm optimizing mold for such computers.

$200K is nowadays an annual total compensation of a junior dev. I believe mold values much more than a one year outcome of a typical 5-person junior dev team.

You may want to read this section of the README.

https://github.com/rui314/mold#why-does-the-speed-of-linking...

mold does support LTO. It's not faster or slower than lld both in terms of link speed and the output binary's speed.

I dislike "contact us for pricing" too, but pricing is hard! I don't know how much I should ask for. This is also a bit unusual business model because mold can be used for free. I'm happy if users pay me 10%-20% of the total cost they could save by using mold though.

If it takes 20 seconds, you go for a coffee or switch the window to start web browsing, but if it takes only 2 seconds, you can wait without being distracted. So it's more than just saving 18 seconds for each build. It wouldn't interrupt your flow.

The biggest reason is because it is multi-threaded. When building a program, the compilation step is parallelized (the build system invokes a compiler for each source file), but the final link step is not. So it is important to make the linker itself multi-threaded.

But even without multi-threading, mold is still faster than other linkers. I can think of various reasons why, but I don't know which attributes how much. I believe the biggest contributor is its efficient data structure -- it is hard to make program faster by writing fast code, but it can naturally be achieved by designing efficient data structures. That said, it is hard to compare two or more programs to find out why one program is faster than the others unless their designs are similar.