Hacker News Reader

Comment by amelius | Hacker News Reader

The problem is that systems evolve. What's IO bound today may be CPU bound tomorrow. And then you'll have to rethink and depending on what language you use you may even have the "what color is my function" problem.

View on HN

What do you mean by this claim that what is io bound today may be cpu bound tomorrow?

There's two ways to understand that. What I think is the likely intention is the requirements may change, such that pieces that currently don't do much computation start to do a lot. Easiest one to think about is adding encryption. Your http server may have been bottlenecked on disk or network i/o, but your https server may be bottlenecked on cpu; not a great example because the cpu work in TLS is in bits and pieces and will probably share nicely.

The other way is that sometimes a little more load perturbs the system so things take a lot longer. I've had systems that work fine until you hit X% cpu, then it jumps to 90%+, because of say lock contention; sometimes N is 80% so whatevs, but sometimes it's 25%, and then you need to find and fix the bottleneck.

The transition from spinning disks to SATA/SAS flash to NVMe.

Data storage is one example, a lot of time loading of data from HDD was the n°1 performance issue as it was thousands of time slower than CPUs ; nowadays the fastest SSDs have sequential reads that read at 12GB/s (DDR3-1600 speeds!) which can easily be much faster that whatever non-trivial processing you'll apply to the data, so the bottleneck moved from IO to CPU.

I'm not sure that I'd want to avoid using a good abstraction because 20 years from now, it may perform marginally worse than it could had it been modeled with much more complexity. Clearly it depends on the use case, but you get my point.

Reply on news.ycombinator.com