编程语言与软件工程2019usenix.org编辑精选
别急：分析 WebAssembly 与原生代码的性能
Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code
进阶 · 约 50 分钟读完前置知识：WebAssembly 基础、编译器优化、性能基准测试
导读
论文对 WebAssembly 与原生代码做系统性性能对比，发现在浏览器外（如 Node/V8 环境下）运行 SPEC 等基准时，WASM 平均比原生慢约 1.5 倍（约 45%–55%），部分场景差距更大。作者将差距归因于编译器后端优化不足、边界检查开销以及寄存器分配效率较低等问题，并指出 WASM 的额外开销主要来自工具链而非 ISA 本身。
HN 关注点：HN 读者围绕“WASM 是否真的够快、是否值得为跨平台分发牺牲原生性能”展开争论，既有实测数据也有对浏览器厂商主导生态的警惕。
后来怎么样
该论文成为 WebAssembly 性能评测的常用基线，推动后续运行时和编译器针对边界检查、寄存器分配等开销做优化；其“浏览器外约慢 1.5 倍”的结论也被后续工作持续复核并部分修正。
HN 评论精选
这几条评论里：质疑 2 补充 1 亲历 1
补充WASM 的真正价值在于零安装、沙箱化的跨平台分发，性能不是重点。
很多评论没抓住重点。作为开发者，我可以用 wasm 打出一个在 Windows、Mac、Linux、Android、iOS 上都能跑的单一二进制，还能用我想用的语言，不需要装 Xcode、Visual Studio、Android Studio 之类的工具链——有文本编辑器和 LLVM 就够了。用户只需在地址栏输入网址就能用，不需要安装、不污染 home 目录、不写注册表，而且运行在沙箱里，不会拿到你没打算给的权限。用 service worker 还能离线使用。我奶奶都能毫无困惑地用，我爸用这些应用也不必担心染上恶意软件或捆绑软件。那些“Web 没有原生感”“不够安全”“在我平台上打包原生应用一样简单”的抱怨都是老生常谈。我们终于有了一个完整的跨平台分发应用的方式，它能够尊重隐私，并保证合理的安全性——而且速度相当快。
bastawhiz查看英文原文
So many comments here missing the point. As a developer, I can use wasm to ship a single binary that works on Windows, Mac, Linux, Android, and iOS. I can use the language that I want. I don't need to have Xcode, visual studio, android studio, or any other set of tools: you can reasonably build an app with your text editor and LLVM. And then, you can use my app by typing its address into your address bar. No installation needed. No polluting your home directory. No registry entries. It's sandboxed, you're never giving the app permissions that you don't intend. A service worker can be used to make the app available offline. My dear grandmother could use this without confusion. My dad can use these apps and feel confident he's not not infesting himself with malware or bundled software. The complaints about "the web doesn't feel native!" and "it's less secure!" and "it's just as easy to ship a native app [for my platform of choice]!" are tired arguments. We've finally got a simple way to distribute apps fully cross platform in a way that CAN respect privacy and guarantees a reasonable level of security. And, it's pretty darn fast.
亲历亲测模拟器负载下 WASM 慢约 10%–3 倍，但性能可预测性比绝对值更重要。
补充一下：在我的 8 位模拟器里，用 clang -O3 编译的代码，两者的性能差距接近 10%（原生版用最新 Xcode 的 clang，WASM 版用 emscripten 的最新 LLVM WASM 后端）。右上角显示的是每帧模拟耗时，我笔记本上 WASM 版大约 2.5–2.8ms，原生版大约 2.0–2.2ms。根据我的经验，WASM 这边很容易不小心踩到“慢路径”，比如寄存器更早就溢出（据我所知是因为 WASM 预留了一两个寄存器）。不过情况在变好：大约一年前，同样的模拟器代码似乎触发了某个特定的慢路径，WASM 版慢了将近 4 倍。当然，针对特定编译器版本、编译器 intrinsics 和特定 CPU 型号，原生版总能投入更多优化，这正是 WASM 永远落后的地方——可移植 ISA 总会撞到无法继续优化的天花板。所以我的经验是：慢 10% 到慢 3 倍都在“预期”范围内，更重要的是对给定代码和编译器版本，性能是可预测的（比如不会突然有 GC 跑上几百毫秒）。
flohofwoe查看英文原文
FWIW: in my 8-bit emulators I'm closer to the 10% performance difference for code compiled in clang with -O3 (the native version uses latest Xcode's clang, the WASM the latest LLVM WASM backend via emscripten): https://floooh.github.io/tiny8bit/cpc-ui.html The time in the top-right is the time spent per frame in the emulator, in the WASM version that's somewhere around 2.5 to 2.8ms on my laptop. The native version is somewhere between 2.0 and 2.2ms. From my experiments, it's quite easy to accidentally hit a "slow path" on the WASM side, for instance registers are spilling earlier (AFAIK because WASM has one or two registers set aside). Things are getting better though. About a year ago, the same emulator code seemed to have triggered some specific slow-path and the WASM version was nearly 4x slower. Of course it's always possible to put more time into optimizing the native version of a piece of code when targeting a specific compiler version, compiler-specific intrinsics and a specific CPU model. This is where WASM will always lag behind, with a portable ISA you'll always hit a wall where further optimization simply isn't possible. So from my experience: somewhere between 10% slower and 3x slower is all within the "expected" range, the more important part is that performance is predictable for a given piece of code compiled with a given compiler version (e.g. you won't have the GC come in and do its thing for a few hundred milliseconds). And at least the emscripten team is very responsive and interested in such pathological cases.
质疑担心 WASM 让浏览器厂商成为新的碎片化平台垄断者。
好吧，将来某个时候浏览器/WASM 会赢。于是取代 Linux/Windows/OSX 的将是 Firefox/Safari/Chrome/某某，各自带着自己的实现坑、缺失特性和性能损失。这一切只是为了让浏览器厂商取代现有的原生部署平台——他们当然有很诱人的经济动机。我们开发者为什么要掉进这个陷阱？跨平台标准我们已经经历过好几次了，不管怎样厂商都会用各自专有的东西把它搞坏。
FpUser查看英文原文
Ok. At some point in the future the browser/wasm will have won. So instead of Linux/Windows/OSX we will have Firefox/Safari/Chrome/Whatever all with their own implementation gotchas, missing features and performance loss. All for the sake of browser vendors trying to displace the existing native deployment platforms. They sure have nice financial incentive. Why do we - developers fall into this trap? We've been there quite a few times already, with cross platform standards. No matter what vendors will fsck'em up with proprietary things.
质疑对非 Web 场景而言 WASM 只是多一层抽象，收益有限。
平均慢 50% 对很多应用来说可以接受。但对我个人而言，我不禁要问：意义何在？我会从 Linux -> glibc -> 原生应用，变成 Linux -> glibc -> 浏览器 -> WebAssembly 应用，又多了一层抽象。当然，WASM 可以在任何平台上直接运行，但预编译应用本来也不是问题（我的 Linux 发行版就提供二进制包）。所以这似乎主要对 Web 应用有意义。而我恰恰尽量避免 Web 应用，因为它们通常是专有的、随时会变、所有者可以随意开始收费或滥用我的数据，而且用起来没有原生感。（我确实认可它对 Web 应用用户的价值：WASM 通常比 JavaScript 快，并让更多语言能写 Web 应用。）
danieldk查看英文原文
Slower at an average of 50% looks acceptable to me for many applications. However, for me personally I wonder: what's the point? I would go from Linux -> glibc -> native application to Linux -> glibc -> Web Browser -> WebAssembly application. Yet another layer of abstraction. Sure, WebAssembly can be run directly on any platform. But precompiling an application is not a problem (my Linux distribution provides binary builds). So, this seems to be interesting to (primarily) web applications. However, I try to avoid web apps, because they are typically proprietary, a moving target, the owner can randomly decide to charge me for things, or (ab)use my data, and they feel non-native. (I do see the benefit for people who use web apps, since WebAssembly is typically faster than Javascript and opens up web app programming to more languages.)
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2019Hacker News 讨论帖174 分 · 205 评
同领域还值得读
Google 的软件工程（2017）
Software Engineering at Google (2017)
介绍了 Google 的软件工程实践，包括其单一代码库（monorepo）、几乎全部开发在主干进行而非分支、代码审查、构建系统 Blaze、协议缓冲区等工具与流程，并讨论了频繁重…
编程语言与软件工程2017 · 1,127 分 · 465 评 · 引用 15入门 · 约 45 分钟编辑精选Peter Naur：编程作为理论构建 (1985)
Peter Naur – Programming as Theory Building (1985)
Peter Naur 1985 年的经典论文《Programming as Theory Building》提出：编程的本质不是写代码或文档，而是在程序员头脑中构建对程序及其运行…
编程语言与软件工程2016 · 629 分 · 74 评入门 · 约 45 分钟编辑精选SciPy 1.0：Python 科学计算的基础算法
SciPy 1.0: fundamental algorithms for scientific computing in Python
这篇发表于 Nature Methods 的论文介绍了 SciPy 1.0——Python 科学计算生态的基石库，涵盖其核心算法模块（优化、积分、插值、线性代数等）、软件架构与社…
编程语言与软件工程2020 · 387 分 · 98 评入门 · 约 45 分钟编辑精选Lisp 的历史（1979）
History of Lisp (1979)
这是 Lisp 发明者 John McCarthy 于 1979 年为 HOPL（编程语言史）会议撰写的回顾文章，讲述 Lisp 的起源、设计动机与早期演进，文中也涉及 if 表…
编程语言与软件工程2018 · 352 分 · 44 评入门 · 约 45 分钟编辑精选使用 NumPy 进行数组编程
Array Programming with NumPy
这篇 Nature 文章介绍 NumPy 的数组编程模型及其在科学计算中的核心作用：以 ndarray 为中心，通过向量化操作让 Python 高效处理多维数组。
编程语言与软件工程2020 · 318 分 · 134 评入门 · 约 40 分钟编辑精选