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.
That's unfortunate, and I'm sorry the Rust rewrite makes StageX's bootstrap more complicated. StageX has a fairly specialized requirement here, though, and I don't think it would make sense to keep mold in C++ just for that use case.
Using the final mold 2.x release as a bootstrap-only linker and then replacing it with mold 3 once Rust is available seems like the most practical compromise.
Yep that is what we are going to have to do. Is what it is. Thanks for maintaining an amazing linker, and we will surely ship v3 at the last mile for end users.
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.
Rui, if I ever get rich, I will seriously give you 1 million US dollars, $100K the minimum, for everything you have done so far, with all your projects.
That's the least I can do to show my appreciation for your incredible work; I can't thank you enough brother!
I also wish to see that chibicc compiler plus the book completed. I want to learn everything around such topics.
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.
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.
Well, can't that be made a build parameter, that can be determined during build configuration? CMake'ifying the project might help you get there perhaps?
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'm charmed by projects like this, thanks for sharing.
What I want to see is a program like this, with very simple assembly/object code, and very fast compilation, and uses DynASM to build the executable in-memory.
Then use a tracing JIT to make it fast.
Having good, tiny, reference C compilers is a prerequisite for that, so I'm always happy to see work in that field.
I am interested in this too. I would do different tradeoffs. I am more interested in optional garbage collection, the parallelism and async story in the language such as threading and coroutines or both together.
I suspect combining garbage collection, exceptions, closures, tail call optimisation, parallelism, JIT compilation and coroutines is difficult to do orthogonally.
On eatonphil's discord someone recently shared this link: This is a framework for building high performance language runtimes
> It didn't work. If it is available as open-source, they don't _need_ a different license.
Don't they? I'm surprised to hear that. I have sold a few proprietary versions of my AGPL codes (which were identical to the original one, but with the license stripped). Not enough to make a living, but I can buy some fancy bikes with the money.
In some cases, they even paid --separately-- for support and a few features of the software that were of particular interest to them. For some reason, many companies are extremely frightened of the AGPL, but a dual AGPL/commercial licensing seems to fit them very well. This is a nice model for free software distribution, but it only suits small projects that do not get external contributors.
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.
I might get shit on for saying this here, but I agree with you that it's very difficult to make a decent living on fully "free" software.
I've had orgs not bat at an eye paying a few thousand for a software license if there are justifiable productivity returns and the license is required for us to continue to use the software.
If that license is not required, we would never give you a dime. It's sad, but true. Those few thousand, to many companies, are pennies on the dollar. Just price it graciously so you don't leave the little guys out.
You'll get grumbles but do what you need to survive if you want to do this full time and for a living. God knows you, of all people, have earned it.
I think I recall you saying that you elided the bugs, yeah? (Am I under-caffeinated this morning?) If so, you could write a second book about the bugs and issues you encountered while implementing chibicc and, uh, that would be awesome too! (I'd buy a copy.)
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.