编程语言与软件工程2019arxiv.org
WebAssembly 与原生代码的性能分析
Analyzing the Performance of WebAssembly vs. Native Code
进阶 · 约 45 分钟读完前置知识：WebAssembly 基础、JIT 编译原理、基准测试方法
导读
这篇论文系统对比了 WebAssembly 与原生代码的运行性能，测试了多种基准程序在两种环境下的执行速度差异。结论显示 WASM 性能已接近原生代码，明显快于 JavaScript，但在某些场景（如寄存器分配、向量化）仍存在优化空间。
HN 关注点：WebAssembly 是否真能达到原生性能，这关系到它能否取代 JavaScript 成为跨平台开发的主流选择。
HN 评论精选
这几条评论里：支持 1 质疑 1 补充 2
补充若 WASM 接近原生性能，将取代 Electron 成为桌面跨平台主流，但移动端受制于 Apple
我从没指望 WebAssembly 能达到原生速度，只希望它显著快于 JavaScript。考虑到 Electron 的流行程度，如果 WASM 真能达到原生性能或至少 80%（这是很大的假设），它将轻松成为绝大多数桌面应用的跨平台语言。至于移动端，我们永远会被 Apple 拖累——它拒绝拥抱 Web 技术，都 2019 年了连'添加到主屏幕'的原生横幅都不支持。
pier25查看英文原文
I never expected WebAssembly to be as fast as native only to be significantly faster than JavaScript. Considering the popularity of Electron, if WebAssembly does get as fast as native or at least 80% there (and that's a really big if) it would easily become the cross platform language for the vast majority of desktop applications. For mobile we will always be dragged down by Apple and its reticence to embrace web technologies. It's 2019 and we can't even show a add to home screen native banner.
质疑质疑实验方法：原生侧禁用向量化，对比不公平
他们在原生代码上禁用了向量化，所以很难说这是一个真正公平的对等比较。
hackcasual查看英文原文
They disable vectorization on native, so hard to call this a true apples-to-apples comparison
支持WASM 将成为 Web 应用默认方案，让开发者摆脱 JavaScript
未来几年 WASM 将成为所有非平凡 Web 应用的默认选择（前提是 DOM 访问问题得到解决）。为什么要发布 JavaScript 到互联网上再在本地编译？我知道 JIT 有其优势，但对 JavaScript 来说不成立。而且开发者讨厌 JavaScript——TypeScript 的存在不就是为了用理性的方式掩盖 JS 的糟糕本质吗？现在你不需要 JS 了，可以选择最合适的语言。
mgamache查看英文原文
WASM will be the default for any non-trivial web apps in the next few years (assuming the DOM access gets addressed). Why would you ship JavaScript of the internet to then get compiled locally? I know there's arguments for JIT, but I don't think they make sense for JavaScript. Also devs hate JavaScript! Okay, I know we don't all hate it and I know it's popular, but really why does TypeScript exist? It's just a rational way to produce JS that hides the silly nature of JS. Now you don't need JS (or TypeScript) choose the language that works best.
补充基准测试应纳入编译速度，否则无法公平评估优化空间
编译速度应该纳入基准测试，因为它对 WebAssembly 至关重要。最好使用与 WASM 编译速度最接近的 Clang 优化级别来对比运行速度。比如文章提到寄存器分配欠佳，但没有编译时间对比，就无法知道是否真有简单方法改进 WASM 实现。
xiphias2查看英文原文
Compilation speed should be part of the benchmarks, as it's critical for WebASM. The best would be to use the Clang optimization setting with the most similar compilation speed to compare runtime speeds. As an example the article mentions suboptimal register allocation, but without compile time comparision there's no way to know if there really is a simple way to improve WebGL implementation.
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2019Hacker News 讨论帖250 分 · 172 评
- 2025Hacker News 讨论帖21 分 · 5 评
- 2025Hacker News 讨论帖74 分 · 57 评
同领域还值得读
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 分钟编辑精选