I believe that the gist is not really meant to provide accurate numbers in every case. Especially with things like network latency, it is very difficult to say that any time is the 'correct' time because it will be different in any case. The real purpose of the gist, which is posted at regular intervals here, is to illustrate the order of magnitude differences between e.g. the L1 cache and L2 cache latency. It is meant to get a programmer to think about cache locality. If I can keep something in L1/L2 cache, it will be orders of magnitude faster than something that needs to make regular round trips to main memory, which is orders of magnitude faster than something that needs to make regular round trips to disk, and so on.
I guess I took the title too literally. I would expect every competent programmer to know what you explained, and that is probably what the title was alluding to.
That sequential reading from an HD varies a lot, and can be anywhere from where it is to somewhat faster than SD (but seek doesn't change much).
The datacenter round-trip and sequential reading from memory sometimes change places now, and sending 1MB on some networks is on the same ballpark of reading 1MB from memory. (There has been some articles about this change here on HN.)
This is a great list. The one that I see people ignore the most is the fact that spinning disk access is 20x the cost of a datacenter roundtrip. If you need low-latency persistence, something like Apache Kafka is a much better solution than a disk (as long as your scale justifies it).
Generally Kafka takes advantage of the OS page cache and the fact that its data is sequential. The reason you can back Kafka effectively with spinning disks is because Kafka is just an immutable log.
OTOH you won't always have sequential access so services that store data in memory cover some of those other cases (eg a KV store like Redis).
A big thing that is missing is dropped packets. Our IT director moved everything offsite with the same justification, and now we constantly have issues because our front-end software does not handle dropped packets well.
Edit: Also, in 10,000 ns, light travels about 3 km in a vacuum. I know latency is addressed a bit in there, but our closest DC is about 70 km away from our main office. That's a pretty substantial hit on latency, especially considering our servers still have spinning discs in them.
It's worth noting that opening a file can have much longer latency than the disk read number in this table on consumer machines due to two factors:
a) power policy causes hard drive to power off. Spin up time is on the order of seconds.
b) user installed virus scanner hooks your process' file open or read to perform scan. This can typically take time on the order of hundreds of milliseconds.
These numbers are also important when writing software that runs on consumer PCs where real-time performance is a feature (e.g. most PC games).
22 comments
[ 3.0 ms ] story [ 59.9 ms ] threadHow outdated are some of these numbers?
According to this[1] source (linked in the gist comments), ping is down to 144ms from LA to Amsterdam.
[1]: https://wondernetwork.com/pings/
Thanks for clarifying.
The datacenter round-trip and sequential reading from memory sometimes change places now, and sending 1MB on some networks is on the same ballpark of reading 1MB from memory. (There has been some articles about this change here on HN.)
https://people.eecs.berkeley.edu/~rcs/research/interactive_l...
(Use the slider)
It shows disk seek and and sequential SSD read going down a lot. However, it also extrapolates out to 2020.
The code listing does have a lot of sources, and shows the extrapolation done, which I didn't look into in great detail.
[1] http://www.oilshell.org/blog/2016/12/23.html
[1] https://www.youtube.com/watch?v=JEpsKnWZrJ8
Note that it also assumes low network latency, though; if you have congestion within the data center, things change.
OTOH you won't always have sequential access so services that store data in memory cover some of those other cases (eg a KV store like Redis).
Edit: Also, in 10,000 ns, light travels about 3 km in a vacuum. I know latency is addressed a bit in there, but our closest DC is about 70 km away from our main office. That's a pretty substantial hit on latency, especially considering our servers still have spinning discs in them.
It shows you by series of questions, how fast code run, what is speed of ram vs cache, ram vs hdd, file vs sql read.
Highly recommended.
These numbers are also important when writing software that runs on consumer PCs where real-time performance is a feature (e.g. most PC games).