5 ms·

It is clearly not an ideal abstraction for anything CPU bound. But for anything IO bound, it is a much more natural way to tame the complexities of concurrency

by xedrac 3y ago

It is clearly not an ideal abstraction for anything CPU bound. But for anything IO bound, it is a much more natural way to tame the complexities of concurrency.

amelius 3y ago
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.
- Dowwie 3y ago
  What do you mean by this claim that what is io bound today may be cpu bound tomorrow?
  - toast0 3y ago
    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.
  - seized 3y ago
    The transition from spinning disks to SATA/SAS flash to NVMe.
  - jcelerier 3y ago
    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.
    - xedrac 3y ago
      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.

by xedrac 3y ago

It is clearly not an ideal abstraction for anything CPU bound. But for anything IO bound, it is a much more natural way to tame the complexities of concurrency.

amelius 3y ago

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.

Dowwie 3y ago
What do you mean by this claim that what is io bound today may be cpu bound tomorrow?
- toast0 3y ago
  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.
- seized 3y ago
  The transition from spinning disks to SATA/SAS flash to NVMe.
- jcelerier 3y ago
  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.
  - xedrac 3y ago
    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.