[repsilat]

It's not an especially weird use of terminology. "I/O bound" means "waiting on reads and/or writes." Cache or RAM or disk, it's all about communication throughput and latency, efficient access patterns etc.

In a compute-bound workload the CPU spends the bulk of its time actually retiring instructions, not stalled waiting on data.

Think about it from the perspective of what the FPU sees -- once it has done that FMA operation, does it have the data it needs to do the next one, or does it need to sit on its hands for a while?

The cache hierarchy, cache-friendly data structures and algorithms -- they all aim to reduce time spent waiting on IO.

[throwawaymath]

I understand that, but I don't think it's useful to use use the term "I/O" in the theoretical sense of the concurrency problem. It's also not typical nomenclature - for example, see https://stackoverflow.com/questions/868568/what-do-the-terms.... We have terms like "CPU bound", "cache bound", and "memory bound", but we don't really have "disk bound" in common usage. This is because the common usage is "I/O bound".

Theoretically speaking we can model any process as one which has to wait and one which doesn't have to wait. But in modern usage we have a variety of types and speeds for reads and writes. When I/O simply means reads and writes, you lose all the practical granularity you'd otherwise get by decomposing the reads/writes into different bottlenecks. It's philosophically elegant, but practically unhelpful for optimizing HPC and distributed systems when, as the responder said, it's rare to be CPU bound.

I also think that the context of my original comment is pretty clearly using I/O in the modern sense of disk usage. Responding with a correction that everything is I/O bound is vacuous, not insightful.

[ChrisRackauckas]

>it's rare to be CPU bound.

Not when solving (partial) differential equations, which is what I am using Julia for.

[repsilat]

Also: CPU-bound problems used to be much more common. We spent a lot of effort making CPUs fast though, and memory access didn't keep up. It's why we have these deep caches, it's why we have out of order execution and speculative branch prediction -- to keep processors fed with data.

Used to be you could count cycles, now that's only really true in the simplest of cases with trivial memory access patterns. Now high-information branches are much more expensive than cycle counting would have us believe, ditto pointer-chasing.