(转)WASM（WebAssember）快速了解第二篇——快速了解JIT

这是有关WebAssembly的系列文章的第二部分，若是您尚未阅读其余文章，咱们建议从头开始。

JavaScript的启动速度很慢，但后来有了所谓的JIT，它变得更快。可是，JIT如何工做？

浏览器如何运行JavaScript

当您做为开发人员向页面添加JavaScript时，您就有目标和问题。

目标：您想告诉计算机该怎么作。

问题：您和计算机使用不一样的语言。

您说人类语言，而计算机说机器语言。即便您不将JavaScript或其余高级编程语言视为人类语言，也是如此。它们是为人类认知而不是机器认知而设计的。

所以，JavaScript引擎的工做是采用您的人工语言并将其变成机器能够理解的东西。

我认为这就像电影《到来》，其中有人和外星人试图互相交谈。

在那部电影中，人类和外星人不仅是逐字翻译。两组对世界的见解不一样。人和机器也是如此（我将在下一篇文章中对此进行更多说明）。

那么翻译如何发生？

在编程中，一般有两种翻译成机器语言的方法。您可使用解释器或编译器。

有了翻译员，这种翻译几乎是逐行进行的。

 另外一方面，编译器不会即时进行翻译。它能够提早建立该翻译并将其记录下来。

这些处理翻译的方式各有利弊。

解释器的利弊

解释器能够快速启动并运行。在开始运行代码以前，无需完成整个编译步骤。您只需开始翻译第一行并运行它。

所以，解释器彷佛很适合JavaScript之类的东西。对于Web开发人员而言，可以快速开始并运行其代码很是重要。

这就是为何浏览器最初使用JavaScript解释器的缘由。

可是，当您屡次运行相同的代码时，就会使用解释器。例如，若是您处于循环中。而后，您必须一遍又一遍地进行相同的翻译。 

编译器的优缺点

编译器具备相反的权衡。

启动须要花费更多时间，由于它必须在开始时执行该编译步骤。可是随后循环中的代码运行得更快，由于它不须要为每次经过该循环重复翻译。

另外一个区别是，编译器有更多时间查看代码并对其进行编辑，以使其运行更快。这些编辑称为优化。

解释器在运行时进行工做，所以在翻译阶段能够花不少时间来找出这些优化。

即时编译器：一箭双鵰

做为摆脱解释器效率低下的一种方式（浏览器每次循环时都必须不断从新翻译代码），浏览器开始将编译器混入其中。

不一样的浏览器以略有不一样的方式执行此操做，可是基本思想是相同的。他们向JavaScript引擎添加了一个新部件，称为监视器（又称为探查器）。该监视器在代码运行时对其进行监视，并记录其运行了多少次以及使用了哪一种类型。

首先，监视器只是经过解释器运行全部内容。

若是同一行代码运行了几回，则该段代码称为热代码。若是运行不少，则称为高温。

基准编译器

当功能开始变热时，JIT会将其发送出去进行编译。而后它将存储该编译。

函数的每一行都被编译为一个“存根”。存根由行号和变量类型索引（稍后将解释为何这很重要）。若是监视器发现执行再次使用相同的变量类型命中相同的代码，则它将仅提取其编译版本。

这有助于加快速度。可是就像我说的，还有更多的编译器能够作。找出解决方案的最有效方法可能须要一些时间。

基准编译器将进行其中的一些优化（我在下面给出一个示例）。可是，它不想花费太多时间，由于它不想使执行时间太长。

可是，若是代码真的很热（若是正在运行不少次），那么值得花费额外的时间进行更多的优化。

优化编译器

当一部分代码很是热时，监视器会将其发送给优化的编译器。这将建立该功能的另外一个甚至更快的版本，该版本也将被存储。

为了使代码的版本更快，优化的编译器必须作出一些假设。

例如，若是能够假设由特定构造函数建立的全部对象都具备相同的形状（即它们始终具备相同的属性名称，而且这些属性以相同的顺序添加），则它能够基于在那。

优化编译器经过监视代码执行状况来使用监视器收集的信息来作出这些判断。若是对于先前经过循环的全部遍历都为真，则假定它将继续为真。

可是，固然，对于JavaScript，永远不会有任何保证。您可能拥有所有具备相同形状的99个对象，可是第100个对象可能缺乏属性。

所以，编译后的代码须要在运行以前进行检查，以查看这些假设是否有效。若是它们是，则编译的代码将运行。可是，若是不是这样，JIT会假设本身作出了错误的假设，并浪费了优化后的代码。

 

而后执行返回到解释器或基准编译版本。此过程称为反优化（或应急）。

一般，优化编译器可以使代码更快，但有时它们可​​能会致使意外的性能问题。若是您的代码不断进行优化，而后再进行优化，那么最终结果将比仅执行基准编译版本慢。

大多数浏览器都增长了限制，以在发生这些优化/反优化周期时突围而出。若是JIT进行了10次以上的优化尝试，而又不得不将其扔掉，它将中止尝试。

优化示例：类型专门化

有不少不一样类型的优化，可是我想看看一种类型的优化，以便您能够感受到优化是如何发生的。优化编译器的最大胜利之一就是所谓的类型专门化。

JavaScript使用的动态类型系统在运行时须要一些额外的工做。例如，考虑如下代码：

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

+=循环中的步骤彷佛很简单。看起来您能够一步计算出来，可是因为动态键入，它须要的步骤比您预期的要多。

假设这arr是一个100个整数的数组。代码预热后，基线编译器将为函数中的每一个操做建立一个存根。所以，将有一个存根sum += arr[i]，它将+=做为整数加法处理操做。

可是，sum和arr[i]不能保证为整数。因为类型在JavaScript中是动态的，所以在循环的后续迭代中arr[i]可能会有一个字符串。整数加法和字符串串联是两个很是不一样的操做，所以它们将编译为很是不一样的机器代码。

JIT处理此问题的方法是编译多个基准存根。若是一段代码是单态的（即始终以相同的类型调用），它将获得一个存根。若是它是多态的（从一种代码传递到另外一种代码使用不一样的类型调用），那么它将为经过该操做的每种类型的组合获取一个存根。

这意味着JIT在选择存根以前必须先问不少问题。

 

因为基线编译器中每行代码都有其本身的存根集，所以，每次执行该行代码时，JIT都须要继续检查类型。所以，对于循环中的每次迭代，都必须提出相同的问题。

 

若是JIT不须要重复这些检查，则代码的执行速度将大大提升。这就是优化编译器要作的事情之一。

在优化编译器中，整个函数将一块儿编译。移动类型检查，使它们在循环以前发生。

 

一些JIT对此进行了进一步优化。例如，在Firefox中，对于仅包含整数的数组有一个特殊的分类。若是arr是这些数组之一，则JIT不须要检查是否arr[i]为整数。这意味着JIT能够在进入循环以前执行全部类型检查。

结论

简而言之，这就是JIT。经过监视正在运行的代码并发送要优化的热代码路径，它可使JavaScript运行更快。这致使大多数JavaScript应用程序的性能获得了许多方面的改进。

即便进行了这些改进，JavaScript的性能仍然是不可预测的。为了使事情更快，JIT在运行时增长了一些开销，包括：

• 优化和反优化
• 内存，用于监视器的簿记和恢复信息，以了解什么时候发生救助
• 用于存储功能的基准和优化版本的内存

这里还有改进的余地：能够消除开销，使性能更可预测。这就是WebAssembly要作的事情之一。

在接下来的文章中，我将更多地解释装配和编译器如何使用它。

转自：https://hacks.mozilla.org/2017/02/a-crash-course-in-just-in-time-jit-compilers/