将应用的 JavaScript 中的热路径替换为 WebAssembly

速度一直很快,

之前的 文章中,我介绍了 WebAssembly 如何帮助您将 C/C++ 的库生态系统引入到 Web 中。我们的 Web 应用 squoosh 充分利用了 C/C++ 库,这是一款应用,可让您使用从 C++ 编译到 WebAssembly 的各种编解码器来压缩图像。

WebAssembly 是一种低层级虚拟机,可运行存储在 .wasm 文件中的字节码。此字节码属于强类型和结构化,因此可以比 JavaScript 更快地针对主机系统进行编译和优化。WebAssembly 提供了一个环境,用于运行从一开始就考虑到沙盒和嵌入的代码。

根据我的经验,网络上的大多数性能问题都是由强制布局和过度绘制导致的,但应用偶尔需要执行计算量大的任务,这会花费大量时间。WebAssembly 可以派上用场。

热路径

在 squoosh 中,我们编写了一个 JavaScript 函数,用于按 90 度倍数旋转图片缓冲区。虽然 OffscreenCanvas 非常适合此用途,但我们定位的浏览器不支持它,而且它在 Chrome 中存在一些 bug

此函数会迭代输入图片的每个像素,并将其复制到输出图片的其他位置,以实现旋转。对于 4094 x 4096 像素的图片(1600 万像素),它需要对内部代码块进行超过 1600 万次迭代,我们称之为“热路径”。尽管迭代次数相当多,但我们测试的三款浏览器中,有两款在 2 秒内完成了此任务。此类互动可接受的时长。

for (let d2 = d2Start; d2 >= 0 && d2 < d2Limit; d2 += d2Advance) {
    for (let d1 = d1Start; d1 >= 0 && d1 < d1Limit; d1 += d1Advance) {
    const in_idx = ((d1 * d1Multiplier) + (d2 * d2Multiplier));
    outBuffer[i] = inBuffer[in_idx];
    i += 1;
    }
}

不过,有一款浏览器的用时超过 8 秒。浏览器优化 JavaScript 的方式非常复杂,并且不同的引擎会针对不同的对象进行优化。有些优化针对原始执行,有些优化针对与 DOM 的互动。在本例中,我们在一个浏览器中遇到了未优化的路径。

另一方面,WebAssembly 完全以原始执行速度为基础构建而成。因此,对于像这样的代码,如果我们想在不同浏览器中实现快速、可预测的性能,WebAssembly 可以助您一臂之力。

使用 WebAssembly 实现可预测的性能

一般来说,JavaScript 和 WebAssembly 可以达到相同的峰值性能。不过,对于 JavaScript,只有在“快路”上才能达到这种性能,而要想一直走在“快路”上,通常很难。WebAssembly 提供的一个主要优势是可预测的性能,即使在不同浏览器之间也是如此。严格的类型和低级架构使编译器能够做出更强的保证,因此 WebAssembly 代码只需优化一次,并且将始终使用“快速路径”。

为 WebAssembly 编写代码

以前,我们会将 C/C++ 库编译为 WebAssembly,以便在 Web 上使用其功能。我们并未修改库的代码,只是编写了少量的 C/C++ 代码以在浏览器与库之间架起桥梁。这一次,我们的动机有所不同:我们想借助 WebAssembly 从头开始编写一些代码,以便充分利用 WebAssembly 的优势。

WebAssembly 架构

WebAssembly 编写代码时,不妨详细了解一下 WebAssembly 的实际含义。

如需引用 WebAssembly.org,请按以下步骤操作:

将一段 C 或 Rust 代码编译为 WebAssembly 时,您会得到一个包含模块声明的 .wasm 文件。此声明由模块预期从其环境导入的“导入”列表、此模块向主机提供的导出(函数、常量、内存块)列表,以及其中包含的函数的实际二进制指令组成。

