That being said, my personal experience is that compiling large C projects on my machine with a fast SSD usually uses all cores on almost 100%, which would make it CPU-bound.
Yes, true, you can construct a machine on which any project you care to run is CPU bound. But meanwhile on my pretty beefy servers compiling a kernel from scratch is very much i/o bound. Maybe if I run it twice in a row after all of the caches have been prepped I can get it to be CPU bound but that's cheating, no? With enough RAM almost anything is CPU bound but that's not the normal situation. A typical laptop has 4 or 8 G of RAM and will rapidly consume all that while doing a kernel compile to the point that it's talking to the disk to a degree that it will slow down to where the CPU's are stalled.
> Yes, true, you can construct a machine on which any project you care to run is CPU bound.
You can also construct a machine on which any project you care to run is I/O bound. Which kind of makes your comment "kernel compile is not CPU bound" kind of pointless, no?
That being said, I just downloaded kernel source on my old laptop just to do a sanity check, and it's pinning all 4 of my cores to 100%, so I don't know that to tell you. Perhaps your beefy server (with, I assume, a powerful CPU) is not a typical scenario.
You mean: I've picked my system components in such a way that kernel compiles are not i/o bound. But on an average machine a kernel recompile is very much i/o bound. To the point that people will go out of their way to get large amounts of RAM and very high performance i/o subsystems into their machines. But your average i7/8G run-of-the-mill machine is going to run into the i/o bottleneck pdq. On a 32 or 64G (or even more) RAM box with an NVME drive you probably can get it to be CPU bound. On my 16G laptop with SATA SSD it very much is, the CPU is only utilized about 60% or so.
That's an interesting claim. Do you mean on all hardware it's IO bound? I would think it depends on the disks, concurrency setting for make, memory size, memory speed, and number of availabile cores.
Yes, all of those are important factor. And playing around with those factors (memory, IO speed etc...etc...) it;s easy to construct a system where CPU could be the limiting factor.
But it's still possible to make a claim that in general, most "in the real world" builds are limited by ram size (especially linking), memory bandwidth not really by CPU.
The main reason is really that compilation is not as parallel as one might think.
Compilation used to be much more IO bound in the past. But these days with nvme drives and really aggressive OS file caching (and or ramdisk) IO is less of an issue.
Also note that this changes significantly moving from O2 to O3 where CPU (single thread) performance become more and more important.Same for partial recompilation.
That being said, my personal experience is that compiling large C projects on my machine with a fast SSD usually uses all cores on almost 100%, which would make it CPU-bound.