一个白学家眼里的 WebAssembly

时间 2020-01-16

标签一个学家眼里 webassembly 繁體版

原文原文链接

在知乎「如何看待 WebAssembly 技术」的问题里，能够看出你们广泛对浏览器、WASM 和 JS 之间的三角关系有很多误解。所以这里做为一个开 (bai) 发 (xue) 者 (jia)，我就来尝试纠正些常见的问题吧。javascript

全文观点摘要：WASM 运行时性能在原理上就是受限的，甚至 JS 均可以和编译到 WASM 的 Rust 一较高下。加上工具链的高度侵入性，它并不太适合做为前端背景同窗 all in 的方向，但对于原生应用的跨平台分发则很是有潜力。html

WASM == 汇编级性能？

这显然不对，WASM 里的 Assembly 并不意味着真正的汇编码，而只是种新约定的字节码，也是须要解释器运行的。这种解释器确定比 JS 解释器快得多，但天然也达不到真正的原生机器码水平。一个可供参考的数据指标，是 JS 上了 JIT 后总体性能大体是机器码 1/20 的水平，而 WASM 则能够跑到机器码 1/3 的量级（视场景不一样很很差说，仅供参考）。至关于即使你写的是 C++ 和 Rust 级的语言，获得的其实也只是 Java 和 C# 级的性能。这也能够解释为何 WASM 并不能在全部应用场景都显示出压倒性的性能优点：只要你懂得如何让 JS 引擎走在 Happy Path 上，那么在浏览器里，JS 就敢和 Rust 五五开。前端

一个在 WASM 和 JS 之间作性能对比的经典案例，就是 Mozilla 开发者和 V8 开发者的白学现场。整个过程是这样的：java

Mozilla Hacks 发表了一篇名为用 Rust 和 WASM 优化 Source Map 性能的博文，将 source-map 这个 JS 包的性能优化了五倍。
V8 核心开发 Vyacheslav Egorov 回应了名为你也许不须要用 Rust 和 WASM 来优化 JS 的博文，用纯 JS 实现了速度比 Rust 更快的惊人优化。
原文做者以无需魔法的速度为名展开了进一步讨论，并用 Rust 作出了新的性能优化。

巧的是，这场论战正发生在两年前白色相簿的季节。双方就像雪菜和冬马那样展开了高水平的对决，名场面十分精彩。最终 Vyacheslav 给出了一张三轮过招后的性能对比图。能够看到虽然最终仍是 Rust 更快，但 JS 被逼到极限后非但不是败犬，还胜出了一回合：node

JS：先开始性能优化的是你吧！擅自跑到我没法触及的地方去的人是你吧！明明高不可攀，却又近在咫尺，先想出这种拷问方式的人是你吧！明明是这样，为何还非得被你责备不可啊…？像那样…天天、天天，在个人眼前，跑得那么快…还说这全都是个人错…太残忍了啊…linux

另外，Milo Yip 大大作过的不一样语言光线追踪性能测试（修罗场），也能侧面印证带 VM 语言与机器码之间的性能对比结论。C++、Java 和 JS 在未经特别优化的前提下，能够分别表明三个典型的性能档次：android

C++/C#/F#/Java/JS/Lua/Python/Ruby 渲染比试git

Ruby：为何大家都这么熟练啊！程序员

WASM 比 JS 快，因此计算密集型应用就该用它？

这有点偏颇，WASM 一样是 CPU 上的计算。对于能够高度并行化的任务，使用 WebGL 来作 GPU 加速每每更快。譬如我在实用 WebGL 图像处理入门这篇文章里介绍的图像处理算法，比起 JS 里 for 循环遍历 Canvas 像素就能够很轻松地快个几十倍。而这种套两层 for 循环的苦力活，用如今的 WASM 重写能快几倍就很是不错了。至于浏览器内 AI 计算的性能方面，社区的评测结论也是 WebGL 和 WebMetal 具有最高的性能水平，而后才是 WASM。参见这里：浏览器内的 AI 评测github

不过，WebGL 的加速存在精度问题。例如前端图像缩放库 Pica，它的核心用的是 Lanczos 采样算法。我用 WebGL 着色器实现过这个算法，它并不复杂，早期的 Pica 也曾经加入过可选的 WebGL 优化，但如今却劈腿了 WASM。这一决策的理由在于，WASM 能保证相同参数下的计算结果和 JS 一致，但 WebGL 则不行。相关讨论参见这里：Issue #114 · nodeca/pica