在研究 WebAssembly 时,我发现了一个之前没有意识到的问题:使 WebAssembly 成为“基于堆栈的虚拟机”的堆栈并未存储在 WebAssembly 模块使用的内存块中。该堆栈完全位于虚拟机内部,Web 开发者无法访问(除非通过开发者工具访问)。因此,您可以编写完全不需要任何额外内存且仅使用虚拟机内部堆栈的 WebAssembly 模块。

在本例中,我们需要使用一些额外的内存来允许任意访问图像的像素,并生成该图像的旋转版本。这就是 WebAssembly.Memory 的用途。

内存管理

通常,使用额外的内存后,您需要以某种方式管理该内存。内存的哪些部分正在使用?哪些是免费的? 例如,在 C 中,您可以使用 malloc(n) 函数查找 n 个连续字节的内存空间。此类函数也称为“分配器”。当然,您必须在 WebAssembly 模块中添加所用分配器的实现,这会增加文件大小。这些内存管理函数的大小和性能可能会因所用算法而异,这也是许多语言提供多个实现可供选择(“dmalloc”“emmalloc”“wee_alloc”等)的原因。

在本例中,我们在运行 WebAssembly 模块之前就知道输入图片的尺寸(因此也知道输出图片的尺寸)。在这里,我们看到了机会:传统上,我们将输入图片的 RGBA 缓冲区作为参数传递给 WebAssembly 函数,并返回旋转后的图片作为返回值。要生成该返回值,我们必须使用分配器。但是,由于我们知道所需的总内存量(输入图片大小的两倍,一次用于输入,一次用于输出),因此我们可以使用 JavaScript 将输入图片放入 WebAssembly 内存,运行 WebAssembly 模块以生成第二个旋转的图片,然后使用 JavaScript 读回结果。我们可以完全不使用任何内存管理!

选择困难

如果您查看了我们要转换为 WebAssembly 的原始 JavaScript 函数,就会发现它是纯计算代码,不含任何 JavaScript 专用 API。因此,将此代码移植到任何语言应该都很简单。我们评估了 3 种可编译为 WebAssembly 的不同语言:C/C++、Rust 和 AssemblyScript。对于每种语言,我们只需回答一个问题:如何在不使用内存管理函数的情况下访问原始内存?

C 和 Emscripten

Emscripten 是适用于 WebAssembly 目标的 C 编译器。Emscripten 的目标是作为 GCC 或 clang 等知名 C 编译器的直接替代品,并且在大多数标志方面都兼容。这是 Emscripten 使命的核心部分,因为它希望尽可能简化将现有 C 和 C++ 代码编译为 WebAssembly 的过程。

访问原始内存是 C 语言的本质,而指针的存在正是出于这个原因:

uint8_t* ptr = (uint8_t*)0x124;
ptr[0] = 0xFF;

在这里,我们将数字 0x124 转换为指向无符号 8 位整数(或字节)的指针。这会有效地将 ptr 变量转换为从内存地址 0x124 开始的数组,我们可以像使用任何其他数组一样使用它,从而访问各个字节以进行读写。在本例中,我们将研究一张图片的 RGBA 缓冲区,并希望对其进行重新排序以实现旋转。如需移动一个像素,实际上我们需要一次移动 4 个连续字节(每个通道一个字节:R、G、B 和 A)。为简化起见,我们可以创建一个由32 位无符号整数组成的数组。按照惯例,我们的输入图片将从地址 4 开始,输出图片将在输入图片结束后直接开始:

int bpp = 4;
int imageSize = inputWidth * inputHeight * bpp;
uint32_t* inBuffer = (uint32_t*) 4;
uint32_t* outBuffer = (uint32_t*) (inBuffer + imageSize);

for (int d2 = d2Start; d2 >= 0 && d2 < d2Limit; d2 += d2Advance) {
    for (int d1 = d1Start; d1 >= 0 && d1 < d1Limit; d1 += d1Advance) {
    int in_idx = ((d1 * d1Multiplier) + (d2 * d2Multiplier));
    outBuffer[i] = inBuffer[in_idx];
    i += 1;
    }
}

