系统与基础设施danluu.com编辑精选
80 年代以来 CPU 的新变化及其对程序员的影响
What's New in CPUs Since the 80s and How Does It Affect Programmers?
2015 — 2022，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
Dan Luu 的这篇长文梳理了自 80 年代以来 CPU 架构的关键演进——SIMD 指令、内存序与原子性、缓存与页大小的关系、功耗管理等——并解释这些底层变化对程序员编写高性能代码的实际影响。文章在 2015 和 2022 年两度登上 HN 首页，评论区还补充了 2015 年之后的新进展。
为什么经久不衰：它把几十年的 CPU 硬件演进浓缩成对程序员真正有用的知识，内容不随时间过时，至今仍是理解现代处理器行为的经典入门读物。
HN 评论精选
SIMD 的持续扩展让 CPU 日益逼近 GPU 的图形处理能力
SIMD 寄存器不断加宽是个值得关注的趋势：MMX 从 64 位起步，如今 AVX-512 已是它的 8 倍。加上多核心、每核多个 SIMD 单元，CPU 是否正变得越来越适合处理原本只有 GPU 才能胜任的图形工作负载？
bluetomcat查看英文原文
The constant widening of the SIMD registers is an interesting trend to watch. MMX started off as 64-bit, and now AVX-512 is 8 times that. With many cores and a couple of SIMD units in each core, aren't CPUs becoming ever more suitable to handle graphic workloads that were once reasonable only for GPUs?
通过具体推演验证了非原子自增的理论下限确实可以远低于直觉
作者说两个线程各对同一位置执行 10000 次 incl 自增，结果理论上可能低到 2。我起初以为下限应是 10000，但推演后发现确实可能得到 2：两个线程都读到 0，线程 1 自增 9999 次后写回，线程 2 写回 1，然后双方再读到 1，重复一轮就得到 2。x86 的一致性机制有什么会禁止这种情况、使实际下限为 10000 吗？
pedrocr查看英文原文
>If we set _foo to 0 and have two threads that both execute incl (_foo) 10000 times each, incrementing the same location with a single instruction 20000 times, is guaranteed not to exceed 20000, but it could (theoretically) be as low as 2. Initially it seemed to me the theoretical minimum should be 10000 (as the practical minimum seems to be). But it does indeed seem possible to get 2: 1) Both threads load 0 2) Thread 1 increments 9999 times and stores 3) Thread 2 increments and stores 1 5) Both threads load 1 5) Thread 2 increments 9999 times and stores 6) Thread 1 increments and stores 2 Is there anything in the x86 coherency setup that would disallow this and make 10000 the actual minimum?
指出文中内存栅栏一节对 x86 强内存序的描述有误
作者关于内存栅栏的部分是错的。x86 是强内存序，写操作对其他核心总是按程序顺序可见；栅栏用于保证读写对内存总线的可见性。作者举的例子并不适用于 x86（不过非临时 SIMD 流式指令等特殊内存类型例外，那时 SFENCE/LFENCE/MFENCE 才有用）。
acallan查看英文原文
The author is incorrect in the section about memory fences. x86 has strong memory ordering [1], which means that writes always appear in program order with respect to other cores. Use a memory fence to guarantee that reads and writes are memory bus visible. The example that the author gives does not apply to x86. [1]There are memory types that do not have strong memory ordering, and if you use non-temporal instructions for streaming SIMD, SFENCE/LFENCE/MFENCE are useful.
从业者证实虚拟索引缓存的实现难度，并引出 M1 大缓存设计的疑问
关于 L1 缓存大小受页大小×相联度限制的分析很有意思。我曾参与构建 ARM A55 的虚拟索引缓存，可以证实那完全是场噩梦，难怪 Intel 和 AMD 一直把 L1 数据缓存控制在避免它的范围内。有趣的是 Apple M1 用 128KB 数据缓存，可能走了虚拟索引路线——不过他们统一用 16K 页，8 路相联下仍可物理索引。那运行 4K 页的 x86 代码时怎么办？会砍掉 75% 的 L1 缓存吗？
gchadwick查看英文原文
Interesting point about L1 cache sizes and the relationship between page size > Also, first-level caches are usually limited by the page size times the associativity of the cache. If the cache is smaller than that, the bits used to index into the cache are the same regardless if whether you're looking at the virtual address or the physical address, so you don't have to do a virtual to physical translation before indexing into the cache. If the cache is larger than that, you have to first do a TLB lookup to index into the cache (which will cost at least one extra cycle), or build a virtually indexed cache (which is possible, but adds complexity and coupling to software). You can see this limit in modern chips. Haswell has an 8-way associative cache and 4kB pages. Its l1 data cache is 8 * 4kB = 32kB. Having helped build the virtually indexed cache of the arm A55 I can confirm it's a complete nightmare and I can see why Intel and AMD have kept to the L1 data cache limit required to avoid it. Interestingly Apple may have gone down the virtually indexed route (or possibly some other cunning design corner) for the M1 with their 128 kB data cache. However I believe they standardized on 16k pages which would allow still allow physical indexing with an 8 way associative cache. So what do they do when they're running x86 code with 4k pages? Does they drop 75% of their L1 cache to maintain physical indexing? Do they aggressively try and merge the x86 4k pages into 16k pages with some slow back-up when they can't do that? Maybe they've gone with some special purpose hardware support for emulating x86 4k pages on their 16k page architecture. Have they just indeed implemented a virtually indexed cache?
历次讨论
同类还值得读
TTY 揭秘（2008）
The TTY demystified (2008)
经典文章深入剖析了 Unix/Linux 中 TTY 子系统的工作原理，包括线路规程、终端驱动、信号与控制字符等机制。
系统与基础设施上首页 11 次 · 2009–2025linusakesson.net编辑精选为什么 GNU grep 这么快
Why GNU grep is Fast
FreeBSD 邮件列表上一篇广为流传的帖子，解释 GNU grep 为什么快：核心在于 Boyer-Moore 字符串搜索算法配合精心优化的内部循环和 I/O，让程序在搜索时“…
系统与基础设施上首页 9 次 · 2010–2022lists.freebsd.orgXplain：为普通人讲解 X11
Xplain – Explaining X11 for the rest of us
《Xplain》是作者（HN 用户 Jasper_）写的一系列 X11 长文，用他在浏览器中重建的 X11 绘图模型做交互演示，讲解 X11 的绘图模型与窗口系统设计。
系统与基础设施上首页 6 次 · 2013–2020magcius.github.io编辑精选旋风教程：为 Linux 创建极小 ELF 可执行文件（1999）
A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux (1999)
breadbox 写于 1999 年的经典教程，主题是如何为 Linux 手工构造并裁剪出体积极小的 ELF 可执行文件。
系统与基础设施上首页 6 次 · 2007–2025muppetlabs.comPostgreSQL 内部原理
The internals of PostgreSQL
《The Internals of PostgreSQL》是一本免费在线书籍，系统讲解 PostgreSQL 的内部实现，包括查询处理、并发控制、WAL、缓冲区管理等核心机制。
系统与基础设施上首页 5 次 · 2017–2025interdb.jp编辑精选