系统与基础设施aloiskraus.wordpress.com
为什么 Skylake CPU 有时会慢 50%：Intel 如何破坏了现有代码
Why Skylake CPUs Are Sometimes 50% Slower
2018 — 2020，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇文章分析了 Intel Skylake-X CPU 上某些 .NET 程序变慢 50% 的原因：Skylake 大幅提高了 PAUSE 指令的延迟，而 .NET 运行时的自旋锁实现大量使用该指令做指数退避，导致锁竞争场景下性能骤降。作者认为 Intel 的这一改动破坏了依赖旧指令时序的现有代码。
为什么经久不衰：它记录了微架构改动如何暴露软件对硬件时序的隐式依赖，是理解自旋锁、PAUSE 指令与性能调优权衡的经典案例。
HN 评论精选
问题出在 .NET 的自旋实现，而非代码被破坏
标题有误导性——没有代码被破坏，只是存在锁竞争的 .NET 程序会变慢。问题的根源在于 .NET 实现了一个相当复杂的自旋循环，对 CPU 和操作系统架构做了多种假设。与我见过的其他自旋循环不同，它们在每次循环中执行多条 pause 指令，这可以说是个糟糕的选择。这个设计的历史很有意思，大概是 .NET 还闭源时定下的。
jstarks查看英文原文
The title is misleading — no code is broken, though it is true that .NET programs that exhibit lock contention will be slower. The root of the problem is that .NET implemented a rather baroque spin loop with several assumptions about the CPU and OS architecture. Unlike any other spin loop I have seen or written, they execute multiple pause instructions per loop. Arguably this was a poor choice. It would be interesting to see the history of this design. It was probably done years ago when .NET was closed source.
罪魁是 .NET 的指数退避设计，不是 PAUSE 指令本身
Intel 文档提到 PAUSE 并不适合“数千周期以上”的等待——即使在旧架构上，10ms 也远超推荐值。另外我不同意“这不是 .NET 的问题，它影响所有使用 pause 指令的自旋锁实现”这一结论：指令本身不是问题，.NET 包含的指数退避才是。极端情况下（64 核 CPU 的最后一次迭代）它会自旋 120 万条 pause 指令。
al2o3cr查看英文原文
The Intel docs mention that PAUSE isn't the right choice for waits of "thousands of cycles or more" - even on the old architecture, 10ms is waaaaaay longer than recommended. I also have to quibble with this conclusion: This is not a .NET issue. It affects all Spinlock implementations which use the pause instruction. The instruction isn't the issue, the exponential backoff that .NET includes is. At the extreme (last iteration, on a 64-core CPU) it will spin for 1.2 million pause instructions...
社区共识是 .NET 的锅，且后来已修复
这是 2018 年的文章，当时被广泛讨论过。普遍共识是 .NET 运行时的自旋实现有问题：既对 PAUSE 指令使用不当，整体设计中也存在过度自旋。据我所知 .NET 后来已修复，也没听说其他代码受影响。
ajross查看英文原文
This is from 2018. It was extensively discussed at the time. The broad consensus was that it was the .NET runtime's spin implementation at fault, both because of the suboptimal use of the PAUSE instruction itself and because of the overall design that had excessive spinning in a few spots. Effectively, IIRC, they were putting the "pause" instruction on the hot path where they needed to exit the loop synchronously, and that's just wrong. Basically no one sane would look at a change log that said "exit latency from pause will now be similar to a pipeline stall" and done anything but shrug. It's since been addressed in .NET, as far as I know. And I'm not aware of any other affected code.
Intel 可能是故意放慢 PAUSE 以省电让资源，但在此场景适得其反
文章漏掉了一个重点：PAUSE 过去延迟固定且很短，现在是可变的。我猜 Intel 是看到 pause 被大量用于自旋锁、浪费功耗和功能单元，于是故意放慢自旋以省电、把资源让给同核的超线程和其他核心，理论上整体计算会更快完成。但在这个案例中没起作用——可能是因为其他线程在跑不含 pause 的自旋锁，结果整体反而更慢。
londons_explore查看英文原文
I think this article misses a major point... PAUSE used to have a fixed quite short latency. It now has a variable latency. I would hazard a guess that the latency strongly depends what the other cores on the machine are doing, and the other thread on the same core. Specifically, I would guess intel saw pause being used in spinlocks, and seeing a lot of power and time on functional units being wasted on locks that spin a lot. They decided to deliberately slow down a spinlock's spinning to use less power, and less of other functional units, and in doing so will free up functional units for the computations on the other hyper-thread and power/thermal headroom for other cores in the same CPU. By doing so, the thought is that overall, the computation should complete sooner. If both hyperthreads on a core execute pause, I'd expect the latency to go to very low again. Yet that reasoning didn't work in this case... The only explanation I can think of is that while some threads are executing pause instructions, other threads are executing other kinds of spinlock's without pause instructions. Those other spinlock's end up spinning faster now they have more functional units, but still making no forward progress. The overall result is the computation isn't sped up, and you still pay a latency penalty to notice the computation is done, hence slower overall.
历次讨论
同类还值得读
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编辑精选