[neilc]

Another factor is that technology improvements tend to favor increases in bandwidth over increases in latency (and there are hard limitations on latency, like the speed of light in distributed systems). This short paper by David Patterson is a great read on the subject:

http://www.cis.gvsu.edu/~kurmasz/Teaching/OldCourses/CS451/G...

[marcosdumay]

Well, in practice the latency that normaly matters is between "start doing activity" and "finish doing activity", and the time actualy working (that depends on bandwidth) is normaly orders of magnitude bigger than the time waiting for data (that depends on latency). There are exceptions, but not many.

And now that I really thought about it, looks like the article's law isn't that relevant in practice. Yes, you can always trade latency for bandwidth if you throw some money at it. But money is finite.

[neilc]

Well, in practice the latency that normaly matters is between "start doing activity" and "finish doing activity", and the time actualy working (that depends on bandwidth) is normaly orders of magnitude bigger than the time waiting for data (that depends on latency).

I don't think that's true; moreover, it is likely to become even less true in the future. Once the data needed for a computation has arrived at the CPU, for most applications the required computation is pretty cheap -- the time spent waiting for the data often dominates the time spent computing with the data. Much of modern CPU design has been devoted to trying to hide the high latency of memory accesses.