webassemblyphp技巧_WebAssembly 2023 年回忆与 2024 年瞻望 年度技能盘点与瞻望

策划 | 蔡芳芳

在刚刚过去的 2023 年，WebAssembly 技能发展态势喜人，多项关键性发起都进入了新阶段，并且得到了社区与工具链的广泛深入支持。
同时，其运用处景呈现出发达扩展的态势，吸引着越来越多组织和个人开拓者群体投入 WebAssembly 的开拓之中。
下文我们将首先回溯 WebAssembly 在 2023 年各项关键技能特性的进展，继而前瞻磋商新的一年它有望展现的发展趋势和前景。
本文是 “2023 InfoQ 年度技能盘点与展望” 系列文章之一，由 InfoQ 编辑部制作呈现。

WebAssembly GC （Garbage Collection，垃圾回收） 特性引入的目的之一是为了更加高效地支持一些须要垃圾回收处理的高等措辞，比如 TypeScript、Java、Kotlin、Python、PHP 和 C# 等。

在没有引入 WebAssembly GC 特性之前，如果要将这些措辞移植到 WebAssembly，一样平常的做法是将相应措辞的虚拟机（如 JavaScript runtime、Python runtime 等）以及目标 app 一起编译成 WebAssembly 目标代码，由 wasm runtime 来实行该措辞的虚拟机，然后再由该虚拟机来实行目标 app。
由于这种办法不随意马虎将目标 app 转成机器码以 AOT（Ahead of Time Compilation）或 JIT（Just in Time Compilation）办法来实行，虚拟机一样平常只能以阐明器的办法实行目标 app，以是性能受到很大的限定。
另一方面，将虚拟机编译到 wasm 目标代码，也可能大大增加目标代码的体积。

引入了 WebAssembly GC 特性之后，人们可以开拓出新的编译器，将某种高等措辞的 app 直接编译成基于 WebAssembly GC 操作的目标代码，不须要将虚拟机一起编译进来。
这样一方面孔标 app 可以用 AOT 或 JIT 办法来实行，另一方面基于 GC opcode 的操作也非常高效（比如对构造成员的访问、对数组元素的访问等），因此可以极大提升性能，并减少目标代码体积。

WebAssembly GC 依赖于 Reference Types 和 Typed Function References （或简称 Func Ref） 两个特性，在基本数据类型 （i32、 i64、 f32、 f64 和 v128） 的根本上引入了多种和引用干系的数据类型，包括 structref、 arrayref、 i31ref、 funcref、 externref 等，规定了类型之间的继续和等价关系，并且引入很多新的 opcode 来操作这些数据类型，从而知足多种高等措辞的需求。
个中 Reference Types 已经在 2021 年正式写入规范，而 GC MVP 发起和 Func Ref 发起在 2023 年也得到了较大的发展，在经由了大量谈论和修正后趋于完善和稳定，目前都进入了阶段四即标准化阶段。

其余开源项目 WAMR （wasm-micro-runtime）、v8、Kotlin 以及开源编译框架 Binaryen 等都在持续跟进支持 GC 特性。
WAMR 已经基本实现了 interpreter、AOT 以及 LLVM JIT 几种实行模式对绝大部分 GC MVP 特性的支持（注：开拓分支），并被运用到了开源 Wasmnizer-ts 项目上面，后者旨在将 TypeScript 措辞编译成基于 WebAssembly GC 的目标代码，以提升性能、减少模块尺寸并方便移植到各个架构，有兴趣可以参考 https://github.com/web-devkits/Wasmnizer-ts。

Hierarchy of abstract wasm GC heap types

Basic idea of Wasmnizer-ts compiler

Func Ref 许可把 wasm 函数作为一个工具来引用，并传入函数参数来调用该引用指向的函数，例如通过 ref.func opcode 来创建一个函数引用然后利用 call_ref opcode 来调用该函数。
这样可以更灵巧地支持动态函数调用，比较之前的 call_indirect opcode 通过 wasm table 来间接的调用函数的办法，可以减少较多的运行时检讨以提升性能。
其余通过函数引用也方便实现有些高等措辞特性，比如闭包（Closure）。

