5 HN users recommended this lecture5 months2020–2025score 5.5
Years with an HN recommendation, 2007–2026
HN uses it to illustrate physical latency limits and why performance and distance matter in computing.
Admiral Grace Hopper holds up a length of wire to show how far light travels in a nanosecond, about 11.8 inches. She explains how she made the idea concrete to people who could not picture a billionth of a second.
“Admiral Grace Hopper Explains the Nanosecond" is a good illustration of this (segment is only 2m)” (HN, 2021)
My favorite is more a small presentation than an image: Admiral Grace Hoper Explains a Nanosecond. [this video] For me it changed my mind on wasting time on less efficient algorithms.
Yes it is and no it isn't. Learn from Admiral Grace Hopper: [this video] The speed of light in fiber optic cable is about 2/3 the speed of light, which is why SpaceX's Starlink will have a potential latency advantage over oceanic fiber optics. It also gives good perspective on what's being thrown away when you add a single ms of latency through a router or a display. 186 miles at the speed of light. Many on HN don't get this, but this is why cloud gaming is perfectly feasible if we're running with low latency displays and inputs, low distance to the edge compute, and few routing hops.
Grace Hopper shows how far light travels in a nanosecond
> The nanosecond wire alone should be a compelling argument. For those that haven't seen it: [this video] (Of course, I expect that most here have, but xkcd 10,000 and all that.)
Speaking as somebody who never stopped optimizing like its the 90s: there's definitely a learning curve, but when microbenchmarking becomes a reflex, you learn your language in depth and the burden drops quickly. It only seems esoteric to you because the industry has collectively decided that Grace Hopper is an old codger who doesn't need to be listened to. [this video]
> Light is slow, not exactly 1 foot per nanosecond but it's a reasonable mnemonic. "Admiral Grace Hopper Explains the Nanosecond" is a good illustration of this (segment is only 2m): * [this video] * [link] Full lecture: * [link]
Two-minute segment illustrating how long a nanosecond is
Pretty reminiscent of Grace Hopper's nanosecond lecture [1] Certainly there are reasons why a feature might slow down a system beyond the branching (for example, if it requires you to load other resources)... but really, the issue is that as pointed out in the youtube video. Software companies very frequently do not care about performance. [1] [this video]
Software companies often do not care about performance
I would add that software infrastructure can run incredibly fast and scale incredibly well on modern hardware if you're a bit careful about resource usage. Traditional relational DBs like Postgresql are very scalable on modern hardware. If you take the time to craft a normalized schema with low redundancy being careful about keeping data small, you can achieve performance and resource efficiency and cache efficiency hundreds of time better than bloated distributed document nosql based systems. You can also get better transactional integrity, reduce reliance on queues (use load balancers instead) and get more instant and more atomic error propagation and edge case resolution. You can really build something lean and mean to a point that would be physically impossible in distributed systems or systems that involve multiple hops over potentially congested networks (as Admiral Grace Hopper likes to remind us, distance matters in computing [this video] ). As far as I know, normalized relational databases are still the best at efficiently using multiple levels of physically near caches to their full potential. Most applications don't need to scale horizontally and can easily fit on single servers (that can scale to dozens of cores and terabytes of ram). I hear arguments that it's the engineers that are expensive so it's ok to be wasteful with hardware if it saves engineering time but in my experience the type of engineers that are good at optimizations are often good at engineering in ge
I'm glad this is becoming conventional wisdom. I used to argue this in these pages a few years ago and would get downvoted below the posts telling people to split everything into microservices separated by queues (although I suppose it's making me lose my competitive advantage when everyone else is building lean and mean infrastructure too). In my mind, reasons involve keeping transactional integrity, ACID compliance, better error propagation, avoiding the hundreds of impossible to solve roadblocks of distributed systems ( [link] ). But also it is about pushing the limits of what is physically possible in computing. As Admiral Grace Hopper would point out ( [this video] ) doing distance over network wires involves hard latency constraints, not to mention dealing with congestions over these wires. Physical efficiency is about keeping data close to where it's processed. Monoliths can make much better use of L1, L2, L3, and ram caches than distributed systems for speedups often in the order of 100X to 1000X. Sure it's easier to throw more hardware at the problem with distributed systems but the downsides are significant so be sure you really need it. Now there is a corollary to using monoliths. Since you only have one db, that db should be treated as somewhat sacred, you want to avoid wasting resources inside it. This means being a bit more careful about how you are storing things, using the smallest data structures, normalizing when you can etc. This is not to save disk, disk is che
>As Admiral Grace Hopper would point out ( [this video] ) doing distance over network wires involves hard latency constraints, not to mention dealing with congestions over these wires. Even accounting for CDNs, a distributed system is inherently more capable of bringing data closer to geographically distributed end users, thus lowering latency.
So they state: > One could argue that we don’t really need PTP for that. NTP will do just fine. Well, we thought that too. But experiments we ran comparing our state-of-the-art NTP implementation and an early version of PTP showed a roughly 100x performance difference: While I'm not necessarily against more accuracy/precision, what problems specifically are experiencing? They do mention some use cases of course: > There are several additional use cases, including event tracing, cache invalidation, privacy violation detection improvements, latency compensation in the metaverse, and simultaneous execution in AI, many of which will greatly reduce hardware capacity requirements. This will keep us busy for years ahead. But given that NTP (either ntpd or chrony) tends to give me an estimated error of around (tens of) 1e-6 seconds, and PTP can get down to 1e-9 seconds, I'm not sure how many data centre applications need that level of accuracy. > We believe PTP will become the standard for keeping time in computer networks in the coming decades. Given the special hardware needed for the grand master clock to get down to nanosecond time scales, I'm doubtful this will be used in most data centres of most corporate networks. Adm. Grace Hopper elegantly illustrates 'how long' a nanosecond is: * [this video] How many things need to worry the latency of signal travelling ~300mm?
The speed of light, because it is so fast, is the most precise physical constant known : 299 792 458 m / s. Less than 7/1000ths away from 300,000,000 m / s. I am not going to sweat this in the least. So light travels only 0.3 m / nano second, or 11.802 inches. [this video]
Hopper's physical demonstration of how far light travels in a nanosecond
Video list and Hacker News comment labels from HackerTube (prompted by @karpathy), released under ODC-By 1.0, built on the open-index/hacker-news archive. Hacker News data is provided by Y Combinator; comments remain the work of their authors. Video titles, channel names and thumbnails belong to their creators and are shown via YouTube. HackerTube Watch is an unofficial edition. Data export of 2026-10-31.
12 Hacker News comments
From the HN archive; up to 20 kept per video, favoring different commenters. Recommendations first.
Citations, criticism and jokes
Read more
Read more
Read more