HackerTubewatch
Surprise me
Frame from Admiral Grace Hopper Explains the Nanosecond Plays via YouTube's privacy-enhanced embed

Admiral Grace Hopper Explains the Nanosecond

funbury
Lectures
YouTube
5 HN users recommended this lecture5 months2020–2025 score 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)

1 strong recommendations · 4 recommendations · 7 citations · Lectures

12 Hacker News comments

From the HN archive; up to 20 kept per video, favoring different commenters. Recommendations first.

@dougmwne Jan 2020 Recommends
on HN thread A low-mass planet candidate orbiting Proxima Centauri
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
@klyrs Jun 2021 Recommends
on HN thread Your CPU may have slowed down on Wednesday
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]
Hopper's lesson on caring about performance
@throw0101a Dec 2021 Recommends
on HN thread I bought 1000 meters of wire to settle a physics debate [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

Citations, criticism and jokes

@cogman10 Jun 2021 Cites it
on HN thread Your CPU may have slowed down on Wednesday
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
@BenoitEssiambre Mar 2022 Cites it
on HN thread How our free plan stays free
Read more
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
Hopper reminds us distance matters in computing
@BenoitEssiambre Aug 2022 Cites it
on HN thread Use one big server
Read more
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
Hopper on hard latency limits of distance
@faeriechangling Aug 2022 Cites it
on HN thread Use one big server
>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.
@throw0101a Nov 2022 Cites it
on HN thread How Precision Time Protocol is being deployed at Meta
Read more
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?
Illustrates how long a nanosecond is
@ForOldHack Sep 2024 Cites it
on HN thread In 1870, Lord Rayleigh used oil and water to calculate the size of molecules
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.

Keyboard shortcuts

/
Search
j k
Next / previous video
r
Surprise me
l
Like (video page)
w
Watch later (video page)
?
This help
Esc
Close