document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2024-12-23 21:20:42 +08:00
Code Issues Packages Projects Releases Wiki Activity

PRF:20161216 The truth about traditional JavaScript benchmarks.md

Browse Source 
@OneNewLife
累死了——居然前前后后我中断了好几次，花了半年的时间才把这篇校对完——我对你能翻译完这么长，这么专业的文章感觉敬仰之极啊！
This commit is contained in:
wxy 2017-09-29 15:51:01 +08:00
parent 45a236fc7c
commit 623f964599
1 changed files with 12 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
translated/tech/20161216 The truth about traditional JavaScript benchmarks.md
View File

@ -171,7 +171,7 @@ Kraken 基准是 [Mozilla 于 2010 年 9 月 发布的][58]，据说它包含了
[![audio-oscillator-data.js](http://benediktmeurer.de/images/2016/audio-oscillator-constructor-20161216.png)][63]
如果我们知道整数模数运算的右边是 2 的幂，我们可以生成显然[更好的代码][64]，完全避免了英特尔上的 `idiv` 指令。所以我们需要获取一种信息使 `this.waveTableLength` 从 `Oscillator` 构造器到 `Oscillator.prototype.generate` 中的模运算都是 2048。一个显而易见的方法是尝试依赖于将所有内容内嵌到 `calcOsc` 函数，并让 `load/store` 消除为我们进行的常量传播，但这对于在 `calcOsc` 函数之外分配的 `sine` `oscillator` 无效。
如果我们知道整数模数运算的右边是 2 的幂，我们显然可以生成[更好的代码][64]，完全避免了英特尔上的 `idiv` 指令。所以我们需要获取一种信息使 `this.waveTableLength` 从 `Oscillator` 构造器到 `Oscillator.prototype.generate` 中的模运算都是 2048。一个显而易见的方法是尝试依赖于将所有内容内嵌到 `calcOsc` 函数，并让 `load/store` 消除为我们进行的常量传播，但这对于在 `calcOsc` 函数之外分配的 `sine` `oscillator` 无效。
因此，我们所做的就是添加支持跟踪某些常数值作为模运算符的右侧反馈。这在 V8 中是有意义的，因为我们为诸如 `+`、`*` 和 `%` 的二进制操作跟踪类型反馈，这意味着操作者跟踪输入的类型和产生的输出类型（参见最近的圆桌讨论中关于[动态语言的快速运算][65]的幻灯片）。当然，用 `fullcodegen` 和 `Crankshaft` 挂接起来也是相当容易的，`MOD` 的 `BinaryOpIC` 也可以跟踪右边已知的 2 的冥。
@ -414,11 +414,11 @@ $
由此可见，在检测 `global_init` 和避免昂贵的预解析步骤我们几乎提升了 2 倍。我们不太确定这是否会对真实用例产生负面影响，不过保证你在预解析大函数的时候将会受益匪浅（因为它们不会立即执行）。
让我们来看看另一个稍有争议的基准测试：[splay.js][89] 测试，一个用于处理伸展树（二叉查找树的一种）和练习自动内存管理子系统（也被成为垃圾回收器）的数据操作基准。它自带一个延迟测试，这会引导 `Splay` 代码通过频繁的测量检测点，检测点之间的长时间停顿表明垃圾回收器的延迟很高。此测试测量延迟暂停的频率，将它们分类到桶中，并以较低的分数惩罚频繁的长暂停。这听起来很棒！没有 `GC` 停顿，没有垃圾。纸上谈兵到此为止。让我们看看这个基准，以下是整个伸展树业务的核心：
让我们来看看另一个稍有争议的基准测试：[splay.js][89] 测试，一个用于处理<ruby>伸展树<rt>splay tree</rt></ruby>（二叉查找树的一种）和练习自动内存管理子系统（也被称为垃圾回收器）的数据操作基准。它自带一个延迟测试，这会引导 `Splay` 代码通过频繁的测量检测点，检测点之间的长时间停顿表明垃圾回收器的延迟很高。此测试测量延迟暂停的频率，将它们分类到桶中，并以较低的分数惩罚频繁的长暂停。这听起来很棒！没有 GC 停顿，没有垃圾。纸上谈兵到此为止。让我们看看这个基准，以下是整个伸展树业务的核心：
[![splay.js](http://benediktmeurer.de/images/2016/splay-insertnode-20161216.png)][90]
这是伸展树结构的核心，尽管你可能想看完整的基准，不过这或多或少是 `SplayLatency` 得分的重要来源。怎么回事？实际上，基准测试是建立巨大的伸展树，尽可能保留所有节点，从而还原它原本的空间。使用像 V8 这样的代数垃圾回收器，如果程序违反了[代数假设][91]，导致极端的时间停顿，从本质上看，将所有东西从新空间撤回到旧空间的开销是非常昂贵的。在旧配置中运行 V8 可以清楚地展示这个问题：
这是伸展树结构的核心构造，尽管你可能想看完整的基准，不过这基本上是 `SplayLatency` 得分的重要来源。怎么回事？实际上，该基准测试是建立巨大的伸展树，尽可能保留所有节点，从而还原它原本的空间。使用像 V8 这样的代数垃圾回收器，如果程序违反了[代数假设][91]，会导致极端的时间停顿，从本质上看，将所有东西从新空间撤回到旧空间的开销是非常昂贵的。在旧配置中运行 V8 可以清楚地展示这个问题：
```
$ out/Release/d8 --trace-gc --noallocation_site_pretenuring octane-splay.js
@ -501,7 +501,7 @@ $ out/Release/d8 --trace-gc --noallocation_site_pretenuring octane-splay.js
$
```
因此这里关键的发现是直接在旧空间中分配伸展树节点可基本避免在周围复制对象的所有开销，并且将次要 `GC` 周期的数量减少到最小（从而减少 `GC` 引起的停顿时间）。我们想出了一种称为[分配站点预占][92]的机制，当运行到基线代码时，将尝试动态收集分配站点的反馈，以决定在此分配的对象的部分是否确切存在，如果是，则优化代码以直接在旧空间分配对象——即预占对象。
因此这里关键的发现是直接在旧空间中分配伸展树节点可基本避免在周围复制对象的所有开销，并且将次要 GC 周期的数量减少到最小（从而减少 GC 引起的停顿时间）。我们想出了一种称为<ruby>[分配场所预占][92]<rt>allocation site pretenuring</rt></ruby>的机制，当运行到基线代码时，将尝试动态收集分配场所的反馈，以决定在此分配的对象的确切部分是否存在，如果是，则优化代码以直接在旧空间分配对象——即预占对象。
```
$ out/Release/d8 --trace-gc octane-splay.js
@ -532,13 +532,13 @@ $
[![SplayLatency 基准](http://benediktmeurer.de/images/2016/awfy-splay-20161216.png)][93]
正如 [SIGPLAN 论文][94] 中所提及的，我们有充分的理由相信，分配站点预占机制可能真的赢得了真实世界应用的欢心，并真正期待看到改进和扩展后的机制，那时将不仅仅是对象和数组字面量。但是不久后我们意识到[分配站点预占机制对真实世界引用产生了相当严重的负面影响][97]。我们实际上得到很多负面新闻，包括 `Ember.js` 开发者和用户的唇枪舌战，不仅是因为分配站点预占机制，不过它是事故的罪魁祸首。
正如 [SIGPLAN 论文][94] 中所提及的，我们有充分的理由相信，分配场所预占机制可能真的赢得了真实世界应用的欢心，并真正期待看到改进和扩展后的机制，那时将不仅仅是对象和数组字面量。但是不久后我们意识到[分配场所预占机制对真实世界应用产生了相当严重的负面影响][97]。我们实际上听到很多负面报道，包括 `Ember.js` 开发者和用户的唇枪舌战，虽然不仅是因为分配场所预占机制，不过它是事故的罪魁祸首。
分配站点预占机制的基本问题数之不尽，这在今天的应用中非常常见（主要是由于框架，同时还有其它原因），假设你的对象工厂最初是用于创建构成你的对象模型和视图的长周期对象的，它将你的工厂方法中的分配站点转换为永久状态，并且从工厂分配的所有内容都立即转到旧空间。现在初始设置完成后，你的应用开始工作，作为其中的一部分，从工厂分配临时对象会污染旧空间，最终导致开销昂贵的垃圾回收周期以及其它负面的副作用，例如过早触发增量标记。
分配场所预占机制的基本问题数之不尽，这在今天的应用中非常常见（主要是由于框架，同时还有其它原因），假设你的对象工厂最初是用于创建构成你的对象模型和视图的长周期对象的，它将你的工厂方法中的分配场所转换为永久状态，并且从工厂分配的所有内容都立即转到旧空间。现在初始设置完成后，你的应用开始工作，作为其中的一部分，从工厂分配临时对象会污染旧空间，最终导致开销昂贵的垃圾回收周期以及其它负面的副作用，例如过早触发增量标记。
我们开始重新考虑基准驱动的工作，并开始寻找驱动现实场景的替代方案，这导致了 [Orinoco][98] 的诞生，它的目标是逐步改进垃圾回收器；这个努力的一部分是一个称为“统一堆”的项目，如果页面中的所有内容都存在，它将尝试避免复制对象。也就是说站在更高的层面看：如果新空间充满活动对象，只需将所有新空间页面标记为属于旧空间，然后从空白页面创建一个新空间。这可能不会在 `SplayLatency` 基准测试中得到相同的分数，但是这对于真实用例更友好，它可以自动适配具体的用例。我们还考虑并发标记，将标记工作卸载到单独的线程，从而进一步减少增量标记对延迟和吞吐量的负面影响。
我们开始重新考虑基准驱动的工作，并开始寻找现实场景驱动的替代方案，这导致了 [Orinoco][98] 的诞生，它的目标是逐步改进垃圾回收器；这个努力的一部分是一个称为“<ruby>统一堆<rt>unified heap</rt></ruby>”的项目，如果页面中所有内容基本都存在，它将尝试避免复制对象。也就是说站在更高的层面看：如果新空间充满活动对象，只需将所有新空间页面标记为属于旧空间，然后从空白页面创建一个新空间。这可能不会在 `SplayLatency` 基准测试中得到相同的分数，但是这对于真实用例更友好，它可以自动适配具体的用例。我们还考虑<ruby>并发标记<rt>concurrent marking</rt></ruby>，将标记工作卸载到单独的线程，从而进一步减少增量标记对延迟和吞吐量的负面影响。
### 轻松一刻
#### 轻松一刻
![](https://pbs.twimg.com/profile_images/491838225300717568/sy5AWvt1.jpeg)
@ -548,15 +548,15 @@ $
### 结论
我希望现在应该清楚为什么基准测试通常是一个好主意，但是只对某个特定的级别有用，一旦你跨越了有用竞争的界限，你就会开始浪费你们工程师的时间，甚至开始损害到你的真实世界的性能！如果我们认真考虑 web 的性能，我们需要根据真实世界的性能来测评浏览器，而不是它们玩弄一个四年的基准的能力。我们需要开始教育（技术）媒体，可能这没用，但至少请忽略他们。
我希望现在应该清楚为什么基准测试通常是一个好主意，但是只对某个特定的级别有用，一旦你跨越了<ruby>有用竞争<rt>useful competition</rt></ruby>的界限，你就会开始浪费你们工程师的时间，甚至开始损害到你的真实世界的性能！如果我们认真考虑 web 的性能，我们需要根据真实世界的性能来测评浏览器，而不是它们玩弄一个四年前的基准的能力。我们需要开始教育（技术）媒体，可能这没用，但至少请忽略他们。
[![2016 年 10 月浏览器基准之战: Chrome、Firefox 和 Edge 的决战](http://benediktmeurer.de/images/2016/venturebeat-20161216.png)][99]
没人害怕竞争，但是玩弄可能已经坏掉的基准不像是在合理使用工程时间。我们可以尽更大的努力，并把 JavaScript 提高到更高的水平。让我们开展有意义的性能测试，以便为最终用户和开发者带来有意思的领域竞争。此外，让我们再对服务器和运行在 Node.js（还有 V8 和 `ChakraCore`）中的工具代码做一些有意义的改进！
没人害怕竞争，但是玩弄可能已经坏掉的基准不像是在合理使用工程时间。我们可以尽更大的努力，并把 JavaScript 提高到更高的水平。让我们开展有意义的性能测试，以便为最终用户和开发者带来有意思的领域竞争。此外，让我们再对运行在 Node.js（ V8 或 `ChakraCore`）中的服务器端和工具端代码做一些有意义的改进！
![](http://benediktmeurer.de/images/2016/measure-20161216.jpg)
结束语：不要用传统的 JavaScript 基准来比较手机。这是真正最没用的事情，因为 JavaScript 的性能通常取决于软件，而不一定是硬件，并且 Chrome 每 6 周发布一个新版本，所以你在三月的测试结果到了四月就已经毫不相关了。如果在浏览器中发送一个数字都一部手机不可避免，那么至少请使用一个现代健全的浏览器基准来测试，至少这个基准要知道人们会用浏览器来干什么，比如 [Speedometer 基准][100]。
结束语：不要用传统的 JavaScript 基准来比较手机。这是真正最没用的事情，因为 JavaScript 的性能通常取决于软件，而不一定是硬件，并且 Chrome 每 6 周发布一个新版本，所以你在三月份的测试结果到了四月份就已经毫不相关了。如果为手机中的浏览器做个排名不可避免，那么至少请使用一个现代健全的浏览器基准来测试，至少这个基准要知道人们会用浏览器来干什么，比如 [Speedometer 基准][100]。
感谢你花时间阅读！
@ -564,7 +564,6 @@ $
作者简介：
我是 Benedikt Meurer，住在 Ottobrunn（德国巴伐利亚州慕尼黑东南部的一个市镇）的一名软件工程师。我于 2007 年在锡根大学获得应用计算机科学与电气工程的文凭，打那以后的 5 年里我在编译器和软件分析领域担任研究员（2007 至 2008 年间还研究过微系统设计）。2013 年我加入了谷歌的慕尼黑办公室，我的工作目标主要是 V8 JavaScript 引擎，目前是 JavaScript 执行性能优化团队的一名技术领导。
--------------------------------------------------------------------------------
@ -573,7 +572,7 @@ via: http://benediktmeurer.de/2016/12/16/the-truth-about-traditional-javascript-
作者：[Benedikt Meurer][a]
译者：[OneNewLife](https://github.com/OneNewLife)
校对：[OneNewLife](https://github.com/OneNewLife)
校对：[OneNewLife](https://github.com/OneNewLife), [wxy](https://github.com/wxy)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出