Reference-Typed Strings （或简称 String Ref） 则旨在改进 WebAssembly 中对字符串的处理办法。
在该发起涌现前，每个措辞的编译器须要自己设计 string 在 WebAssembly 中的表达办法、编码处理等。
这种办法导致天生的 wasm 模块中有大量的逻辑用来处理 string，进而增大模块体积。
另一方面，WebAssembly 每每运行在一个特定的宿主环境中，在 WebAssembly 中实现的 string 可能无法被宿主环境直策应用，因此在宿主和 wasm 之间进行 string 通报时每每涉及到内存拷贝，影响性能。

String Ref 发起引入了一种新的引用类型，直接将宿主环境的 string 以引用的形式供应给 WebAssembly，并通过一系列 opcode 来进行操作。
这一发起使得编译器无需再设计自己的 string 表达办法，同时避免了大量用于处理编码的 opcode，在降落编译器实现繁芜度的同时，也减小了天生的 wasm 模块体积。
同时，WebAssembly 和宿主直接通报 string 时无需拷贝，也提升了性能。
虽然该发起还处在阶段一，但很快引起关注，目前 v8 、WAMR 和 Binaryen 都已经支持。

wasi-threads 是 WebAssembly 系统接口 （WebAssembly System Interface，WASI） 的一个扩展发起，它的目的是在 WASI 环境中引入对多线程的支持，使得 WebAssembly 运用程序能够创建、同步和管理多个线程。
它供应了一个标准化的 API 来创建线程：status wasi_thread_spawn（thread_start_arg start_arg），该 API 哀求 wasm runtime 实现对应的名为“thread-spawn”的 WASI 接口来创建线程，并准备好干系高下文，在新创建的线程中实现对 wasm app 函数的回调。
其余它也在 WebAssembly threads 发起的一些原语根本上实现了对互斥锁 （mutex）、条件变量等的支持，以便折衷和同步多个线程的实行。
基于此，该发起实现了对 pthreads 大部分 API 的支持，目前工具链 wasi-sdk 已经基本实现了上述支持，并发布了 wasi-threads 的二进制包。
而开源社区 wasmtime 和 WAMR 也分别实现了该发起，有兴趣可以参考 https://bytecodealliance.github.io/wamr.dev/blog/introduction-to-wamr-wasi-threads。

Memory model of WAMR wasi-threads

WebAssembly 的内存模型是基于线性内存的，目前 MVP 版本（最小可行版本）中线性内存只支持 Memory32，其地址范围是 32 位，即一个线性内存最多有 65536 （=216 ）个 page，而每个 page 有 65536 （=216） 个字节，以是最多可以有 232 = 4G 个字节。
这对付许多运用如 Web 运用和嵌入式系统来说是足够的，但对付某些事情负载，特殊是须要大量内存的运用程序，如云打算、人工智能、虚拟化和容器等，可能不足。
因此 Memory64 发起被提出，以支持 64 位地址范围，而相应的和线性内存访问干系的规范或发起也被扩展，包括基本的 memory 操作、Bulk Memory 规范、Shared Memory 的 atomic 内存操作、SIMD-128 规范中有关内存的操作等。

目前 Memory64 已经进入到了阶段三即实现阶段，wasm runtime 方面 v8、wasmtime、wasmer 和 wasm2c 等均已经供应支持，工具链方面 LLVM、Emscripten 和 Binaryen 也供应了支持。
而 wasi-sdk 所依赖的根本库 wasi-libc 也有开拓者提交了支持 Memory64 的 patch，期待在不久的将来 Memory64 可以在 wasi-sdk 中得到支持。

Multi-Memories 发起则意在支持在一个 wasm 模块中利用多个线性内存，这样做可以提高隔离和安全性，供应更灵巧的内存管理，并且方便多模块之间共享数据，比如模块将私有数据存在一个内存实例，而须要和其它模块共享的数据则存在另一个内存实例。
目前该发起已经进入阶段四即标准化阶段，v8 和 Binaryen 已经支持。

