Latency numbers every programmer should know

``` for (const { children } of document.getElementsByClassName(&quot;latency-container&quot;)) { console.log(`${children[0].innerText.padEnd(35, &quot; &quot;)} = ${children[1].innerText}`); } ```<p>L1 cache reference = 1ns<p>Branch mispredict = 3ns<p>L2 cache reference = 4ns<p>Mutex lock&#x2F;unlock = 17ns<p>Send 1K bytes over 1 Gbps network = 44ns<p>Main memory reference = 100ns<p>Compress 1K bytes with Zippy = 2us<p>Read 1 MB sequentially from memory = 3us<p>Read 4K randomly from SSD = 16us<p>Read 1 MB sequentially from SSD = 49us<p>Round trip within same datacenter = 500us<p>Read 1 MB sequentially from disk = 825us<p>Disk seek = 2ms<p>Send packet CA-&gt;Netherlands-&gt;CA = 150ms<p>Can we discuss the actual material now.

I say this without hate: it&#x27;s absolutely fascinating how bad this UX is. Having said this, I am sure that I have committed worse UX crimes in my career, but when curse of knowledge hits you, only your users can see the problems. But lucky samwho has the HN community that is not shy of criticizing ;-).<p>I think it&#x27;s really interesting and instructional to think about <i>why</i> the UX feels so bad. My ideas are:<p>- The page has one main job: presenting latency numbers to the viewer.<p>- This job is easy enough. There are many ways to get this done. So people expect the main job to be done at least as good as with these other ways.<p>- I hypothesize that the page prioritizes other jobs before the main job. It tries to make finding the relationship between those numbers fun to detect. * Users are foremost interested in the main job, but this main job is done poorly because you don&#x27;t see all latency numbers in one view (maybe after clicking a few times at the right places, but for such an easy task this is way too much work)<p>- It&#x27;s very difficult to grasp the mental model of the UI just aby using it. You click somewhere and things happen. Even now that I have used it for a few minutes, I have no idea what it does or is supposed to do. I found it very interesting how much it frustrated my that repeated clicks are not idempotent and made the UI &quot;diverge&quot;. It makes you somehow feel lost and worry about breaking things.<p>- The user must read the help text. But users don&#x27;t do this. At least I didn&#x27;t until I was very frustrated. Then this help text changes. And changes again. I don&#x27;t want to learn a new application only to read a simple list of numbers.<p>These are my main points, I think. To me, it was very interesting. Thanks for that, samwho. and kudos for sharing this publically :-)

The title is missing &quot;Latency&quot; which would show many other results on searching. My go to is this one[0] because it&#x27;s plain text and shows &quot;Syscall&quot; and &quot;Context switch&quot;.<p><pre><code> Latency numbers every programmer should know L1 cache reference ......................... 0.5 ns Branch mispredict ............................ 5 ns L2 cache reference ........................... 7 ns Mutex lock&#x2F;unlock ........................... 25 ns Main memory reference ...................... 100 ns Syscall on Intel 5150 ...................... 105 ns Compress 1K bytes with Zippy ............. 3,000 ns = 3 µs Context switch on Intel 5150 ............. 4,300 ns = 4 µs Send 2K bytes over 1 Gbps network ....... 20,000 ns = 20 µs SSD random read ........................ 150,000 ns = 150 µs Read 1 MB sequentially from memory ..... 250,000 ns = 250 µs Round trip within same datacenter ...... 500,000 ns = 0.5 ms Read 1 MB sequentially from SSD* ..... 1,000,000 ns = 1 ms Disk seek ........................... 10,000,000 ns = 10 ms Read 1 MB sequentially from disk .... 20,000,000 ns = 20 ms Send packet CA-&gt;Netherlands-&gt;CA .... 150,000,000 ns = 150 ms Assuming ~1GB&#x2F;sec SSD </code></pre> [0] <a href="https:&#x2F;&#x2F;gist.github.com&#x2F;nelsnelson&#x2F;3955759" rel="nofollow">https:&#x2F;&#x2F;gist.github.com&#x2F;nelsnelson&#x2F;3955759</a>

I bring criticism: The first few bars on my screen cannot be read, as the text is hidden behind the floating HUD. If I click on the next few bars, to bring those below the box, then the bar becomes too small and the text is cropped, so I cannot read it either.<p>It is also a bit uncomfortable to read 90° text. It&#x27;s fun to click the bars and play with the UI, but not to actually read what they say. It&#x27;s a nice visualization, but it suffers from form over function! I can&#x27;t comfortably use it to learn about the numbers I should know :(

Lineage:<p>- Peter Norvig (original (?)) - <a href="http:&#x2F;&#x2F;norvig.com&#x2F;21-days.html#answers" rel="nofollow">http:&#x2F;&#x2F;norvig.com&#x2F;21-days.html#answers</a><p>- Jeff Dean (slides) - <a href="https:&#x2F;&#x2F;www.cs.cornell.edu&#x2F;projects&#x2F;ladis2009&#x2F;talks&#x2F;dean-keynote-ladis2009.pdf" rel="nofollow">https:&#x2F;&#x2F;www.cs.cornell.edu&#x2F;projects&#x2F;ladis2009&#x2F;talks&#x2F;dean-key...</a><p>- Colin Scott - <a href="https:&#x2F;&#x2F;github.com&#x2F;colin-scott&#x2F;interactive_latencies?tab=readme-ov-file">https:&#x2F;&#x2F;github.com&#x2F;colin-scott&#x2F;interactive_latencies?tab=rea...</a><p>- this post

