WebAssembly 那些事儿

时间 2019-11-09

标签 webassembly 那些事儿繁體版

原文原文链接

WebAssembly 那些事儿

什么是 WebAssembly？

WebAssembly 是除 JavaScript 之外，另外一种能够在网页中运行的编程语言，而且相比之下在某些功能和性能问题上更具优点，过去咱们想在浏览器中运行代码来对网页中各类元素进行控制，只有 JavaScript 这一种选择，而现在咱们能够将其它语言（C/C++ etc.）编译成 wasm 格式的代码在浏览器中运行。

WebAssembly 的目标是对高级程序中间表示的适当低级抽象，即 wasm 代码旨在由编译器生成而不是由人来写。html

每一种目标汇编语言（x8六、ARM etc.）都依赖于特定的机器结构，当咱们想要把代码放到用户的机器上执行的时候，并不知道目标机器结构是什么样的，而 WebAssembly 与其余的汇编语言不同，它不依赖于具体的物理机器，能够抽象地理解成它是 概念机器的机器语言，而不是实际的物理机器的机器语言，正由于如此 WebAssembly 指令有时也被称为虚拟指令，它比 JavaScript 代码更直接地映射到机器码，同时它也表明了“如何能在通用的硬件上更有效地执行代码”的一种理念。git

目前对于 WebAssembly 支持状况最好的编译器工具链是 LLVM，还有一个易用的工具叫作 Emscripten，它经过本身的后端先把代码转换成本身的中间代码（asm.js），而后再转化成 WebAssembly，实际上它是基于 LLVM 的一系列编译工具的集合。github

Tip：不少 WebAssembly 开发者用 C 语言或者 Rust 开发，再编译成 WebAssembly，其实还有其余的方式来开发 WebAssembly 模块：使用 TypeScript 开发 WebAssembly 模块，或者直接书写 WebAssembly 文本 etc.。

WebAssembly 代码存储在 .wasm 文件内，这类文件是要浏览器直接执行的，由于 .wasm 文件内是二进制文件难以阅读，为方便开发者查看官方给出对 .wasm 文件的阅读方法：
把 .wasm 文件经过工具转为 .wast 的文本格式，开发者能够在必定程度上理解这个 .wast 文件（经过 S- 表达式写成，相似于 lisp 语言的代码书写风格）。编程

Tip：.wast 文件和 .wasm 文件之间的相互转化能够经过工具 wabt 实现。

为何 WebAssembly 更快？

一些关于性能的历史

- JavaScript 于 1995 年问世，它的设计初衷并非为了执行起来快，在前 10 个年头它的执行速度也确实不快。后端

- 紧接着，浏览器市场竞争开始激烈起来。数组

- 广为流传的“性能大战”在 2008 年打响，许多浏览器引入 JIT 编译器，JavaScript 代码的运行速度渐渐变快（10倍！），这使得 JavaScript 的性能达到一个转折点。浏览器

知识迁移：Javascript JIT 工做原理

在代码的世界中，一般有两种方式来翻译机器语言：解释器和编译器。服务器

若是是经过解释器，翻译是一行行地边解释边执行
编译器是把源代码整个编译成目标代码，执行时再也不须要编译器，直接在支持目标代码的平台上运行

解释器启动和执行的更快，咱们不须要等待整个编译过程完成就能够运行代码，从第一行开始翻译就能够依次继续执行。正是由于这个缘由，解释器看起来更加适合 JavaScript，对于一个 Web 开发人员来说，可以快速执行代码并看到结果是很是重要的。但是当咱们运行一样的代码一次以上的时候，解释器的弊处就显现出来：好比执行一个循环，那解释器就不得不一次又一次的进行翻译，这是一种效率低下的表现。网络

编译器的问题则刚好相反：它须要花一些时间对整个源代码进行编译，而后生成目标文件才能在机器上执行。对于有循环的代码执行的很快，由于它不须要重复的去翻译每一次循环。数据结构

另一个不一样是，编译器能够用更多的时间对代码进行优化，以使的代码执行的更快；而解释器是在 runtime 时进行这一步骤的，这就决定它不可能在翻译的时候用不少时间进行优化。

Just-in-time 编译器：综合二者的优势

为了解决解释器的低效问题，后来的浏览器把编译器也引入进来，造成混合模式。不一样的浏览器实现这一功能的方式不一样，不过其基本思想是一致的：在 JavaScript 引擎中增长一个监视器（也叫分析器），监视器监控着代码的运行状况，记录代码一共运行多少次、如何运行等信息。

起初，监视器监视着全部经过解释器的代码，若是同一行代码运行屡次，这个代码段就被标记成 “warm”，若是运行不少次则被标记成 “hot”。