Memory Control 发起则希望可以减少 native 和 wasm 模块以及 wasm 模块之间的内存拷贝，并供应基于 host mmap 的内存映射和访问掌握办法，比如在对内存初始化后将它设置成只读模式。
它提出了 memory.map 和 memory.protect 等 opcode，可选方案之一是将 host 内存映射成一个 wasm 的内存引用，然后许可将该引用的句柄在共享的 heap 中通报到另一个 wasm 模块，这样目标模块可以通过该引用句柄来访问对应的内存，从而实现零拷贝数据通报。
虽然该发起在 2022 年初就停滞了更新，但是目前引起了较多兴趣，有不少谈论希望能连续推进该发起。

Possible memory data sharing based on memory control proposal

Component Model（组件模型） 是一个在多措辞环境下实现多个 wasm 模块相互协作的发起，它引入了一套抽象类型办理多措辞的类型差异，并用序列化 / 反序列化来办理抽象类型到 wasm 基本类型的过渡。
该发起目前得到了社区的广泛支持，在 2023 年取得了显著的进展，支持发起的 wasm runtime 数量在增长，基于 Component model 抽象类型重制的 WASI-preview2 正式上线。
工具链方面，Wasm-tools 完成对发起的支持。

Component model shared everything dynamic linking sample

这里所说的 Dynamic Linking 是指最早由 Emscripten 提出的动态链接模型，用来将 C/C++ 运用程序的源代码划分成几个部分进行编译，并在实行时将它们链接在一起。
相对 Component Model 而言，Core Module 进行链接的模块是 WebAssembly 模块，而不是对 WebAssembly 模块进行了封装的组件 （Component）。
这种动态链接办法相对大略，目前在 llvm-17.0 中已经支持，而最新的 wasi-sdk release 版本也供应了支持。
Emscripten 规定编译器可以编译出两类的共享模块：Main modules（主模块）和 Side modules（暂称为副模块）。
个中只有主模块可以把系统库（如 libc）一起链接进来，并且一个项目中有且只有一个主模块，主模块的一些 symbol 如函数可能依赖于副模块，它们在实行时当副模块被加载后被进行链接。
同时主模块有自己的线性内存和 wasm table，而副模块则没有自己的线性内存和 wasm table，副模块共享主模块的线性内存和 wasm table，并且须要从主模块的线性内存和 wasm table 中预留一部分空间来存储自己的数据。
通过这种办法，可以实现主模块和副模块之间的数据共享。

而如何在主模块的线性内存以及 wasm table 中预留出部分空间给副模块，以及对副模块的链接机遇，是在主模块加载时链接（Load-time dynamic linking），还是在主模块实行时加载（Runtime dynamic linking），可能是 wasm runtime 实现时须要考虑的问题。
从目前来看，除了浏览器之外，彷佛还没有 standalone runtime 实现了该技能。
相对付组件模型，这种链接办法可以实现模块间零拷贝数据通报以提升性能，并且内存花费较小，实现也相比拟较随意马虎，缺陷是多措辞支持较差，目前来看彷佛只能支持 C/C++/Rust 等利用 clang 来编译的措辞。

Possible linking between Main module and Side module

wasi-nn 是 WebAssembly 系统接口 （WebAssembly System Interface、 WASI） 的另一个扩展，紧张用于支持深度学习硬件加速。
它被提出的缘故原由之一是由于机器学习框架（例如 Tensorflow）不随意马虎被移植到 WebAssembly SIMD 并且较好地支持一些硬件特性来担保性能。
它紧张针对机器学习运用处景，许可在 wasm 模块中访问 host 供应的机器学习功能，可以用于模型演习和推理，适用场景包括自然措辞处理、图像识别、语音识别等领域。
其支持多种深度学习模型框架，个中包括 TensorFlow 和 OpenVINO 等业界主流框架；其目标实行环境涵盖了从中心处理器（CPU）、图形处理器（GPU）到专为机器学习设计的张量处理单元（TPU）等多种打算硬件架构。
目前 WAMR、wasmtime 和 WasmEdge 都对 wasi-nn 供应了支持，个中 WAMR 紧张支持 Tensorflow 模型，而 wasmtime 和 WasmEdge 紧张支持 OpenVINO 模型。
有兴趣可以参考 https://github.com/bytecodealliance/wasm-micro-runtime/tree/main/core/iwasm/libraries/wasi-nn。