因此对计算密集型任务，WASM 并非前端惟一的救星，而是给你们多了一种在性能、开发成本和效果之间权衡的选择。在我我的印象里，前端在图形渲染外须要算力的场景说实话并不太多，像加密、压缩、挖矿这种，都难说是高频刚需。至于将来可能至关重要的 AI 应用，长期而言我仍是看好 WebGPU 这种更能发挥出 GPU 潜力的下一代标准，固然 WASM 也已是个不错的可选项了。

WebGL：是我，是我先，明明都是我先来的…3D 也好，图像处理也好，仍是深度学习也好…

只要嵌入 WASM 函数到 JS 就能提升性能？

既然 WASM 很快，那么是否是我只要把 JS 里 const add (a, b) => a + b 这样的代码换成用 C 编译出来的 WASM，就能够有效地提升性能了呢？

这还真不必定，由于现代浏览器内的 JS 引擎都标配了一种东西，那就是 JIT。简单来讲，上面这个 add 函数若是始终都在算整数加法，那么 JS 引擎就会自动编译出一份计算 int a + int b 的机器码来替代掉原始的 JS 函数，这样高频调用这个函数的性能就会获得极大的提高，这也就是 JIT 所谓 Just-in-time 编译的奥妙所在了。

因此，不要一以为 JS 慢就想着手动靠 WASM 来嵌入 C，其实现代 JS 引擎可都是在不停地帮你「自动把 JS 转换成 C」的！若是你能够把一个 JS 函数改写成等价的 C，那么我猜若是把这个函数单独抽离出来，靠 JS 引擎的 JIT 都极可能达到相近的性能。这应该就是 V8 开发者敢用 JS 和 Rust 对线的底气所在吧。

像在 JS 和 WASM 之间的调用终于变快了这篇文章中，Lin Clark 很是精彩地论述了整个优化过程，最终使得 JS 和 WASM 间的函数调用，比非内联的 JS 函数间调用要快。不过，至于和被 JIT 内联掉的 JS 函数调用相比起来如何，这篇文章就没有说起了。

这里偏个题，Mozilla 常常宣传本身实现的超大幅优化，有很多均可能来源于以前明显的设计问题（平心而论，咱们本身未尝不是这样呢）。像去年 Firefox 70 在 Mac 上实现的大幅省电优化，其根源是什么呢？粗略的理解是，之前的 Firefox 在 Mac 上居然每帧都会全量更新窗口像素！固然，这些文章的干货都至关多，十分推荐你们打好基础后看看原文，至少是个更大的世界，也经常能对软件架构设计有所启发。

若是后续 WASM 支持了 GC，那么嵌入互调的状况极可能更复杂。例如我最近就尝试在 Flutter 的 Dart 和安卓的 Java 之间手动同步大对象，但愿能「嵌入一些安卓平台能力到 Flutter 体系里」，然而这带来了许多冗长而低性能的胶水代码，须要经过异步的消息来作深拷贝，可控性很低。虽然 WASM 如今尚未 GC，但一旦加上，我有理由怀疑它和 JS 之间的对象生命周期管理也会遇到相似的问题。只是这个问题主要是让 Mozilla 和 Google 的人来操心，用不着咱们管而已。

参数传递什么的，已经无所谓了。由于已经再也不有函数，值得去调了。传达不了的指针，已经不须要了。由于已经再也不有对象，值得去爱了。

在 JS 里调 WASM，就像 Python 里调 C 那样简单？

这个问题只有实际作过才有发言权。譬如我最近尝试过的这些东西：

在安卓的 Java class 里调用 C++
在 Flutter 的 Dart 里调用 C
在 QuickJS 这种嵌入式 JS 引擎里调用 C

它们都能作到一件事，那就是在引擎里新建原生对象，并将它以传引用的方式直接交给 C / C++ 函数调用，并用引擎的 GC 来管理对象的生命周期。这种方式通常称为 FFI（Foreign Function Interface 外部函数接口），能够把原生代码嵌入到语言 Runtime 中。但若是是两个不一样的 Runtime，事情就没有这么简单了。例如 QuickJS 到 Java 的 binding 项目 Quack，就须要在 JS 的对象和 Java 对象中作 Marshalling（相似于 JSON 那样的序列化和反序列化）的过程，不能随便传引用。

