WebAssembly 为何比 asm.js 快？

做者：Alon Zakai

编译：胡子大哈

翻译原文：huziketang.com/blog/posts/…

英文原文：Why WebAssembly is Faster Than asm.js

转载请注明出处，保留原文连接以及做者信息

---

本文做者：Alon Zakai

英文链接：Why WebAssembly is Faster Than asm.js

WebAssembly 是为 Web 而设计的、能够生成浏览器可执行的二进制文件的编程语言。而且于2017 年 2 月 28 日，四个主要的浏览器一致赞成宣布 WebAssembly 的 MVP 版本已经完成，即将推出一个浏览器能够搭载的稳定版本。WebAssembly 的一个主要目标就是变快。本文将给出一些它如何变快的技术细节。

固然，“快”是相对的概念。相比于 JavaScript 和其余动态语言，WebAssembly 的快主要是由于它的静态类型特性和方便优化特性。WebAssembly 意在速度上可以达到和本地执行同样快，其实 asm.js 已经比较接近这一目标了，可是 WebAssembly 要进一步缩短和本地执行速度之间的差距。所以本文着重介绍为何 WebAssembly 比 asm.js 更快。

在开始介绍以前，先作一些说明：新的技术老是有一些还没来得及优化的状况，因此目前来讲，并非全部状况下 WebAssembly 都是最快的。本文主要表达的是 WebAssembly 为何应该是更快的。对于它还不是那么快的一些状况，也是将来须要 fix 的问题。

那么有了这些标准之后，咱们来介绍为何 WebAssembly 更快。

1. 启动

WebAssembly 设计之初就定位在：体积更小、下载更快、解析更快，这样即便应用于一个大型的 web 应用上启动也会很快。

JavaScript 代码经过 gzip 进行压缩，与本地代码相比它已经压缩了不少，想要进一步缩小它的体积确实不是一件容易的事情。可是经过对 WebAssembly 文件大小的精心设计（LEB128 指标），二进制格式的 WebAssembly 的文件大小要比压缩后的 JavaScript 文件更小。一般来说，要比 gzip 压缩后的小 10% - 20%。

WebAssembly 在解析过程有更大的进步：它的解析速度要比 JavaScript 快一个数量级。这得益于 WebAssembly 的二进制格式就是为更适合解析而设计的。同时 WebAssembly 的解析和优化函数也更容易实现并行，这一特色在多核机器上的体现更好。

影响启动时间的因素除了下载和解析之外还有不少，好比代码的 VM 彻底优化、执行以前下载所必须的额外文件等。可是下载和解析步骤是不管如何都不可避免的步骤，所以要尽量地对它们进行优化。不管是对于浏览器仍是 app，其余的影响因素都有办法避免或者缓和它们的影响（例如代码的彻底优化，能够经过 WebAssembly 的基线编译器或解释器来避免）。

2. CPU 特性

使得 asm.js 这么快的技巧之一是利用好 CPU 特性。JavaScript 数字类型都是 double 型的，在 asm.js 中加法操做后会有一个按位与的操做，这使得 double 加法这个操做，在逻辑上和 CPU 作简单的 int 加法（CPU 作简单 int 加操做很快）是等价的。而 asm.js 巧妙地经过这种方式使得 VM 能够更加有效地利用 CPU。

可是有一些 JavaScript 中表达的东西，asm.js 是表达不了的。
WebAssembly 则不受 JavaScript 的约束，咱们一块儿来看一下更多的可利用的 CPU 特性：

• 64 位整型。基于 64 位整型的操做速度能够快 4 倍。例如能够增长哈希算法和加密算法的速度。
• 加载和存储偏移量。它的用处特别普遍，基本上全部包含域的内存对象都涉及到偏移量的问题（如 C 语言中 struct 等）。
• 非对齐加载和存储。这避免了 asm.js 所须要的 mask（asm.js 为 Typed Array 兼容而作的操做），同时这在几乎全部的加载和存储问题都用得上。
• 多种 CPU 指令，例如 popcount，copysign 等。每个指令都有助于某种具体使用场景（例如，popcount 在密码分析这个场景下颇有用）。