将整个 JavaScript 函数移植到 C 后,我们可以使用 emcc 编译 C 文件

$ emcc -O3 -s ALLOW_MEMORY_GROWTH=1 -o c.js rotate.c

一如既往,emscripten 会生成一个名为 c.js 的粘合代码文件和一个名为 c.wasm 的 wasm 模块。请注意,经过 gzip 压缩后,wasm 模块仅会缩减到大约 260 字节,而粘合代码在经过 gzip 压缩后大约为 3.5KB。稍作调整,我们就能够摆脱粘合代码,并使用原版 API 实例化 WebAssembly 模块。通常,只要您不使用 C 标准库中的任何内容,就可以使用 Emscripten 实现此目的。

Rust

Rust 是一种新型的现代编程语言,具有丰富的类型系统、无运行时,以及可保证内存安全性和线程安全性的所有权模型。Rust 还将 WebAssembly 作为一项核心功能加以支持,Rust 团队为 WebAssembly 生态系统贡献了许多出色的工具。

其中一种工具是 rustwasm 工作组开发的 wasm-packwasm-pack 会将您的代码转换为适合 Web 的模块,该模块可与 webpack 等捆绑器开箱即用。wasm-pack 是一种极其方便的体验,但目前仅适用于 Rust。该团队正在考虑添加对其他以 WebAssembly 为目标平台的语言的支持。

在 Rust 中,切片是 C 中的数组。与在 C 语言中一样,我们需要创建使用起始地址的 slice。这违反了 Rust 强制执行的内存安全模型,因此为了实现我们的目标,我们必须使用 unsafe 关键字,以便编写不符合该模型的代码。

let imageSize = (inputWidth * inputHeight) as usize;
let inBuffer: &mut [u32];
let outBuffer: &mut [u32];
unsafe {
    inBuffer = slice::from_raw_parts_mut::<u32>(4 as *mut u32, imageSize);
    outBuffer = slice::from_raw_parts_mut::<u32>((imageSize * 4 + 4) as *mut u32, imageSize);
}

for d2 in 0..d2Limit {
    for d1 in 0..d1Limit {
    let in_idx = (d1Start + d1 * d1Advance) * d1Multiplier + (d2Start + d2 * d2Advance) * d2Multiplier;
    outBuffer[i as usize] = inBuffer[in_idx as usize];
    i += 1;
    }
}

使用以下命令编译 Rust 文件

$ wasm-pack build

会生成一个 7.6KB 的 wasm 模块,其中包含大约 100 字节的粘合代码(均在 gzip 压缩后)。

AssemblyScript

AssemblyScript 是一个相当年轻的项目,旨在成为 TypeScript 到 WebAssembly 的编译器。不过,请务必注意,它不会使用任何 TypeScript。AssemblyScript 使用与 TypeScript 相同的语法,但会将标准库替换为自己的库。其标准库为 WebAssembly 的功能建模。这意味着,您不能将任何 TypeScript 编译为 WebAssembly,但并不意味着您必须学习新的编程语言才能编写 WebAssembly!

    for (let d2 = d2Start; d2 >= 0 && d2 < d2Limit; d2 += d2Advance) {
      for (let d1 = d1Start; d1 >= 0 && d1 < d1Limit; d1 += d1Advance) {
        let in_idx = ((d1 * d1Multiplier) + (d2 * d2Multiplier));
        store<u32>(offset + i * 4 + 4, load<u32>(in_idx * 4 + 4));
        i += 1;
      }
    }

考虑到 rotate() 函数的类型接口很小,因此将此代码移植到 AssemblyScript 非常容易。AssemblyScript 提供了 load<T>(ptr: usize)store<T>(ptr: usize, value: T) 函数来访问原始内存。如需编译 AssemblyScript 文件,我们只需安装 AssemblyScript/assemblyscript npm 软件包并运行以下命令:

$ asc rotate.ts -b assemblyscript.wasm --validate -O3

