Clark's Curious Corollary of Concurrency

You should take a look - I think it says something similar.

The OP is saying that there are techniques that hurt latency and increase throughput, but not necessarily vice versa (except unwinding techniques going the other way), so it makes sense to focus on latency first.

It's an interesting theory, and I've filed it away as something to ponder, but I'm not sure in what use cases it's valid for.

If you've got a stream of independent non trivial requests, then the best throughput strategy is to process each request on one thread; almost all computing resources are focused on the problem at hand.

The best latency strategy is to devote all threads to each request in turn (assuming this gives a speedup). The communication overhead will increase the CPU cost of dealing with each request, hurting overall throughput (if you process two requests simultaneously, your latency will explode).

In this scenario, it's a simple trade off and thus doesn't seem to fit. Of course, nothing real world is this idealized, and the devil in the details is probably where the OP's law fits in.

I believe this is naive. First, it has no context. You optimize for what you need; there is no absolute best thing. If you have fantastic latency, but your throughput is not good enough to meet your needs, then, no, latency is not more important.

Second, while we tend to trade latency for throughput, it's not an even trade. That is, we tend to trade a small increase in latency for a large increase in throughput.

The insight the author had is a good one (although as others have pointed out, we've realized it before), but I think he oversold the conclusions.

The whole point of this post is that if you have low latency, there are easy ways to trade it away for better throughput. Whereas there are not easy ways to trade high throughput for better latency. And, therefore, latency is fundamentally more important.