HackerURLs

一次又一次被重新发现的经典。

同一个链接,相隔一年以上,一次又一次被人重新发现、再次冲上 Hacker News 首页。能经受住这种时间检验的,大多是值得一读再读的文章。每篇附中文标题,讨论最热的那些再加上中文导读和高赞评论翻译。

从名人堂开始
  • 4,700+篇经过时间检验的经典

Hall of fame

名人堂

在经典库里看全部精选

上首页次数最多、而且有中文导读的 30 篇。时间轴上每个黑点是一次上首页,空心点是一次没冲上去的投稿。

  1. 正在载入经典…

Archive

经典库

按第一次上首页的年份分布,点柱子筛选。

排序

    About

    这些经典是怎么挑出来的

    1. 01

      合并同一个链接

      读取 Hacker News 自 2006 年以来的全部链接投稿,把 http/https、www、跟踪参数等写法不同的同一篇文章合并成一条。

    2. 02

      只留经得起时间的

      同一链接至少两次拿到 50 分以上(约等于上首页),而且两次相隔一年以上;再由 AI 剔除状态页、产品首页和新闻事件。

    3. 03

      写导读、译评论

      上首页次数最多的 2,000 篇配上中文导读、"为什么经久不衰",并精选翻译 HN 高赞评论。导读由 AI 生成,可能有误。

    系统与基础设施danluu.com

    数据错位如何通过减少缓存未命中将性能提升 12 倍

    How misaligning data can increase performance 12x by reducing cache misses

    3次上首页
    3年跨度
    383累计得分
    62条评论

    2014 — 2017,它一次次回到首页

    黑点是上首页(≥ 50 分)的那次投稿,空心点是没冲上去的投稿,点越大分数越高。

    导读

    Dan Luu 的这篇文章通过实验展示:故意让数据错开页对齐,可以避免多个热数据映射到同一组缓存槽位(缓存冲突缺失),从而把性能提升 12 倍。文章解释了 n 路组相联缓存的工作原理,说明硬件缓存的实现细节(按地址低位做哈希、每组槽位有限)会实实在在地影响程序性能。

    为什么经久不衰:它用一个反直觉的实验揭示了 CPU 缓存组相联机制这个容易被软件工程师忽视的细节,是排查“本该很快却很慢”的内存访问问题时常被回头查阅的经典参考。

    关键词 CPU缓存性能优化缓存缺失内存对齐

    HN 评论精选

    澄清:文章讲的是页对齐,与字边界对齐/结构体打包是两回事

    这里很多评论以为这说的是不按字边界对齐(比如用 packed pragma、Sandy Bridge 支持非对齐访问等)。这和字对齐完全无关。正如文章开头所说,这里说的是页边界对齐,它和字边界或结构体打包是完全不同层面的东西,不要混淆。

    cowsandmilk查看英文原文

    I see many comments here acting like this means not aligning on word boundaries (e.g. using packed pragma, sandy bridge have unaligned access, etc.). This has nothing to do with word alignment. As the article states at the beginning, this is about aligning to page boundaries, which is on a very different level than word boundaries or structure packing. Let's not get these confused.

    组相联缓存的实现细节值得软件工程师了解,是排查性能问题的思路之一

    至少应该知道 n 路组相联缓存里那个 n 的存在,这篇文章是个很好的提醒。下次你遇到本该很快(本该常驻缓存)的数据访问却似乎不快时,这就是又一个可以排查的方向。从软件工程师的角度,很容易知道 CPU 有缓存,就以为它和自己写的软件缓存差不多。但实现细节——用地址掩码做哈希、哈希到同一桶的数据只有几个槽位可用——其实很重要,本文正说明了这一点。

    barrkel查看英文原文

    It's important to at least know about the n in n-way set associative cache (i.e. that it exists) and this article is a good reminder. Next time you see data accesses that ought to be fast (ought to be hot in cache) but seem not to be, this is another thing you can look for. It's easy, from a software engineer perspective, to know that your CPU has cache, and just think it's like any other cache you might implement in software. But the implementation details - the hashing by masking the address, and only having a few slots available for things that hash to the same bucket - are actually important, as shown here.

    提醒:该技巧依赖架构,非对齐访问在不同处理器上代价差异很大

    要记住的是,这个技巧并非对所有架构或同一架构的所有处理器都有效。有些架构不支持非对齐内存访问,会抛出异常;如果对结构体用 packed 属性,编译器会生成正确的代码但更慢——几乎总是多出很多指令,导致代码变大、缓存和译码缓存效率下降。作者用的是较新的 Intel 处理器;x86 一直支持非对齐访问,只是周期上更慢,而近年的 Intel 处理器已把这一代价大幅缩短,我认为这是网络应用推动的——它们更关注往信道里塞尽可能多的字节,而非对齐要求。

    mtanski查看英文原文

    One of the things to keep in mind here is that this trick won't work or work as well for every architecture or every processor family in that architecture. Some architectures do not support unaligned memory access and will raise an exception. If you're using things like packed attribute with your structs your compiler will generate the correct code but that code will be slower. In almost all cases it will generate many more instructions and because of that your cache will be less effective (due to larger code size) your decoder cache will be less effective, etc... The author has a more modern Intel processor. The x86 family always supported unaligned access, albeit it was always slower in terms of cycles. More recent Intel processor have made this penalty much shorter. I believe this was driven network applications many of which focus on efficiency of packing as many bytes down the channel and less on the alignment requirements. http://www.agner.org/optimize/blog/read.php?i=142&v=t

    指出这一技术的通用名称是缓存着色,许多分配器已内置支持

    这通常叫做“缓存行着色”(cache line colouring),很多分配器已经替你做了这件事。

    ori_b查看英文原文

    The usual term for this is "cache line colouring", and many allocators do this for you. http://en.wikipedia.org/wiki/Cache_coloring

    历次讨论

    同类还值得读

    1. TTY 揭秘(2008)

      The TTY demystified (2008)

      经典文章深入剖析了 Unix/Linux 中 TTY 子系统的工作原理,包括线路规程、终端驱动、信号与控制字符等机制。

      系统与基础设施上首页 11 次 · 2009–2025linusakesson.net编辑精选
    2. 为什么 GNU grep 这么快

      Why GNU grep is Fast

      FreeBSD 邮件列表上一篇广为流传的帖子,解释 GNU grep 为什么快:核心在于 Boyer-Moore 字符串搜索算法配合精心优化的内部循环和 I/O,让程序在搜索时“…

      系统与基础设施上首页 9 次 · 2010–2022lists.freebsd.org
    3. Xplain:为普通人讲解 X11

      Xplain – Explaining X11 for the rest of us

      《Xplain》是作者(HN 用户 Jasper_)写的一系列 X11 长文,用他在浏览器中重建的 X11 绘图模型做交互演示,讲解 X11 的绘图模型与窗口系统设计。

      系统与基础设施上首页 6 次 · 2013–2020magcius.github.io编辑精选
    4. 旋风教程:为 Linux 创建极小 ELF 可执行文件(1999)

      A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux (1999)

      breadbox 写于 1999 年的经典教程,主题是如何为 Linux 手工构造并裁剪出体积极小的 ELF 可执行文件。

      系统与基础设施上首页 6 次 · 2007–2025muppetlabs.com
    5. PostgreSQL 内部原理

      The internals of PostgreSQL

      《The Internals of PostgreSQL》是一本免费在线书籍,系统讲解 PostgreSQL 的内部实现,包括查询处理、并发控制、WAL、缓冲区管理等核心机制。

      系统与基础设施上首页 5 次 · 2017–2025interdb.jp编辑精选

    打赏支持

    打赏二维码

    觉得有用,请作者喝杯咖啡。

    WeChat

    关注向阳乔木

    微信公众号「向阳乔木推荐看」

    微信公众号「向阳乔木推荐看」二维码

    微信扫一扫;在微信里打开本页时,长按二维码识别。