对 WASM 来讲是怎样的呢？基本上，WASM 的线性内存空间能够随便用 JS 读写，并无深拷贝的困扰。不过，WASM 只有 int 和 float 之流的数据类型，连 string 都没有，所以对于稍复杂一点的对象，都很难手写出 JS 和 WASM 两边各自的结构。如今这件脏活是交由 wasm-bindgen 等轮子来作的。但毕竟这个过程并非直接在 JS 的 Runtime 里嵌入 C / C++ 函数，和传统编译到机器码的 FFI 仍是挺不同的。

而至于不能在 WASM 的 Memory 对象里表达的 JS 对象，就会遇到一种双份快乐的问题了。例如如今若是须要频繁地用 WASM 操做 JS 对象，那么几乎必然是影响性能的。这方面典型的坑是基于 WASM 移植的 OpenGL 应用。像 C++ 中的一个 glTexImage2D 函数，目前编译到 WASM 后就须要先从 WASM 走到 JS 胶水层，再在 JS 里调 gl.texImage2D 这样的 WebGL API，最后才能经由 C++ binding 调用到原生的图形 API。这样从一层胶水变成了两层，性能不要说比起原生 C++，能比得上直接写 JS 吗？

固然，Mozilla 也意识到了这个问题，所以他们在尝试如何更好地将 Web IDL（也就是浏览器原生 API 的 binding）开放给 WASM，并在这个过程当中提出了 WASM Interface Types 概念：既然 WASM 已是个字节码的中间层了，那么干脆给它约定个能一统全部编程语言运行时类型的 IR 规范吧！不过，这一规范仍是但愿主要靠协议化、结构化的深拷贝来解决问题，只有将来的 anyref 类型是能够传引用的。anyref 有些像 Unix 里的文件描述符，这里就不展开了。

因此，将来也许 WASM 里会有 DOM 的访问能力，但目前这毕竟还只是个饼。不要说像 WebGL 的某些扩展已经明确不受 Web IDL 支持，就算距离把主流的 Web 标准都开放到 WASM 并普及到主流用户，在 2020 年这个时间节点看来仍是挺遥远的。

浏览器：为何会变成这样呢…第一次有了高性能的脚本语言，又兼容了高级的原生语言。两份快乐重叠在一块儿。而这两份快乐，又带来了更多的快乐。获得的，本该是像梦境通常的幸福时光…可是，为何，会变成这样呢…

前端框架早晚会用 WASM 重写？

我以为很难，或者说这件事的投入产出比 (ROI) 未必足够。由于对于主流的前端应用来讲，它们都是 IO 密集而不是计算密集型的，这时 WASM 增长的算力很难成为瓶颈，反而会增长许多工程上的维护成本。

这方面的一个论据，是 Google 的 JIT-less V8 介绍。V8 在关闭 JIT 后峰值性能下降到了不到原先十分之一的级别（见 QuickJS Benchmark），却也几乎不影响刷 YouTube 这种轻度应用的性能表现，在模拟重度 Web 应用负载的 Speedometer 标准下，其跑分也有原先的 60% 左右，只有在 Webpack 打包类型的任务上出现了数量级的差别。你以为迁移到 WASM 后，峰值算力就算比如今再翻两倍，能在事件驱动、IO 密集的 GUI 场景中表现出颠覆性的突破吗？能说服框架做者们彻底放弃现有的 JS 代码库，选用另外一种语言来完全重写框架吗？何况 WASM 从长期来看，可都要依赖很多体积足以影响首屏性能的 JS 胶水代码和 polyfill 呢。

用 WASM 重写主流 UI 框架，意味着前端须要重度依赖一门彻底不一样的语言技术栈。你说由于 JVM 比 V8 快，因此 Node 应用就应该用 Java 重写吗？我看前端圈里的政治正确明明是反过来的啊…

我即便是死了，钉在棺材里了，也要在墓里，用这腐朽的声带喊出：JS 牛逼！！！（被禁言）

WASM 属于前端生态？

这个我不太承认。要知道，一个 WASM 应用，其编译工具链和依赖库生态，基本彻底不涉及 JS。

2018 年我尝试编译过 ffmpeg 到 WASM，这整个过程几乎和 JS 没任何关系，重点都集中在搭建 Docker 编译环境和魔改 Makefile 上了。以我当时的水平，整个流程让我很是困惑。

