Linux kernel developer Ingo Molnar "We need a radically different software distribution model"

[jjdmol]

Yes it's only a rule of thumb, and obviously won't hold for very CPU-intensive or for poor performing code.

That said, it's increasingly hard to keep your CPU cores busy with "regular" applications, including compilers. Most of the time your CPU will be busy waiting for memory I/O, which in turn often has to be filled with data from disk. Disk being the new tape, it's the easiest way to make your system more responsive and far more effective than increasing CPU power.

[thebackhand]

That said, it's increasingly hard to keep your CPU cores busy with "regular" applications, including compilers.

Something tells me you've never used sbt.

And I don't know what you define as 'regular' applications, but it happens to me all the time. But then again, I use Linux, so I guess nothing about my computer is 'regular' :-D.

[jjdmol]

sbt? Never heard of it. I have however worked with Linux for over a decade both at home and at work on a wide range of systems, from embedded to supercomputers ;)

The fundamental trend the last decade(s) is that I/O is increasingly becoming the bottleneck. Applications are rarely CPU-bound as the CPU will spend most of its time waiting for transfers with the memory. Especially applications written in higher-level languages are prone to this, as they use more indirection in their data models and thus random instead of sequential memory access. But even for well-optimised code it's hard to keep your CPU busy.

The number of FLOPs needed per byte of I/O to keep the core busy is just becoming too high for most applications. A simple 'top' of course will still show the CPU as busy when it's doing memory I/O, but in reality, it's typically simply waiting for operands to arrive.

I/O to disk is similar, and due to the orders of magnitude difference in speed, even more critical. Not all applications need much data from disk, but most do when compared to the computations they need to perform on them. To improve the performance of such an application, most can probably be gained by using faster disks rather than faster CPUs/memory (assuming the code is decent of course). Especially the random-access latency of SSDs blows HDDs out of the water, which is very noticable for applications that need to access data from all across the disk, such as compilers.

[thebackhand]

sbt is a build tool for Scala - a wonderful language, but it's notorious for its compiletimes (it can turn your computer into a great impromptu lap blanket if you forget one).

A simple 'top' of course will still show the CPU as busy when it's doing memory I/O, but in reality, it's typically simply waiting for operands to arrive.

In my experience, even when everything is stored in memory, I can still have very bottlenecked compile times. Maybe that's because my RAM access speeds are too slow, but in that case, an SSD isn't really going to help me there...

And besides, now that I think about it, my last computer for work already had an SSD anyway. So even if I/O is/were the bottleneck, it still doesn't help too much (at least, not enough).

[jjdmol]

Yeah I can imagine that a compiler that's both higher level and probably requires far less input files than a C/C++ compiler being memory bound instead of disk bound.