HackerPapers

HN 二十年,最值得读的论文。

从 Hacker News 2006 年以来的全部投稿里,挑出链接本身就是论文的帖子:arXiv、期刊、会议论文、技术报告。每篇附中文标题,讨论最热的那些再加上中文导读和高赞评论翻译。

从必读开始
  • 8,000+篇被 HN 讨论过的论文

Essential

必读 30 篇

在论文库里看全部精选

编辑精选里 HN 讨论最热的 30 篇,每篇都有中文导读。不知道从哪读起,就从这里开始。

  1. 正在载入论文…

Archive

论文库

点柱子按年份筛选。注:源数据里 2023 年的帖子分数记录不全,2026 年尚未过完,这两年收录偏少。

难度
排序

    About

    这些论文是怎么挑出来的

    1. 01

      全量扫一遍

      读取 Hacker News 自 2006 年以来的全部 446 万条链接投稿,找出指向 arXiv、期刊、会议、技术报告和学术 PDF 的帖子。

    2. 02

      只留论文本身

      由 AI 逐条判断,剔除介绍论文的新闻、博客和幻灯片,同一篇论文的多次投稿合并计算,并统计它在评论区被引用的次数。

    3. 03

      写导读、译评论

      讨论最热的 1,500 篇配上中文导读,并精选、翻译 HN 高赞评论。导读由 AI 生成,可能有误,请以原文为准。

    编程语言与软件工程2013arxiv.org

    解释型 Python 能有多快?

    How fast can we make interpreted Python? (2013)

    进阶 · 约 90 分钟读完前置知识:CPython 解释器原理、JIT 编译基础、C 扩展机制

    读论文 HN 讨论
    179HN 得分
    103条评论
    2次投稿

    导读

    这篇 2013 年的论文研究如何在不放弃 CPython 兼容性的前提下加速解释执行的 Python。作者实现了 Falcon——一个以 CPython 扩展形式运行、将基于栈的字节码编译为寄存器式代码的 JIT 编译器,在保持与现有 C 扩展兼容的同时,基准测试平均提速约 25%,最高可达 2.5 倍。

    HN 关注点:HN 读者长期关注 Python 性能问题,讨论焦点在于 C 扩展 API 兼容性是否是拖累解释器性能的根本枷锁,以及 Falcon 与 PyPy 等方案的取舍。

    关键词 PythonJITCPythonPyPy

    HN 评论精选

    扩展 API 兼容性才是 Python/Ruby 性能提升的根本障碍

    这里最大的问题似乎是:与 Python 扩展 API 的兼容性是拖累性能的锚。Ruby 也因持续兼容其扩展 API 而受害。论文中对比了 Lua 和 JavaScript,但值得注意的是 JavaScript 本身没有扩展 API,而 Lua 团队则以不在乎跨版本破坏 API 兼容而闻名。我想说的是,这个努力值得称赞,但 Python(和 Ruby)真正需要的是摆脱扩展 API 兼容性的枷锁。

    jballanc查看英文原文

    It seems like the biggest point here is that compatibility with the extension API in Python is the anchor dragging down performance. Similarly, Ruby suffers from continued compatibility with its extension API. In the paper they compare with Lua and JavaScript, but it's worth noting that JavaScript doesn't have an extension API (well, JavaScript proper...not saying anything about node.js), and the team behind Lua are notorious for not caring about breaking API compatibility between versions. I guess what I'm trying to say is, while this is a laudable effort, it seems what Python (and Ruby) really needs is a way to free itself from the chains of extension API compatibility.

    概括论文核心做法与性能数据,并补充源码链接

    这是一个栈式转寄存器式的 Python JIT 编译器,以 CPython 扩展的形式运行,因此保持与现有 C 扩展的兼容。论文基准测试中平均快 25%,最高达 2.5 倍。源码:https://github.com/rjpower/falcon/(直到论文最后才提到!)

    _ihaque查看英文原文

    Stack->register JIT compiler for Python that maintains compatibility with existing C extensions because it runs as an extension within CPython. Average of 25% faster to up to 2.5x on the benchmarks in the paper. Source link: https://github.com/rjpower/falcon/ (doesn't show up in the paper till the very end!)

    亲历对比:PyPy 接近 Node.js,但代码风格会影响其优化效果

    论文挺老了,纯 Python 依然慢,但 PyPy 已达到 Node.js 的水平。我用多种语言重写同一个程序(比较两张图片并生成差异图),以 CPython 为 1x 基准:Rust 100x,Go 60x,Node.js 12x,PyPy 10-11x。最初 PyPy 只有 4x,但我做了一次轻量重构,去掉一些多余的 map() 和 zip()(三元列表)之后,PyPy 就真的快了。

    epx查看英文原文

    Quite old, plain Python is still slow but PyPy is in the league of Node.js. I rewrote the same program (compare two images, generate a third that shows the diff) in a number of languages. Considering CPython as the reference implementation (1x), I got 100x in Rust, 60x in Go, 12x in Node.js and 10-11x in PyPy. Initially I got 4x with PyPy but I did a light refactor, removing some map()s and zip()s that were gratitious (3-element lists) and then PyPy went real fast.

    指出论文已过时,如今 PyPy 性能远超论文数据

    标题应该注明是 2013 年的。如今 PyPy 相对 CPython 的平均提速早已远超 25%。/edit:公平地说,Falcon 项目的 README 很好地说明了它与 PyPy 在目标和性能上的差异:https://github.com/rjpower/falcon/blob/master/README.md

    piquadrat查看英文原文

    Title should say 2013. These days, PyPy is way past 25% average speedup with respect to CPython. /edit to be fair, the project README points out the difference in goals and performance between Falcon and PyPy quite nicely: https://github.com/rjpower/falcon/blob/master/README.md

    相关资源

    从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。

    代码

    历次讨论

    同领域还值得读

    1. Google 的软件工程(2017)

      Software Engineering at Google (2017)

      介绍了 Google 的软件工程实践,包括其单一代码库(monorepo)、几乎全部开发在主干进行而非分支、代码审查、构建系统 Blaze、协议缓冲区等工具与流程,并讨论了频繁重…

      编程语言与软件工程2017 · 1,127 分 · 465 评 · 引用 15入门 · 约 45 分钟编辑精选
    2. Peter Naur:编程作为理论构建 (1985)

      Peter Naur – Programming as Theory Building (1985)

      Peter Naur 1985 年的经典论文《Programming as Theory Building》提出:编程的本质不是写代码或文档,而是在程序员头脑中构建对程序及其运行…

      编程语言与软件工程2016 · 629 分 · 74 评入门 · 约 45 分钟编辑精选
    3. SciPy 1.0:Python 科学计算的基础算法

      SciPy 1.0: fundamental algorithms for scientific computing in Python

      这篇发表于 Nature Methods 的论文介绍了 SciPy 1.0——Python 科学计算生态的基石库,涵盖其核心算法模块(优化、积分、插值、线性代数等)、软件架构与社…

      编程语言与软件工程2020 · 387 分 · 98 评入门 · 约 45 分钟编辑精选
    4. Lisp 的历史(1979)

      History of Lisp (1979)

      这是 Lisp 发明者 John McCarthy 于 1979 年为 HOPL(编程语言史)会议撰写的回顾文章,讲述 Lisp 的起源、设计动机与早期演进,文中也涉及 if 表…

      编程语言与软件工程2018 · 352 分 · 44 评入门 · 约 45 分钟编辑精选
    5. 使用 NumPy 进行数组编程

      Array Programming with NumPy

      这篇 Nature 文章介绍 NumPy 的数组编程模型及其在科学计算中的核心作用:以 ndarray 为中心,通过向量化操作让 Python 高效处理多维数组。

      编程语言与软件工程2020 · 318 分 · 134 评入门 · 约 40 分钟编辑精选

    打赏支持

    打赏二维码

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

    WeChat

    关注向阳乔木

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

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

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