后来我在折腾嵌入式 Linux 和安卓的过程当中，顺带搞懂了工具链的概念。一个原生应用，须要编译、汇编和连接过程，才能变为一个可执行文件。好比个人开发机是 Mac，那么装在 macOS 上典型的几套工具链像这样：

面向 macOS 的工具链，是编译到 macOS 二进制格式的 clang 那一套
面向安卓的工具链，是编译到 ARM 二进制格式的 aarch64-linux-android-gcc 那一套（在 NDK 里翻翻就知道了）
面向 PSP 的工具链，是编译到 MIPS 二进制格式的 mips-gcc 那一套（名字不必定对啊）
面向 WASM 的工具链，是面向 WASM 字节码格式的 Emscripten 那一套

后面三者都是编译到其它的平台，所以叫作交叉编译。

一套支持交叉编译的工具链，会附带上用于支持目标平台的一些库，例如 include 了 <GLES2/gl2.h> 以后，你调用到的 glTexImage2D API 就是动态库里提供的。有了动态库，这个 API 才能在 x86 / ARM / MIPS / WASM 等平台上一致地跑起来（就像安卓上的 .so 格式）。像 Emscripten 就提供了面向 WASM 平台，编译成 JS 格式的一套动态库。但它只能保证这些 API 能用，性能如何就另说了。它本身也对移植 WebGL 时的性瓶颈提出了不少的优化建议。

因此这里再重复一遍，编译 WASM 应用所需的依赖库和整套工具链，几乎都跟 JS 没什么关系。JS 就像机器码那样，只是人家工具链编译出来的输出格式而已。在 JS 开发者看来，这整套东西可能显得至关突兀。但从原生应用开发者的视角看来，这一切都再正常不过了。

来而不往非礼也。WASM 能够把其它语言引进来，JS 就不能往外走出去了吗？除了 Flutter 这种修正主义路线，像我详细介绍过的 Static TypeScript 和 QuickJS，就是信奉 JS 系的冬马党们搞的反向输出：

说了这么多，那么 WASM 的适用场景究竟是什么呢？如今 WASM 社区大力推广的提案，如 WASI、多线程、GC 这些，其实都跟 JS 生态关系不大，而是方便把更复杂的原生应用直接搬进 Web 的技术需求。话都说到这份上了，你们还没看出来吗？这不就是典型雪菜式的明修栈道，暗度陈仓嘛（笑）

最后总结下，JS 和 WASM 的人设大概各自是这样的：

JS：我先来的，哪里有浏览器，哪里就是个人主场。虽然有人不喜欢个人脾气，但我到哪都是一头黑长直的字符串脚本。追个人引擎有的是，但我始终首先是浏览器的忠犬。
WASM：我是高岭之花，浏览器内外你们都欢迎我，并且谁都能编译到我，因此欢迎你们都来用个人二进制格式吧。我虽然很想和 JS 和浏览器三我的永远在一块儿，但最但愿之后跨平台只要靠个人努力就能够永远幸福下去了。

WASM：啊…若是 JS 是强类型的男孩子的话就行了。

你以为明明先来的冬马 (JS) 和高岭之花的雪菜 (WASM) 哪一个更对你胃口呢？提醒下某些成天喊着我全都要的白学家，双份快乐可不是通常人玩得起的噢。

通常来讲整个白学家（程序员）群体里冬马党基数最大，但骨灰级玩家经常是雪菜党。至于我嘛…你看看我简介里的花名叫什么？

最后上一张合照，冬马和雪菜都是好样的！

后记

WASM 固然是个革命性的技术，表明了一种跨平台的全新方向，尤为对原生应用开发者来讲具有巨大的商业价值。但它对前端来讲其实就是个浏览器内置的字节码虚拟机，不是一切性能问题的灵丹妙药。目前网上很多对它的赞美，在我看来多少有些过誉了。因此建议你们不要盲目跟风，仍是从白学，啊不计算机科学的基础出发，去判断一个技术的适用场景和价值在哪吧。

本文配图均来自纯 JS 实现的高性能前端应用稿定 PS。白学部分纯属娱乐，请你们不要过度解读（如为何 JS 的 Logo 是雪菜黄，而 WASM 的 Logo 反而是冬马紫之类）。个人水平有限，欢迎你们对本文技术观点更进一步的交流，也但愿你们能关注个人「前端随想录」这个自由技术专栏～