WebAssembly 系列 - 现在与未来

Mon, Apr 19, 21

这是系列的第六篇,如果你还没有阅读其它篇章,我们建议你从头开始哦。

今年(2017 年)二月28日,4 大浏览器一致表示他们已经完成了针对 WebAssembly 的 MVP 版本 的发布。这意味着浏览器已经基本可以承载 WebAssembly 的基本功能。

当代浏览器携手共进
图:当代浏览器携手共进

这提供了一个浏览器可承载的稳定内核。这个内核并非包含了社区计划的全部的特性,但那也是够快、够用了。

由此,开发者们可以开始发布他们的 WebAssembly 代码了。对于早期版本的浏览器,开发者们可以发送 asm.js 版本的代码。因为 asm.js 是 javascript 的子集,任何 js 引擎都可运行它。使用 Emscripten,你可以将一个 app 同时编译成 WebAssembly 和 asm.js。

虽然这是首次发布,WebAssembly 也会相当的快。然而,通过后期的修正、加入新特性,在将来,它会更快。

浏览器端提升 WebAssembly 性能

有些速度上的提升,会由浏览器引擎对于 WebAssembly 更好的支持做出。各个浏览器厂商对于这些问题的处理都是独立进行的。

程序间(JS 和 WebAssembly)函数调用更快

目前,在 JS 代码里调用一个 WebAssembly 函数比它理所应当的要慢。因为,这里面需要做一些额外的事情,它被称为 trampolining(蹦床)。JIT 不知道如何直接操作 WebAssembly,因此,我们需要将 WebAssembly 路由过去。相关的引擎(就是用于启动和运行优化后的 WebAssembly 代码的那个)在执行这个动作的时候非常缓慢。

Person jumping from JS on to a trampoline setup function to get to WebAssembly
图:Person jumping from JS on to a trampoline setup function to get to WebAssembly

如果 JIT 知道如何直接处理 WebAssembly,我们的速度将提高 100 倍。

如果将仅仅一个重任务派发给 WebAssembly 模块,你不会注意到这个 overhead 。但是,如果你有很多 JS 和 WebAssembly 之间的通讯任务(小的任务)要做,这个 overhead 就很明显了。

加载更快

JIT 必须平衡更快加载和更快执行二者。如果你在一开始花费更多的时间来编译和优化,那么执行速度得到了提升,然而启动变慢了。

基于代码运行时的实际情况考虑,和先期编译的时间代价,关于如何平衡二者,还是有很多的工作要做的。先期编译可以确保代码一旦运行,便没有任何的明显的性能问题;而运行时的实际情况是指,很多的代码不会运行很长时间,于是优化也就显得不划算。

由于 WebAssembly 不需要具体化要使用的类型,引擎也就不必操心去检测运行时类型。这给了引擎更多的选择,比如编译和执行可以并行。

另外,新加的 JS API 允许 WebAssembly 的流式编译。这意味着引擎可以在字节下载期间启动编译。

在 Firefox 浏览器,我们基于双编译器系统工作。一个编译器善于代码基本优化(compiler optimization),会在先期( AOT )运行。与此同时,另一个编译器则会在后台执行全面优化,全面优化后的代码在就绪后会顶替基本优化版本。

向规范追加后 MVP 特性

WebAssembly 的目标之一,制定规范是小步伐并且是测试同行的,而非一开始就设计出全部。

这就是说,还有很多特性值得期待,只是目前尚未 100% 构思明白。这些值得期待的特性将会被严格的写入规范,所有的浏览器厂家都会参与进来。

这些特性我们称为准特性,这里列举几个吧。

直接操作 DOM

目前,WebAssembly 无法直接与 DOM 交互。这就是说,使用 WebAssembly 你还不能做类似如下操作:

element.innerHTML = `...`

相反,你必须通过 Js 来处理。这就是说你需要将值传回到 JavaScript 的调用者。另外一方面,这也意味着,在 WebAssembly 调用 JS 函数(无论 JS 函数或 WebAssembly 函数),可以借助 WebAssembly 模块中的 imports 指令。

在 WebAssembly 程序中,人们必须通过 Js 来访问 DOM
图:在 WebAssembly 程序中,人们必须通过 Js 来访问 DOM

不管哪种方式,看起来,经由 JavaScript 比直接操作显得要慢。有些 WebAssembly 应用可能会在 DOM 处理期间挂起。

共享内存协同

提高代码运行速度的方法之一就是将代码分为几个部分,然后并行执行它们。这可能会适得其反,因为,线程之间的通讯的 overhead 比执行任务的耗时都要多。

但是,如果你能够在线程间共享内存,便可以减少 overhead。为了达到目的,WebAssembly 使用 Js 的 SharedArrayBuffer。一旦浏览器支持,工作组就可以开始为此制定规范,来设计 WebAssembly 与 SharedArrayBuffer 的交互法则。

SIMD

如果你阅读过其它关于 WebAssembly 的文章,你可能听说过 SIMD。它是 single instruction, multiple data 的简写。这是另一种并行机制。

有了 SIMD,你就可以向大数据块(比如:一个包含了不同数值的向量)的不同部分发送相同指令,以同时处理一个数据块。由此,它可以显著提升游戏或者 VR 应用的计算速度。

这对普通应用不太重要,但如果是需要操作 multimiedia,比如游戏开发,这就是非常重要的。

异常处理

许多基于 C++ 语言的项目都会用到异常处理,然而,它目前还没有写进 WebAssembly 的规范中。

如果你使用 Emscripten 来编译你的代码,可能需要在编译优化级别上去模拟异常处理。这很慢,因此你很可能会使用 DISABLE_EXCEPTION_CATCHING 关闭此功能。

一旦 WebAssembly 内置了异常处理,这个模拟的工作就是不必要的。

其它改进 —— 面向开发者更加友善

此准特性无关性能,而是为了改善开发体验。

  • First-class 源码级开发工具 目前,在浏览器上调试 WebAssembly 就像是调试原始的 assembly。很少有开发者不借助工具就能够将 source code 映射到 assembly。我们正在考虑如何改进我们的工具,以使得开发者能够调试代码。
  • 垃圾回收 如果你能在编译时确定类型,你应该可以把你的代码转为 WebAssembly。因此使用类似 TypeScript 等强类型语言编写的代码与 WebAssembly 是兼容的。目前唯一的问题是,WebAssembly 不知道如何与既存的垃圾收集器交互,比如 Js 引擎内置的那个 GC。这个准特性的想法就是打算允许 WebAssembly 通过一系列低级别的 GC 基础类型和操作,优先访问 JS 引擎内置 GC。
  • ES6 模块集成 浏览器目前支持使用 script 标签来加载模块化的脚本文本。一旦这个准特性加入规范,你便可以使用同样的方式加载 WebAssembly 模块。

最后

WebAssembly 很快,随着一些新的特性的加入和方方面面的改进,它一定会更快!

https://hacks.mozilla.org/2017/02/where-is...