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 生成,可能有误。

    系统与基础设施igoro.com编辑精选

    处理器缓存效应图集

    Gallery of Processor Cache Effects

    3次上首页
    9年跨度
    406累计得分
    74条评论

    2010 — 2019,它一次次回到首页

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

    导读

    这篇页面是 Igor Ostrovsky 的经典文章《Gallery of Processor Cache Effects》,用若干简短代码示例展示处理器缓存层次结构对程序性能的影响,涉及缓存行、伪共享等现象。它通过可测量的例子说明,看似等价的内存访问方式可能带来很大的速度差异。

    为什么经久不衰:因为它把抽象的缓存层次结构变成可复现的小实验,让开发者直观看到内存访问模式如何决定性能,十多年后仍是理解缓存友好的入门经典。

    关键词 CPU缓存性能优化伪共享内存层次

    HN 评论精选

    评论者用亲身经历说明:缺乏缓存一致性时,必须按缓存行隔离共享数据,否则会出现难以复现的崩溃。

    我在 LSI Logic 工作时,我们有一颗双核处理器,两个核之间完全没有缓存一致性。实际上必须把所有内存分配按缓存行填充,两个核才不会互相干扰。不幸的是,我们也让客户自己写代码。我们最好的客户之一 Motorola 有个项目开始出问题:代码稍作改动就会引发各种诡异崩溃。我被叫去帮忙,看完代码才发现没人告诉过他们缓存一致性问题。做了几处修改(只是把 .bss 和 .data 变量移到受缓存行保护的 malloc 分配里),所有问题就消失了。好笑的是他们的工程经理知道后打电话来骂我;他火气很大,我把电话开免提,叫来我的经理们在实验室围着听,让他发泄了几分钟直到没劲。这成了我们后来常拿来乐的传奇轶事。

    drmpeg查看英文原文

    When I worked at LSI Logic, we had a dual core processor that didn't have any cache consistency at all between cores. You actually had to pad all memory allocations to a cache line so that the two cores didn't interfere with each other. Unfortunately, we also let our customers develop their own code. One of our best customers (Motorola) starting having problems with one of their projects. Small changes in their code would cause all kinds of bizarre crashes. I was asked to help out and after reviewing their code, I realized that nobody had told them about the cache coherency issue. After making a few changes (just moving .bss and .data variables into cache line protected malloc's), all the problems disappeared. The funny part was when their engineering manager found out. He calls me on the phone and starts to chew me out. He was furious, so I put him on speaker and called my managers into the lab. We stood around and just let him rant for a few minutes until he ran out of steam. A legendary episode that we chuckled about many times thereafter.

    评论推荐了深入理解缓存与内存的经典长文《What Every Programmer Should Know About Memory》。

    这篇帖子写得很好,概括了缓存层次结构相关的主要痛点。想深入的话,经典参考是《What Every Programmer Should Know About Memory》。

    utopcell查看英文原文

    Nicely written post that summarizes the major pain points wrt cache hierarchies. The canonical reference for diving deeper is "What Every Programmer Should Know About Memory" [1]. [1] https://people.freebsd.org/~lstewart/articles/cpumemory.pdf

    评论者用亲身经历强调伪共享的隐蔽性:间歇性变慢很难定位,分析器粒度粗,经验也很关键。

    很好的总结。他说的“例 6”关于伪共享(false cache sharing)曾让我中招:我给线程分配的数据结构在内存里挨得太近,结果线程共享了缓存行。我花了一阵子才弄明白;能发现大概只是因为问题不是一直出现,所以我才纳闷代码为什么有时变慢。如果它稳定复现,我只会觉得这代码就是慢。虽然有些分析器会给出缓存命中率,但通常粒度是整个线程,很难定位到具体哪段代码有问题。而且你还得有足够经验判断什么是“正常”的命中率——我不确定自己具备。

    lutorm查看英文原文

    Nice summary. His "example 6", about false cache sharing, bit me once when I was allocating data structures for my threads and they ended up close enough in memory that threads shared cache lines. It took a while before I figured it out and probably the only reason I did was that it didn't happen all the time, so I was wondering why the code sometimes ran slower. If it had been consistent I would just have thought the code was slow. While there are profilers that spit out cache hit rates, it's usually on the scale of whole threads which makes it very difficult to find which code is bad. You also have to have enough experience to know what a "normal" hit rate is, which I'm not sure I am.

    评论者对示例中编译器未合并两次自增感到意外,并指出该例使用 C# 而非 C++。

    例 4 里我有点惊讶:既然分配就在同一个函数里、紧挨着使用处,编译器居然不能把 {a[0]++; a[0]++;} 优化成 {a[0]+=2;}。补充:我该继续往下读的,显然别人也提了同样的问题并且得到了回应。那个例子是 C# 而不是 C++,难怪我的直觉不对。

    Symmetry查看英文原文

    I was sort of surprised in example 4 that the compiler couldn't optimize {a[0]++; a[0]++;} to {a[0]+=2;}, given that the allocation was right there in the same function as the usage. EDIT: Should have kept reading, other people apparently had this same comment and it was addressed. This was for C# rather than C++ so no wonder my intuition was off.

    历次讨论

    同类还值得读

    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

    关注向阳乔木

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

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

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