AssemblyScript 将向我们提供约 300 字节的 wasm 模块,且粘合代码。 该模块仅适用于原生 WebAssembly API。

WebAssembly 取证

与其他 2 种语言相比,Rust 的 7.6KB 大小令人惊讶。WebAssembly 生态系统中有一些工具可以帮助您分析 WebAssembly 文件(无论创建时使用的是哪种语言),告诉您发生的情况,并帮助您改善状况。

Twiggy

Twiggy 是 Rust 的 WebAssembly 团队提供的另一款工具,可从 WebAssembly 模块中提取大量富有洞察力的数据。该工具并非特定于 Rust,可让您检查模块的调用图等信息,确定未使用或多余的部分,并找出哪些部分占模块的总文件大小。后者可以使用 Twiggy 的 top 命令完成:

$ twiggy top rotate_bg.wasm
Twiggy 安装屏幕截图

在本例中,我们可以看到文件大小的绝大部分都来自分配器。出乎意料的是,我们的代码没有使用动态分配。另一个主要原因是“函数名称”子部分。

wasm-strip

wasm-stripWebAssembly Binary Toolkit(简称 wabt)中的一种工具。其中包含一些工具,可用于检查和操作 WebAssembly 模块。wasm2wat 是一个反汇编器,可将二进制 Wasm 模块转换为人类可读的格式。Wabt 还包含 wat2wasm,可让您将这种人类可读的格式转换回二进制 wasm 模块。虽然我们确实使用了这两个互补工具来检查 WebAssembly 文件,但我们发现 wasm-strip 最有用。wasm-strip 会从 WebAssembly 模块中移除不必要的部分和元数据:

$ wasm-strip rotate_bg.wasm

这会将 rust 模块的文件大小从 7.5KB 缩减到 6.6KB(经过 Gzip 压缩)。

wasm-opt

wasm-optBinaryen 中的一款工具。它会接受一个 WebAssembly 模块,并尝试仅根据字节码优化其大小和性能。某些工具(例如 Emscripten)已运行此工具,但有些工具则没有。通常,最好尝试使用这些工具节省一些额外的字节。

wasm-opt -O3 -o rotate_bg_opt.wasm rotate_bg.wasm

使用 wasm-opt,我们可以再减少一些字节,使压缩后的总大小为 6.2KB。

#![no_std]

经过一些咨询和研究,我们在不使用 Rust 标准库的情况下,使用 #![no_std] 功能重写了 Rust 代码。这还会完全停用动态内存分配,从我们的模块中移除分配器代码。使用 此 Rust 文件进行编译

$ rustc --target=wasm32-unknown-unknown -C opt-level=3 -o rust.wasm rotate.rs

在执行 wasm-optwasm-strip 和 gzip 后,生成了 1.6KB 的 wasm 模块。虽然它仍然比 C 和 AssemblyScript 生成的模块大,但足够小,可以被视为轻量级模块。

性能

在仅根据文件大小就得出结论之前,请注意,我们此次改进是为了优化性能,而不是文件大小。我们如何衡量效果,以及取得了怎样的成效?

如何进行基准测试

尽管 WebAssembly 是一种低级字节码格式,但仍需要通过编译器发送,以生成特定于主机的机器码。与 JavaScript 一样,编译器的工作方式分为多个阶段。简单来说:第一阶段的编译速度要快得多,但生成的代码运行速度往往较慢。模块开始运行后,浏览器会观察哪些部分被频繁使用,并通过更优化但速度较慢的编译器发送这些部分。

我们的用例很有趣,因为用于旋转图片的代码将被使用一次,也许两次。因此,在大多数情况下,我们永远无法获得优化编译器的好处。在进行基准化分析时,请务必注意这一点。在循环中运行 WebAssembly 模块 10,000 次会产生不切实际的结果。为了得到实际数字,我们应该运行一次模块,并根据单次运行得出的数字做出决策。

效果对比

不同语言的速度比较
各浏览器的速度比较

