rui314

When I announced the rewrite, it was actually already mostly done.

AI's coding ability is truly amazing. We've spent decades inventing languages, tools, and methodologies to help us write better code more efficiently, but AI-assisted coding is the biggest breakthrough in programming productivity I've seen in my lifetime. It's genuinely incredible.

I think the way I've talked about incremental linking may have given a somewhat misleading impression. I'm not against incremental linking, and I'm not denying its possible usefulness. But especially when I was developing lld, I felt that we should focus first on speeding up full links.

Before I created lld, linking was much slower than it is today, and people somehow seemed to accept that as a given. People would often argue that since linking was slow, we needed to reduce the amount of linking work by implementing incremental linking. I thought that was too pessimistic. Why don't we just make the usual full link much faster, ideally almost as fast as a cp command, so that we don't need incremental linking nearly as much?

In other words, I wanted to solve the slow link problem head-on rather than work around linker slowness. And now we can link multi-gigabyte binaries in a second or two, which makes incremental linking much less urgent than it was ten years ago. That's pretty much what I wanted to achieve.

Am I satisfied with the speed? No. Could incremental linking speed it up even more? Maybe. Would it still be useful? Sure. It may well be worth doing. But people don't need it nearly as badly as they did ten years ago. I wanted to solve the larger problem first.

Table 4 shows actual measurements on my Threadripper 7980X machine, so I'm not sure whether the numbers look too good or not. I chose large programs more or less at random as the test set without thinking too much about it, so they were not cherry-picked. I'm developing mold on this machine, so mold may naturally be optimized for this configuration. That's why we have Table 6. My benchmark is available at https://zenodo.org/records/21882261. It's pretty easy to run, so you may want to try it out.

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...