基线编译器

若是一段代码变成 “warm”，那么 JIT 就把它送到编译器去编译，而且把编译结果存储起来。

代码段的每一行都会被编译成一个“桩”（stub），同时给这个桩分配一个以“行号 + 变量类型”的索引，若是监视器监视到执行一样的代码和一样的变量类型，那么就直接把这个已编译的版本 push 出来给浏览器。经过这样的作法能够加快执行速度，可是正如前我所说的，编译器还能够找到更有效地执行代码的方法（优化）。

基线编译器能够作一部分这样的优化，不过基线编译器优化的时间不能过久，由于会使得程序的执行在这里 hold 住，不过若是代码确实很是 “hot”（也就是说几乎全部的执行时间都耗费在这里），那么花点时间作优化也是值得的。

优化编译器

若是一个代码段变得 “very hot”，监视器会把它发送到优化编译器中，生成一个更快速和高效的代码版本出来，而且存储之。为了生成一个更快速的代码版本，优化编译器必须作一些假设：例如它会假设由同一个构造函数生成的实例都有相同的形状，就是说全部的实例都有相同的属性名，而且都以一样的顺序初始化，那么就能够针对这一模式进行优化。

整个优化器起做用的链条是这样的，监视器从他所监视代码的执行状况作出本身的判断，接下来把它所整理的信息传递给优化器进行优化，若是某个循环中先前每次迭代的对象都有相同的形状，那么就能够认为它之后迭代的对象的形状都是相同的，但是对于 JavaScript 历来就没有保证这么一说，前 99 个对象保持着形状，可能第 100 个就减小某个属性。

正是因为这样的状况，编译代码须要在运行以前检查其假设是否是合理的，若是合理那么优化的编译代码会运行，若是不合理那么 JIT 会认为这是一个错误的假设，而且把优化代码丢掉，这时执行过程将会回到解释器或者基线编译器，这一过程叫作去优化。

一般优化编译器会使得代码变得更快，可是一些状况也会引发一些意想不到的性能问题。若是代码一直陷入优化去优化的怪圈，那么程序执行将会变慢，还不如基线编译器快。大多数的浏览器限制当优化去优化循环发生的时候会尝试跳出这种循环，好比若是 JIT 反复作 10 次以上的优化而且又丢弃的操做，那么就不继续尝试去优化这段代码。

一个优化的例子：类型特化（Type specialization）

JavaScript 所使用的动态类型体系在运行时须要进行额外的解释工做，例以下面代码：

function arraySum(arr) {
  var sum = 0;
  for (var i = 0; i < arr.length; i++) {
    sum += arr[i];
  }
}

+= 循环中这一步看起来很简单，只须要进行一步计算，可是偏偏由于是用动态类型，所须要的步骤要比咱们所想象的更复杂一些：咱们假设 arr 是一个有 100 个整数的数组，当代码被标记为 “warm” 时，基线编译器就为函数中的每个操做生成一个桩，sum += arr[i]会有一个相应的桩，而且把里面的 += 操做当成整数加法，可是 sum 和 arr[i] 两个数并不保证都是整数，由于在 JavaScript 中类型都是动态类型，在接下来的循环当中 arr[i] 颇有可能变成了string 类型，整数加法和字符串链接是彻底不一样的两个操做，会被编译成不一样的机器码。

JIT 处理这个问题的方法是编译多基线桩：若是一个代码段是单一形态的（即老是以同一类型被调用），则只生成一个桩：若是是多形态的（即调用的过程当中，类型不断变化），则会为操做所调用的每个类型组合生成一个桩。这就是说 JIT 在选择一个桩以前会进行多分枝选择（相似于决策树），问本身不少问题才会肯定最终选择哪一个。

正是由于在基线编译器中每行代码都有本身的桩，因此 JIT 在每行代码被执行的时候都会检查数据类型，在循环的每次迭代 JIT 也都会重复一次分枝选择。

若是代码在执行的过程当中 JIT 不是每次都重复检查的话，那么执行的还会更快一些，而这就是优化编译器所须要作的工做之一。在优化编译器中，整个函数被统一编译，这样的话就能够在循环开始执行以前进行类型检查。

一些浏览器的 JIT 优化更加复杂：在 Firefox 中给一些数组设定特定的类型，好比数组里面只包含整型，若是 arr 是这种数组类型，那么 JIT 就不须要检查 arr[i] 是否是整型，这也意味着 JIT 能够在进入循环以前进行全部的类型检查。

- 随着性能的提高 JavaScript 能够应用到更多领域（Node.js etc.）

- 经过 WebAssembly 咱们颇有可能正处于第二个拐点！

当前的 JavaScript 性能如何？

