为什么浏览器里的WebAssembly能达到本地应用的速度？

WebAssembly| 2017-03-20

本文作者：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 的基线编译器或解释器来避免）。

图1：为什么浏览器里的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。

图2：为什么浏览器里的WebAssembly能达到本地应用的速度？

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%）。

图3：为什么浏览器里的WebAssembly能达到本地应用的速度？

可预见的优良性能

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

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

本文文字及图片出自 huzidaha.com