在每一种具体场景下到底能起到多大做用，要依赖于如何使用上面提到的特性。和正常使用 asm.js 相比，咱们的统计是大概比 asm.js 提高了 5% 的速率。将来还有更多可挖掘的 CPU 特性来提升速率，例如 SIMD。

3. 工具链改进

WebAssembly 是编译器生成的主要目标，因此它的运行主要包含两个部分：生成它的编译器（工具链端）和运行它的虚拟机（浏览器端）。优良的性能全都依赖于这两部分。

对于 asm.js，状况也相似，而且 Emscripten 作了一系列对工具链的优化，还作了运行 LLVM 的优化器和 Emscripten 的 asm.js 优化器。对 WebAssembly 的优化都是在这些的基础上来设计的，而且同时还加入了一些专门针对 WebAssembly 的改进。咱们本身在学习 asm.js 的过程对咱们改善 WebAssembly 颇有帮助，尤为体如今一下几个方面：

• 咱们使用 Binaryen WebAssembly 优化器来代替 Emscripten asm.js 优化器，前者是专门为速度而设计，其速度的提高是以更多优化步骤为代价的。例如在优化的过程当中会移除重复函数，这样会使 C++ 编译代码总体减少 5% 左右。
• 对冗余、复杂的控制流进行更好的优化，这能够提高 Relooper 算法的效率，对于编译解释类型循环也颇有帮助。
• Binaryen 优化器是在试验中不断设计和完善的，经过超级优化器作的实验也会带来各类状况的微妙改进——我想 asm.js 也作过一样的事情。

总的来讲，这些工具链的改进，在 asm.js 的基础上进一步提高了 WebAssembly 的速度（Box2D 速度评测中，WebAssembly 的速度分别提高了 5% 和 7%）。

可预见的优良性能

asm.js 的速度很接近本地执行的速度了，可是它不可能在全部的浏览器中都达到一样的标准。由于在使用 asm.js 的过程当中，一些人尝试用一种方法来优化 asm.js，而另外一些人用另外一种方法优化，这致使了不一样人有不一样的版本和结果。虽然随着时间的推移，你们对于 asm.js 也达成了某种共识，可是对于 asm.js 来说，本质问题是它仍是没有一个统一的标准。它只是一个由一个厂商推出的，非标准的 JavaScript 子集而已，而它的使用者根据本身的偏好和习惯来使用它。

WebAssembly 则不一样，它是由几大主要的浏览器厂商共同设计的。与 JavaScript相比，JavaScript 只能经过一些创新方法或者 asm.js 这种方法来提升速度，而不论哪一种方法都不可能适用于全部浏览器。WebAssembly 的优化方案则获得了大多数厂商的承认。对于 WebAssembly 来说，对于不一样的 VM 依旧有很大的提高空间（如 AOT、JIT 有不一样编译方式）。不过可以基本判定的是，能够应用于整个网络的优良性能是指日可期的。

想了解更多关于 WebAssembly 的知识，请移步下面 WebAssembly 系列文章。

背景知识：

• WebAssembly 系列（一）生动形象地介绍 WebAssembly
• WebAssembly 系列（二）JavaScript Just-in-time (JIT) 工做原理
• WebAssembly 系列（三）编译器如何生成汇编

当前 WebAssembly 的情况

• WebAssembly 系列（四）WebAssembly 工做原理
• WebAssembly 系列（五）为何 WebAssembly 更快？

WebAssembly 的将来

• WebAssembly 系列（六）WebAssembly 的如今与将来

转载请注明出处，保留原文连接以及做者信息

欢迎你们关注个人前端大哈 - 知乎专栏，按期发布高质量前端文章。

---

我最近正在写一本《React.js 小书》，对 React.js 感兴趣的童鞋，欢迎指点。