WebAssembly 如何演进成为“浏览器第二编程语言”？( 三 ) _WebAssembly

文章插图

到 2011 年， Emscripten 已经具备编译像 Python 以及 DOOM 等中大型项目的能力，与此同时 Emscripten 也在 JSConfEU 会议上首次亮相，并取得了一定的影响力。Mozilla 看到了 Emscripten 项目的巨大潜力（相较于 NaCl 而言对 Web 更加友好）， Brendan 及 Andreas 邀请 Alon 加入 Mozilla 的 Research 团队全职负责 Emscripten 项目的开发， Alon Zakai 欣然接受并将工作的重心放在了如何提升 Emscripten 编译的 JavaScript 代码执行速度上。
在JavaScript 的弊端章节中我们可以看到，尽管 JavaScript 拥有 JIT（Just-In-Time），但由于 JavaScript 本身的语言特性，导致 JIT（Just-In-Time）难以被预测，在实际的生产环境当中 JIT（Just-In-Time）的效果往往并没有那么显著。
为了使得 JavaScript 运行得更快，我们应该要更充分地利用 JIT（Just-In-Time），因此在 2013 年， Alon Zakai 联合 Luke Wagner、David Herman 发布了 asm.js 。
asm.js 的思想很简单，就是尽可能明确对应的类型，以便 JIT（Just-In-Time）被充分利用。如下图示例所示：

文章插图

我们可以看到，对于add函数而言，由于传入参数x、y以及返回值进行了|0的操作，其能够很明确地为 JIT（Just-In-Time）指明对应的类型（i32），因此可以被 JIT（Just-In-Time）充分优化（不考虑后期 AOT 的情况）。
通过添加类似的类型注解， Emscripten 编译的 asm.js 在运行速度上相比普通 JavaScript 有了质的飞跃。在 Benchmark 中， asm.js 能达到 Native 性能的 50% 左右，相比于普通的 JavaScript 代码而言取得了极大的性能提升，这无疑是让人兴奋的成果。但是 asm.js 自身也存在一些无法忽视的问题，其总体而言并不是一个非常理想的技术方案。

文章插图

最显而易见的就是 asm.js 代码的“慢启动”问题。由于 asm.js 还是和 JavaScript 一样的文本格式，因此对于大中型项目而言，其解析花费的时间会非常长，无法与高效的二进制格式相提并论。
其次， asm.js 实质上是一种较为 hack 的实现方式，类似|0的类型标注不具有可读性，同时拓展 asm.js 也变得越来越复杂且不可靠：随着 asm.js 想要更加接近于 Native 的执行性能，不免会对诸多 Math 函数（例如 Math.imul 及 Math.fround 等）进行拓展和改写。从长远来看，这对 TC39 标准的制定并不友好，同时 asm.js 自身的相关实现（例如 memory growth 等）也遭遇了非常多的问题，导致 asm.js 标准被迫不断修订。“The hacks had a cost” ，我们需要一个全新的技术来解决 asm.js 所遇到的这些问题。
合作共赢 - WebAssembly在 2013 年， NaCl/PNaCl 与 asm.js/Emscripten 形成了不同路线发展的竞争态势，但与此同时， Google 及 Mozilla 也在工具及虚拟机层面加强了许多合作，其中包括：

由 Google 的 JF Bastien 牵头，每月 Google 和 Mozilla 工具团队之间开展交流会；
Emscripten 和 PNaCl 开始共享部分代码，包括 Legalization Passes、le32 triple 等；
尝试将 NaCl 应用通过 Emscripten 编译，并开源 Pepper.js；
Google 及 Mozilla 共同向 asm.js 贡献代码，并规划未来 Native Code 在 Web 上的合理方案；
就 WebAssembly 前身“WebAsm”进行标准和方案的讨论；

最终在 2015 年的 4 月 1 号， “WebAssembly”击败了“WebAsm”、“Webmachine”和其它名称，在 Google 和 Mozilla 的团队交流邮件中被确定使用。至 2015 年 6 月 17 号，两方就 WebAssembly 的标准化工作达成一致，并搭建了 WebAssembly 官网开始对外宣传。WebAssembly 的设计汲取了 NaCl 与 asm.js 两者的优点：