3 ms·
> I mean correct me if you have actual data to prove me wrong, but my memory at the time is that build times were really not a problem. I never had cause to bu
by frumplestlatz 8mo ago
> I mean correct me if you have actual data to prove me wrong, but my memory at the time is that build times were really not a problem.
I never had cause to build quake, but my Linux kernel builds took something like 3-4 hours on an i486. It was a bit better on the dual socket pentium I had at work, but it was still painfully slow.
I specifically remember setting up gcc cross toolchains to build Linux binaries on our big iron ultrasparc machines because the performance difference was so huge — more CPUs, much faster disks, and lots more RAM.
That gap disappeared pretty quickly as we headed into the 2000s, but in 1997 it was still very large.
- knorker 8mo ago> Linux kernel builds took something like 3-4 hours on an i486 From cold, or from modified config.h, sure. But also keep in mind that the Pentium came out in 1993.
- RupertSalt 8mo agoI remember two huge speedups back in the day: `gcc -pipe` and `make -j`. `gcc -pipe` worked best when you had gobs of RAM. Disk I/O was so slow, especially compared to DRAM, that the ability to bypass all those temp file steps was a god-send. So you'd always opt for the pipeline if you could fill memory. `make -j` was the easiest parallel processing hack ever. As long as you had multiple CPUs or cores, `make -j` would fill them up and keep them all busy as much as possible. Now, you could place artificial limits such as `-j4` or `-j8` if you wanted to hold back some resources or keep interactivity. But the parallelism was another god-send when you had a big compile job. It was often a standard but informal benchmark to see how fast your system could rebuild a Linux kernel, or a distro of XFree86.