Some of these have always been quite counterintuitive to me, particularly the networking ones. Google Stadia was always an exercise in edge cases in expectations on these numbers for me.<p>It felt weird that a gaming computer in a datacenter could be &quot;faster&quot; than a computer on my network, but one frame takes ~16ms to render, bandwidth is big enough to stream, network latency might only be another ~frame, and suddenly the image is on my machine within 2 or 3 frames. However there were unexpectedly slow parts! The controller actually ran over WiFi directly, so that inputs went straight to the server rather than via Bluetooth, comparing with Xbox Cloud on a Bluetooth controller, this made a huge difference, but that makes sense because Bluetooth&#x27;s latency might be 1-2 frames itself. It&#x27;s counterintuitive to me that the latency from my controller to my computer, less than 1m, might be higher than the latency from my computer, to my router, to my ISP, to Google&#x27;s DC, and to a server. Similarly, the latency on HDMI from a computer to my TV is in the same ballpark of a few frames because of all the processing my cheap TV does to look good.

I&#x27;m on Firefox mobile. I can make head nor tail of what this is meant to demonstrate.

The meaning of the number with the + and - is completely escaping me. It looks like a year but goes into the future.

Slightly mysterious title. I thought it would be about 16, 256, 65536, 16777216, 4294967296, etc.

The 1MB streaming data from disk should be closer to 4ms (250MB&#x2F;s). Disk streaming rates (on 7200rpm drives) have not improved significantly, based upon the published “sustained transfer rate OD” metrics from the three drive manufacturers.

The time to send over a 1Gbps network looks very wrong. Each bit takes 1ns (by definition) so sending 1K byte must take at least 8192ns

Holy smokes, this design is terrible and the site is unusable (on mobile at least).

Are we to believe that in 2030, sending 1K over a gig network will be faster than a CPU-internal missed branch prediction?<p>Seems highly unlikely for a wide variety of reasons.

the UX on this needs to be seriously reconsidered, I don&#x27;t read with the head tilted sideways. function over form if your target is technical ppl.

This is great. Lots of feedback and info sharing from everyone’s collective knowledge base. Lot of feedback from thr grey beards around in the retro era eg 1980-1990 and those who are on the bleeding edge inventing the future. Good job. Keep going.<p>1) If a technology didn’t exist. I’d make the bar black &#x2F; grey. The pedants will hound you to death<p>2) A means to see the trend of a given feature on log plot if necessary. Eg Memory access 1980-2030 is interesting.<p>3) An info icon on the bar (i in a circle) to get details about the measurement. Disks seek for example is pegged at 1ms because it’s where mechanical disks have limits. If so is it track to track or full stroke seek ?

reading sideways sucks

Very cool little thing. The interface initially isn&#x27;t very intuitive but once you figure out the correlation between the above&#x2F;below bar clicks it is kind of cool.

I made this! Happy to answer any questions.<p>Can’t stress enough how grateful I am to Colin Scott for doing the work and open sourcing the calculations for the latencies over time.

The design doesn’t work on safari on iPad, the navigation blocks the content and it’s not possible to read half the columns.<p>A simple ASCII blog post would have been better

How is this something &quot;every programmer should know&quot; ? I mean 95% of us work with software that is not performance critical, where security&#x2F;auditing&#x2F;monitoring&#x2F;stability&#x2F;maintainability&#x2F;etc. is more important than raw performance.

I keep reading that fragmentation doesn’t matter for SSDs. But the latency difference between a sequential read and a random read is absolutely huge? When are we going to accept that fragmentation really does matter?

interesting demo. also scaling logarithmically would look cool as most bars disappear most of the time. (maybe you can add horizontal bars to the background and scale the distances between them as well)

DC round trip at a constant 500 mics is a bit surprising to me. I guess it’s just a hard number for Scott to get historical values for, and depends a lot on how networking in a datacentre is set up.

Every programmer should know how to represent &quot;the numbers&quot;. Without reasonable representation your numbers are just useless crap.

Is there any explanation for why programmers need to know these numbers? I don&#x27;t know any of these and I, semi successfully, write some code (admittedly using nodejs).

Site is broken in mobile safari. Can&#x27;t scroll at all.

The design doesn’t work on safari on iPad, the navigation blocks the content and it’s not possible to read half the columns.<p>A simple ASCII blog post would have been better

Nice idea, but I found the UI awkward.<p>And I probably not the only one that took a few minutes to realize the number referred to the year.

It’s a nice visualization. Maybe move the label to above the bar if the bar becomes too short to fit it inside of it?

The original is honestly better: <a href="https:&#x2F;&#x2F;colin-scott.github.io&#x2F;personal_website&#x2F;research&#x2F;interactive_latency.html" rel="nofollow">https:&#x2F;&#x2F;colin-scott.github.io&#x2F;personal_website&#x2F;research&#x2F;inte...</a>

I really wanted to understand the numbers but the content does not help

The design is aesthetic and all, but it does not convey the information well.<p>Instead, just show an isometric graph with dates moving right-down, and each type, right-up, if that makes sense. Then, a single static 3d-ish image would show the different latencies and how they&#x27;ve changed over the years. No need for all the interactive gadgetry, that adds nothing, and in fact just obscures the big picture.

Repeatedly clicking the same bar keeps shrinking it... weird

The top 3 speeds have not changed in 15 years.<p>Love the site.

Where are these 1GBPS networks in 1980?

Some of those numbers are very weird.

Wait a packet CA -&gt; NL -&gt; CA was 150 ms in 1980?