Remember there was a lot less to the Linux kernel at the time. Wasn't too bad. The single-threaded compile time for Linux has stayed fairly consistent for awhile, since the tree grows about as fast as the average desktop improves. The big improvement in compile time has come from being able to compile with 8-32+ threads.
Yes, that's true. It has been O(1 hour) for pretty much the entire history of Linux. And if you think about it, this makes sense. If it were significantly less than that, the development cycle would speed up so it would be easier to add capabilities, which would slow down the build. If it were significantly longer, the addition of new features would slow down until the hardware started to catch up. So the compile time acts as a sort of natural control mechanism to throttle the addition of new features.
I'm not sure that is the primary reason -- many other projects have had their compile times explode over many years, even though the same logic should apply.
Not to mention if you build the kernel regularly, you benefit from incremental compilation. If you change a few non-header files the rebuild time can be as little as 2-3 minutes. Oh, and "make localdefconfig" will reduce your from-scratch compile times to the 5-15 minute mark. I highly doubt most kernel devs are building a distro configuration when testing (especially since they'd be testing either in a VM or on their local machine).
When I worked at Microsoft, Windows took far, far longer than an hour to build from scratch. I remember walking a few buildings over to the burn lab to pick up DVDs of the latest build. I don’t have any hard data, but running a full build on your dev box was very rarely done.
The dynamics of commercial projects can be very different from open-source. You're much more likely to tolerate sitting through long builds if you're being paid to do so.
I'm convinced that compiler speed is all a matter of how it was initially designed.
Take for example Delphi which can compile millions of lines of code in under a minute or something ridiculous. Then we have D, Go, Rust, and such, they compile rather large codebases that would take C++ a good 30 minutes on high end hardware of today in shorter spans of time (not as familiar with how fast Rust compiles, but I know Go and D do pretty nicely, especially if you enable concurrency for D), which probably takes those same 30 minutes on high end hardware from about a decade ago.
Sadly from what I have heard C / C++ has to run through source files numerous times before it finally compiles the darn thing into anything meaningful. Facebook made a preprocessor in D to speed things up for them, it technically didn't have to be coded in D, but Walter did write the preprocessor for them, so he gets to pick whatever language.
The C++ language cannot be parsed with a context-free parser.
A large part of the build times, however, is due to optimizations.
In the early days, clang was much faster in compilation than gcc. Over the years, it has improved on optimization output but as a consequence has lost the compilation speed.
There are many examples for https://godbolt.org/ to show how much work the optimizer does. As example, the http://eigen.tuxfamily.org library relies on the optimizer to generate optimized code for all sorts of combinations of algorithms.
Rust doesn't compile very fast unfortunately, but it's being worked on. General wisdom says it's about as fast as Clang but comparing compile speeds across languages in a meaningful way is difficult
Fair enough, thanks for that, I wasn't sure, all my Rust programs have been small enough to where I havent noticed. I wonder if it would of made sense for Rust to consider this earlier on in the same way that Pascal did. I believe I heard Pascal was designed to be parsed easily by machine code.
"Parsing" was probably not the best choice of word on the GP's part, but they meant that Pascal was specifically designed to be implementable with a naive single-pass compiler; of course that would exclude many optimizations we take for granted these days.
It's the layout of the code that allows Pascal (/Delphi) to compile everything in a single pass. By starting with the main file you easily build the tree of deps and public interfaces/functions vs the private & implementation details.
C and C++ even though they have header files, make no restriction on what goes in a header file, so it takes a bit to figure out the dep graph.
But the preprocessor isn't what makes compiling C++ slow. It's a combination of the complex grammar, and ahead of time optimization of a (mostly) static language. Turns out you can compile code really fast if you don't actually try to optimize it.
Linux in the 90's wasn't as bloated as it was now. It definitely took well under an hour to compile a kernel. My first Linux box was a 386SX-16. I later upgraded to a 486DX4-100.
That doesn't sound right, it's still not bloated. The majority is drivers then comes the cpu arch folder that takes a big cut. You can check yourself with cloc:
It used to take me just over two hours to compile a (very minimal stripped down) kernel on my 25 MHz 80486 with 4 MB of RAM (in the late 2.0.x/early 2.2.x days).
Long. I remember it being something like an hour or so to compile the kernel, but the kernel was also much smaller then. I specifically remember Linux 2.0.0 coming in a 2MB tar ball. Because it probably took me longer to download with my 28800 baud modem from an over saturated FTP server than it did to compile. 8)