下图片介绍 JS 引擎性能使用的大概分布状况，各个部分所花的时间取决于页面所用的 JavaScript 代码，其比例并不表明真实状况下的确切比例状况，而且这些任务并非离散执行或者按固定顺序依次执行的，而是交叉执行：好比某些代码在进行解析时，其余一些代码正在运行而另外一些正在编译。

Parsing：表示把源代码变成解释器能够运行的代码所花的时间；
Compiling + optimizing：表示基线编译器和优化编译器所花的时间（某些优化编译器的工做并不在主线程运行）
Re-optimizing：当 JIT 发现优化假设错误，丢弃优化代码所花的时间（包括重优化的时间、抛弃并返回到基线编译器的时间）
Execution：执行代码的时间
Garbage collection：垃圾回收、清理内存的时间

早期的 JavaScript 执行相似于下图，各个过程顺序进行：

各个浏览器处理下图中不一样的过程有着细微的差异，咱们使用 SpiderMonkey 做为模型来说解不一样的阶段：

文件获取

这一步并无显示在图表中，可是看似简单的从服务器获取文件得这个步骤，却会花费很长时间，WebAssembly 比 JavaScript 的压缩率更高，即在服务器和客户端之间传输文件更快，尤为在网络很差的状况下。

解析

当文件到达浏览器时 JavaScript 源代码就被解析成抽象语法树，浏览器采用懒加载的方式进行，只解析真正须要的部分，而对于浏览器暂时不须要的函数只保留它的桩。解析事后 AST（抽象语法树）就变成了中间代码（字节码：一种中间代码，经过虚拟机转换为机器语言）提供给 JS 引擎编译，而 WebAssembly 则不须要这种转换，由于它自己就是中间代码，要作的只是解码而且检查确认代码没有错误便可。

知识迁移：抽象语法树

抽象语法树（Abstract Syntax Tree）也称为 AST 语法树，指的是源代码语法所对应的树状结构。

程序代码自己能够被映射成为一棵语法树，而经过操纵语法树咱们可以精准的得到程序代码中的某个节点。Espsrima 提供一个在线解析的工具，咱们能够借助于这个工具将 JavaScript 代码解析为一个 JSON 文件表示的树状结构，举例以下所示：

// Life, Universe, and Everything
var answer = 6 * 7;

{
    "type": "Program",
    "body": [
        {
            "type": "VariableDeclaration",
            "declarations": [
                {
                    "type": "VariableDeclarator",
                    "id": {
                        "type": "Identifier",
                        "name": "answer"
                    },
                    "init": {
                        "type": "BinaryExpression",
                        "operator": "*",
                        "left": {
                            "type": "Literal",
                            "value": 6,
                            "raw": "6"
                        },
                        "right": {
                            "type": "Literal",
                            "value": 7,
                            "raw": "7"
                        }
                    }
                }
            ],
            "kind": "var"
        }
    ],
    "sourceType": "script"
}

抽象语法树的做用很是的多，好比编译器、IDE、压缩优化代码 etc.，在 JavaScript 中虽然咱们并不会经常与 AST 直接打交道，但却也会常常涉及到它的使用：例如使用 UglifyJS 来压缩代码时，这背后的原理就是在对 JavaScript 的抽象语法树进行操做。

编译和优化

JavaScript 是在代码的执行阶段编译的，由于它是弱类型语言，当变量类型发生变化时，一样的代码会被编译成不一样版本，不一样浏览器处理 WebAssembly 的编译过程也不一样，有些浏览器只对 WebAssembly 作基线编译，而另外一些浏览器用 JIT 来编译，不论哪一种方式，WebAssembly 都更贴近机器码因此它更快：

在编译优化代码以前不须要提早运行代码以知道变量都是什么类型
编译器不须要对一样的代码作不一样版本的编译
不少优化在 LLVM 阶段就已经完成

重优化

有些状况下 JIT 会反复地进行抛弃优化代重优化过程，当 JIT 在优化假设阶段作的假设在执行阶段发现是不正确的时候，就会发生这种状况：好比当循环中发现本次循环所使用的变量类型和上次循环的类型不同，或者原型链中插入了新的函数，都会使 JIT 抛弃已优化的代码。

须要花时间丢掉已优化的代码而且回到基线版本
若是函数依旧频繁被调用，JIT 可能会再次把它发送到优化编译器又作一次优化编译

而在 WebAssembly 中类型都是肯定的，因此 JIT 不须要根据变量的类型作优化假设，也就是说 WebAssembly 没有重优化阶段。

执行

