I have a 2 sockets x 8 cores (16 real cores) Xeon desktop machine from last year. It's very fast.
But to make it useful for compilation, I had to make a lot of alterations to our software and build systems to ensure we were maximally parallelizing builds. This included splitting up C programs into separate C files almost comically fine-grained. I was literally using ‘wc -l *.c’ and trying to even up the size of the files.
Eventually you hit Amdahl's law: Some parts of the build (I'm looking at you, autoconf configure scripts) simply cannot be parallelized and they slow the whole system down.
The other thing it does well is virtualization, but that tends to be limited by RAM and disk space. The machine has 64 GB of RAM so it can run plenty of VMs, but I had to install more disks so I could store those VMs. It now has 4 SSDs and 3 hard drives, and managing the space across those is a bit painful (with LVM).
> Eventually you hit Amdahl's law: Some parts of the build (I'm looking at you, autoconf configure scripts) simply cannot be parallelized and they slow the whole system down.
Linking a large C/C++ project can take some (a lot of) time as well. Linking is of course in general a rather difficult to parallelize problem, except if there is no linking (e.g. because the runtime links everything at every application start cough).
Absolutely yes, linking was another unsolvable problem when I was parallelizing the builds. As was odd stuff like building documentation, building Perl bindings and a few other things that were inherently serial.
Does partial linking (ld -r) allow one to parallelize linking? The Linux kernel does that on its build system, though I don't know if it's for performance reasons.
> This included splitting up C programs into separate C files almost comically fine-grained. I was literally using ‘wc -l *.c’ and trying to even up the size of the files.
This probably increased CPU usage, but did it really reduce compilation times? I would imagine that any gains from parallelizing function compile times would be eliminated by having to process the header files over and over again. Not to mention the time cost of doing the splitting.
I'm pretty sure it increased build times on less parallel machines, yes. And as you say the total work done (because of duplicate header file compilation) was greater.
But to make it useful for compilation, I had to make a lot of alterations to our software and build systems to ensure we were maximally parallelizing builds. This included splitting up C programs into separate C files almost comically fine-grained. I was literally using ‘wc -l *.c’ and trying to even up the size of the files.
Eventually you hit Amdahl's law: Some parts of the build (I'm looking at you, autoconf configure scripts) simply cannot be parallelized and they slow the whole system down.
The other thing it does well is virtualization, but that tends to be limited by RAM and disk space. The machine has 64 GB of RAM so it can run plenty of VMs, but I had to install more disks so I could store those VMs. It now has 4 SSDs and 3 hard drives, and managing the space across those is a bit painful (with LVM).