这两个图表是对同一数据的不同视图。在第一个图表中,我们按浏览器进行比较;在第二个图表中,我们按所用语言进行比较。请注意,我选择了对数时间尺度。值得注意的是,所有基准测试都使用了相同的 1600 万像素测试图片和相同的主机,但有一款浏览器无法在同一台机器上运行。

无需过多分析这些图表,我们就可以清楚地看到,我们解决了最初的性能问题:所有 WebAssembly 模块的运行时间均在 500 毫秒左右。这证实了我们在开头所说的:WebAssembly 可为您提供可预测的性能。无论我们选择哪种语言,浏览器和语言之间的差异都很小。确切地说:所有浏览器中 JavaScript 的标准差约为 400 毫秒,而所有浏览器中所有 WebAssembly 模块的标准差约为 80 毫秒。

有效时间

另一个指标是创建 WebAssembly 模块并将其集成到 squoosh 所需的工作量。很难为“努力程度”分配一个数字值,因此我不会创建任何图表,但我想指出以下几点:

AssemblyScript 可以顺畅运行。它不仅允许您使用 TypeScript 编写 WebAssembly,让我的同事能够轻松进行代码审核,还能生成无粘合 WebAssembly 模块,这些模块非常小且性能出色。TypeScript 生态系统中的工具(如 prettier 和 tslint)可能可以正常运行。

Rust 与 wasm-pack 的结合也非常方便,但在需要绑定和内存管理的大型 WebAssembly 项目中更为出色。为了实现具有竞争力的文件大小,我们不得不稍微偏离常规路径。

C 和 Emscripten 开箱即用即可创建一个非常小且高性能的 WebAssembly 模块,但如果不敢深入研究粘合代码并将其缩减到仅包含必需内容,总大小(WebAssembly 模块 + 粘合代码)最终会非常大。

总结

因此,如果您有 JS 热路径,并且希望使其更快或更符合 WebAssembly 的规范,应该使用哪种语言?与性能问题一样,答案是:取决于具体情况。我们发布了什么?

比较图

比较我们使用的不同语言的模块大小 / 性能权衡,最佳选择似乎是 C 或 AssemblyScript。我们决定推出 Rust。做出此决定的原因有很多:Squoosh 中目前提供的所有编解码器都是使用 Emscripten 编译的。我们希望拓展对 WebAssembly 生态系统的了解,并在生产环境中使用其他语言。AssemblyScript 是一个强大的替代方案,但该项目相对较年轻,并且编译器的成熟程度不如 Rust 编译器。

虽然在散点图中,Rust 与其他语言的文件大小差异看起来非常明显,但实际上差异并不大:加载 500B 或 1.6KB 甚至超过 2G 的文件都需要不到 1/10 秒的时间。Rust 有望很快缩小模块大小方面的差距。

在运行时性能方面,Rust 在各浏览器中的平均速度比 AssemblyScript 快。尤其是在大型项目中,Rust 更有可能生成运行速度更快的代码,而无需手动进行代码优化。但这并不妨碍您选择最合适的模型。

尽管如此,AssemblyScript 还是一个了不起的发现。借助它,Web 开发者无需学习新语言即可生成 WebAssembly 模块。AssemblyScript 团队的响应非常及时,并且正在积极改进其工具链。我们一定会在未来密切关注 AssemblyScript。

更新:Rust

在本文发布后,Rust 团队的 Nick Fitzgerald 向我们推荐了他们出色的 Rust Wasm 图书,其中包含关于优化文件大小的部分。按照其中的说明操作(最值得注意的是启用链接时间优化和手动 panic 处理)后,我们就可以编写“正常”Rust 代码,并恢复使用 Cargo(Rust 的 npm),而不会增加文件大小。经过 gzip 压缩后,Rust 模块的大小为 370B。如需了解详情,请参阅我在 Squoosh 上打开的 PR

特别感谢 Ashley WilliamsSteve KlabnikNick FitzgeraldMax Graey 在此过程中提供的所有帮助。