5 ms·

Oh geez I can't imagine how long it would take to compile Linux on that slow of a processor.

CreRecombinase 7y ago
I once read somewhere that the time to compile Linux from source on high-end desktop hardware has remained remarkably stable over the years.
- lisper 7y ago
  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.
  - cyphar 7y ago
    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).
    - lisper 7y ago
      > many other projects have had their compile times explode over many years Like, for example?
      - brantonb 7y ago
        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.
        pretty_bubbles 7y ago
        Was it just the windows kernel? Or did it include all of the utilities in Windows?
        lisper 7y ago
        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.
        fest 7y ago
        Until management notices, does the X hours saved multiplication by number of developers, and the resources for improvement will be found soon.
        cameronbrown 7y ago
        Definitely not. People are far more expensive than machines.
    - lonelappde 7y ago
      It's a lower bound for a highly active project.
- giancarlostoro 7y ago
  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.
  - anchpop 7y ago
    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
    - giancarlostoro 7y ago
      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.
      - steveklabnik 7y ago
        Parsing is not the reason why it takes a while to compile.
        Sharlin 7y ago
        "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.
- pbhjpbhj 7y ago
  My first Linux, Slackware, took me a week to download (Slackware), was on something like 12 disks. I compiled a kernel, took two days. That was on a second-hand Pentium-S. I probably wasn't doing it right.
anyfoo 7y ago
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)
deleted 7y ago
[deleted]
deleted 7y ago
[deleted]
TkTech 7y ago
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.
jlgaddis 7y ago
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).
icedchai 7y ago
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.
- ce4 7y ago
  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: http://cloc.sourceforge.net/ http://cloc.sourceforge.net/
  - icedchai 7y ago
    Linux 1.0 was 1 meg, gzipped and less than 200K lines of code, total. Linux 4.x is over 150 megs, gzipped. Just the lines in the arch/x86 folder are more than the total lines in Linux 1.0.
znpy 7y ago
depending on how you configure your kernel and what storage you're using, it might be doable.

I once read somewhere that the time to compile Linux from source on high-end desktop hardware has remained remarkably stable over the years.

lisper 7y ago
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.
- cyphar 7y ago
  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).
  - lisper 7y ago
    > many other projects have had their compile times explode over many years Like, for example?
    - brantonb 7y ago
      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.
      - pretty_bubbles 7y ago
        Was it just the windows kernel? Or did it include all of the utilities in Windows?
      - lisper 7y ago
        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.
        fest 7y ago
        Until management notices, does the X hours saved multiplication by number of developers, and the resources for improvement will be found soon.
        cameronbrown 7y ago
        Definitely not. People are far more expensive than machines.
  - lonelappde 7y ago
    It's a lower bound for a highly active project.
giancarlostoro 7y ago
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.
- anchpop 7y ago
  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
  - giancarlostoro 7y ago
    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.
    - steveklabnik 7y ago
      Parsing is not the reason why it takes a while to compile.
      - Sharlin 7y ago
        "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.
pbhjpbhj 7y ago
My first Linux, Slackware, took me a week to download (Slackware), was on something like 12 disks. I compiled a kernel, took two days. That was on a second-hand Pentium-S. I probably wasn't doing it right.

anyfoo 7y ago

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)

deleted 7y ago

[deleted]

deleted 7y ago

[deleted]

TkTech 7y ago

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.

jlgaddis 7y ago

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

icedchai 7y ago

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.

ce4 7y ago
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: http://cloc.sourceforge.net/ http://cloc.sourceforge.net/
- icedchai 7y ago
  Linux 1.0 was 1 meg, gzipped and less than 200K lines of code, total. Linux 4.x is over 150 megs, gzipped. Just the lines in the arch/x86 folder are more than the total lines in Linux 1.0.

znpy 7y ago

depending on how you configure your kernel and what storage you're using, it might be doable.