Simple working flow of wasi-nn

WebAssembly Exception Handling（非常处理）发起旨在为 WebAssembly 添加类似 Java 或 C++ 中非常处理的机制，使开拓者能够更好地管理和处理程序实行过程中的缺点情形。
该发起引入了“tag” 的观点，利用 tag 来标识非常类型，当抛出一个非常时，会附带一个 tag 来见告调用者非常的类型，然后调用者可以在 catch 语句中根据 tag 来决定如何处理非常。
目前该发起已经进入到阶段三即实现阶段，v8、Firefox 和 wasm2c 都已经支持，WAMR 在 classic interpreter 模式下也供应了支持（注: 开拓分支），工具链方面 LLVM、 Emscripten 和 Binaryen 也都已经支持。

目前 GC、Func Ref、Multi-memories、Threads 和 Tail call 等发起都已经进入到了阶段四，随着发起的进一步完善和稳定，有望在新的一年里正式写入规范。
而基于这些发起之上的运用，也将得到更加广泛的发展，比如基于 GC 发起的 Wasmnizer-ts 和 Kotlin、基于 Threads 发起的 wasi-threads 发起及干系的运用等。

关于 wasm 模块与本机环境（Native）之间、wasm 模块之间的数据共享问题，一贯是社区广泛谈论的议题。
业界普遍期待能够办理模块之间零拷贝数据通报的问题，籍此提升性能表现。
随着一系列创新方案的提出以及工具链的不断完善，这一寻衅有望得到更为有效的办理。

另一方面，针对 wasm 模块之间的链接与代码共享难题，随着 Component Model 和 Core Module Dynamic Linking 的发展，更多的 wasm runtime 正在逐步实现对模块间链接与代码共享的支持，这将进一步推动 WebAssembly 生态系统的高效整合。

目前 WebAssembly 已经被广泛运用到各个领域中，比如 Web 运用，图像处理、IoT、人工智能、边缘打算、区块链等等。
随着 wasm 技能进一步成熟和工具链生态进一步发展，其在更多专业领域和场景的潜力将得以开释。
展望未来，我们预期 wasm 将在汽车、云原生、PLC、Snapshot 迁移等场景得到采取。

WebAssembly 发展面临的紧张问题之一是工具支持，这可能影响了一些用户体验。
估量在新的一年里会有更多更友好的工具涌现，比如 AOT/JIT 调试工具、多线程调试支持、性能监测工具、内存监测工具等。

总之，在过去一年里，WebAssembly 多项提案得到了显著的演进与发展，诸多前沿特性和功能逐步得到了各个 WebAssembly 运行时与工具链的广泛支持。
同时，我们也目睹了越来越多的运用处景和实际案例呈现出来，充分展示了 WebAssembly 技能的潜力与代价。

展望新的一年，我们期待 WebAssembly 能够在技能成熟度及实用性层面实现更为坚实而有力的打破，更好地为干系的行业、组织以及开拓职员做事。

作者先容：

黄文勇, Intel Web Platform Engineering 软件工程师, Wasm Micro Runtime 项目 Technical Leader何良, Intel Web Platform Engineering 软件工程师, Wasm Micro Runtime 项目紧张贡献者徐君, Intel Web Platform Engineering 软件工程师, Wasm Micro Runtime 项目紧张贡献者

Wasm Micro Runtime (WAMR) 是一个运行在浏览器之外的 Standalone WebAssembly 虚拟机，支持 Interpreter、AOT、JIT 等多种实行模式，支持多种 OS 和多种 CPU 架构，具有高性能、低内存花费、功能高度可配置等特性，适用于从嵌入式、物联网、边缘打算到可信实行环境、智能合约、云原生等各种运用。
参考 https://github.com/bytecodealliance/wasm-micro-runtime。

如果你以为本文对你有帮助，或者你对 WebAssembly 未来发展有自己的思考，欢迎在文末留言见告我们！

原文链接：https://www.infoq.cn/article/5Zrq507bQW6lial5iVy1