开发人员本身也能够写出执行效率很高的 JavaScript 代码，这须要了解 JIT 的优化机制，例如要知道什么样的代码编译器会对其进行特殊处理，然而大多数的开发者是不知道 JIT 内部的实现机制的，即便知道 JIT 的内部机制也很难写出符合 JIT 标准的代码，由于人们一般为了代码可读性更好而使用的编码模式偏偏不合适编译器对代码的优化；加之 JIT 会针对不一样的浏览器作不一样的优化，因此对于一个浏览器优化的比较好，极可能在另一个浏览器上执行效率就比较差。

正是由于这样执行 WebAssembly 一般会比较快，不少 JIT 为 JavaScript 所作的优化在 WebAssembly 并不须要；另外 WebAssembly 就是为编译器而设计的，开发人员不直接对其进行编程，这样就使得 WebAssembly 专一于提供更加理想的指令（执行效率更高的指令）给机器便可。

垃圾回收

JavaScript 中开发者不须要手动清理内存中不用的变量，JS 引擎会自动地作这件事情即垃圾回收的过程。但是当咱们想要实现性能可控，垃圾回收可能就是一个大问题：垃圾回收器会自动开始，这是不受控制的，因此颇有可能它会在一个不合适的时机启动，目前的大多数浏览器已经能给垃圾回收安排一个合理的启动时间，不过这仍是会增长代码执行的开销。

目前为止 WebAssembly 不支持垃圾回收，内存操做都是手动控制的，这对于开发者来说确实会增长开发成本，不过也使得代码的执行效率更高。

WebAssembly 的如今与将来

JavaScript 和 WebAssembly 之间调用的中间函数

目前在 Javascript 中调用 WebAssembly 的速度比本应达到的速度要慢，这是由于中间须要作一次“蹦床运动”：JIT 没有办法直接处理 WebAssembly，因此 JIT 要先把 WebAssembly 函数发送到懂它的地方，这一过程是引擎中比较慢的地方。

按理来说，若是 JIT 知道如何直接处理 WebAssembly 函数，那么速度会有百倍的提高，若是咱们传递的是单一任务给 WebAssembly 模块，那么不用担忧这个开销，由于只有一次转换，也会比较快，可是若是是频繁地从 WebAssembly 和 JavaScript 之间切换，那么这个开销就必需要考虑了。

快速加载

JIT 必需要在快速加载和快速执行之间作权衡，若是在编译和优化阶段花了大量的时间，那么执行的必然会很快，可是启动会比较慢。目前有大量的工做正在研究，如何使预编译时间和程序真正执行时间二者平衡。WebAssembly 不须要对变量类型作优化假设，因此引擎也不关心在运行时的变量类型，这就给效率的提高提供了更多的可能性，好比可使编译和执行这两个过程并行。加之最新增长的 JavaScript API 容许 WebAssembly 的流编译，这就使得在字节流还在下载的时候就启动编译。

FireFox 目前正在开发两个编译器系统：一个编译器先启动，对代码进行部分优化，在代码已经开始运行时，第二个编译器会在后台对代码进行全优化，当全优化过程完毕，就会将代码替换成全优化版本继续执行。

添加后续特性到 WebAssembly 标准的过程

直接操做 DOM

目前 WebAssembly 没有任何方法能够与 DOM 直接交互，就是说咱们还不能经过好比 element.innerHTML 的方法来更新节点。想要操做 DOM 必需要经过 JS，那么就要在 WebAssembly 中调用 JavaScript 函数，无论怎么样都要经过 JS 来实现，这比直接访问 DOM 要慢得多，因此这是将来必定要解决的一个问题。

共享内存的并发性

提高代码执行速度的一个方法是使代码并行运行，不过有时也会拔苗助长，由于不一样的线程在同步的时候可能会花费更多的时间。这时若是可以使不一样的线程共享内存，那就能下降这种开销，实现这一功能 WebAssembly 将会使用 JavaScript 中的 SharedArrayBuffer，而这一功能的实现将会提升程序执行的效率。

SIMD（单指令，多数据）

SIMD（Single Instruction, Multiple Data）在处理存放大量数据的数据结构有其独特的优点，好比存放不少不一样数据的 vector（容器），就能够用同一个指令同时对容器的不一样部分作处理，这种方法会大幅提升复杂计算的效率好比游戏或者 VR 应用。

异常处理

许多语言都仿照 C++ 式的异常处理，可是 WebAssembly 并无包含异常处理，若是咱们用 Emscripten 编译代码，就知道它会模拟异常处理，可是这一过程很是之慢，慢到想用 “DISABLEEXCEPTIONCATCHING” 标记把异常处理关掉。若是异常处理加入到 WebAssembly 中那就没必要再采用模拟的方式，而异常处理对于开发者来说又特别重要，因此这也是将来的一大功能点。