为什么说 Wasm 是 Web 的未来?

开发 前端
大家好,我是皮汤。过去两个月,我主要在研究 WebAssembly(WASM) 相关的内容,了解到 WASM 填补了 Web 一直以来缺失的部分:媲美原生的性能。对这方面有了一点心得,分享给大家。

[[437422]]

本文转载自微信公众号「程序员巴士」,作者一只图雀。转载本文请联系程序员巴士公众号。

大家好,我是皮汤。过去两个月,我主要在研究 WebAssembly(WASM) 相关的内容,了解到 WASM 填补了 Web 一直以来缺失的部分:媲美原生的性能。对这方面有了一点心得,分享给大家。

这篇文章打算讲什么?

了解 WebAssembly 的前世今生,这一致力于让 Web 更广泛使用的伟大创造是如何在整个 Web/Node.js 的生命周期起作用的,探讨为什么 WASM 是 Web 的未来?

在整篇文章的讲解过程中,你可以了解到 WebAssembly 原生、AssemblyScript、Emscripten 编译器。

最后还对 WebAssembly 的未来进行了展望,列举了一些令人兴奋的技术的发展方向。

为什么需要 WebAssembly ?

动态语言之踵

首先先来看一下 JS 代码的执行过程:

上述是 Microsoft Edge 之前的 ChakraCore 引擎结构,目前 Microsoft Edge 的 JS 引擎已经切换为 V8 。

整体的流程就是:

  • 拿到了 JS 源代码,交给 Parser,生成 AST
  • ByteCode Compiler 将 AST 编译为字节码(ByteCode)
  • ByteCode 进入翻译器,翻译器将字节码一行一行翻译(Interpreter)为机器码(Machine Code),然后执行

但其实我们平时写的代码有很多可以优化的地方,如多次执行同一个函数,那么可以将这个函数生成的 Machine Code 标记可优化,然后打包送到 JIT Compiler(Just-In-Time),下次再执行这个函数的时候,就不需要经过 Parser-Compiler-Interpreter 这个过程,可以直接执行这份准备好的 Machine Code,大大提高的代码的执行效率。

但是上述的 JIT 优化只能针对静态类型的变量,如我们要优化的函数,它只有两个参数,每个参数的类型是确定的,而 JavaScript 却是一门动态类型的语言,这也意味着,函数在执行过程中,可能类型会动态变化,参数可能变成三个,第一个参数的类型可能从对象变为数组,这就会导致 JIT 失效,需要重新进行 Parser-Compiler-Interpreter-Execuation,而 Parser-Compiler 这两步是整个代码执行过程中最耗费时间的两步,这也是为什么 JavaScript 语言背景下,Web 无法执行一些高性能应用,如大型游戏、视频剪辑等。

静态语言优化

通过上面的说明了解到,其实 JS 执行慢的一个主要原因是因为其动态语言的特性,导致 JIT 失效,所以如果我们能够为 JS 引入静态特性,那么可以保持有效的 JIT,势必会加快 JS 的执行速度,这个时候 asm.js 出现了。

asm.js 只提供两种数据类型:

  • 32 位带符号整数
  • 64 位带符号浮点数

其他类似如字符串、布尔值或对象都是以数值的形式保存在内存中,通过 TypedArray 调用。整数和浮点数表示如下:

ArrayBuffer对象、TypedArray视图和DataView 视图是 JavaScript 操作二进制数据的一个接口,以数组的语法处理二进制数据,统称为二进制数组。参考 ArrayBuffer 。

  1. var a = 1; 
  2.  
  3. var x = a | 0; // x 是32位整数 
  4.  
  5. var y = +a; // y 是64位浮点数 

而函数的写法如下:

  1. function add(x, y) { 
  2.  
  3. x = x | 0; 
  4.  
  5. y = y | 0; 
  6.  
  7. return (x + y) | 0; 
  8.  

上述的函数参数及返回值都需要声明类型,这里都是 32 位整数。

而且 asm.js 也不提供垃圾回收机制,内存操作都是由开发者自己控制,通过 TypedArray 直接读写内存:

  1. var buffer = new ArrayBuffer(32768); // 申请 32 MB 内存 
  2. var HEAP8 = new Int8Array(buffer); // 每次读 1 个字节的视图 HEAP8 
  3. function compiledCode(ptr) { 
  4.   HEAP[ptr] = 12; 
  5.   return HEAP[ptr + 4]; 

从上可见,asm.js 是一个严格的 JavaScript 子集要求变量的类型在运行时确定且不可改变,且去除了 JavaScript 拥有的垃圾回收机制,需要开发者手动管理内存。这样 JS 引擎就可以基于 asm.js 的代码进行大量的 JIT 优化,据统计 asm.js 在浏览器里面的运行速度,大约是原生代码(机器码)的 50% 左右。

推陈出新

但是不管 asm.js 再怎么静态化,干掉一些需要耗时的上层抽象(垃圾收集等),也还是属于 JavaScript 的范畴,代码执行也需要 Parser-Compiler 这两个过程,而这两个过程也是代码执行中最耗时的。

为了极致的性能,Web 的前沿开发者们抛弃 JavaScript,创造了一门可以直接和 Machine Code 打交道的汇编语言 WebAssembly,直接干掉 Parser-Compiler,同时 WebAssembly 是一门强类型的静态语言,能够进行最大限度的 JIT 优化,使得 WebAssembly 的速度能够无限逼近 C/C++ 等原生代码。

相当于下面的过程:

无需 Parser-Compiler,直接就可以执行,同时干掉了垃圾回收机制,而且 WASM 的静态强类型语言的特性可以进行最大程度的 JIT 优化。

WebAssembly 初探

我们可以通过一张图来直观了解 WebAssembly 在 Web 中的位置:

WebAssembly(也称为 WASM),是一种可在 Web 中运行的全新语言格式,同时兼具体积小、性能高、可移植性强等特点,在底层上类似 Web 中的 JavaScript,同时也是 W3C 承认的 Web 中的第 4 门语言。

为什么说在底层上类似 JavaScript,主要有以下几个理由:

  • 和 JavaScript 在同一个层次执行:JS Engine,如 Chrome 的 V8
  • 和 JavaScript 一样可以操作各种 Web API

同时 WASM 也可以运行在 Node.js 或其他 WASM Runtime 中。

WebAssembly 文本格式

实际上 WASM 是一堆可以直接执行二进制格式,但是为了易于在文本编辑器或开发者工具里面展示,WASM 也设计了一种 “中间态” 的文本格式,以 .``wat 或 .wast 为扩展命名,然后通过 wabt 等工具,将文本格式下的 WASM 转为二进制格式的可执行代码,以 .wasm 为扩展的格式。

来看一段 WASM 文本格式下的模块代码:

  1. (module 
  2.   (func $i (import "imports" "imported_func") (param i32)) 
  3.   (func (export "exported_func"
  4.     i32.const 42 
  5.     call $i 
  6.   ) 

上述代码逻辑如下:

  • 首先定义了一个 WASM 模块,然后从一个 imports JS 模块导入了一个函数 imported_func ,将其命名为 $i ,接收参数 i32
  • 然后导出一个名为 exported_func 的函数,可以从 Web App,如 JS 中导入这个函数使用
  • 接着为参数 i32 传入 42,然后调用函数 $i

我们通过 wabt 将上述文本格式转为二进制代码:

  • 将上述代码复制到一个新建的,名为 simple.wat 的文件中保存
  • 使用 wabt 进行编译转换

当你安装好 wabt 之后,运行如下命令进行编译:

  1. wat2wasm simple.wat -o simple.wasm 

虽然转换成了二进制,但是无法在文本编辑器中查看其内容,为了查看二进制的内容,我们可以在编译时加上 -v 选项,让内容在命令行输出:

  1. wat2wasm simple.wat -v 

输出结果如下:

可以看到,WebAssembly 其实是二进制格式的代码,即使其提供了稍为易读的文本格式,也很难真正用于实际的编码,更别提开发效率了。

将 WebAssembly 作为编程语言的一种尝试

因为上述的二进制和文本格式都不适合编码,所以不适合将 WASM 作为一门可正常开发的语言。

为了突破这个限制,AssemblyScript 走到台前,AssemblyScript 是 TypeScript 的一种变体,为 JavaScript 添加了 WebAssembly 类型 , 可以使用 Binaryen 将其编译成 WebAssembly。

WebAssembly 类型大致如下:

  • i32、u32、i64、v128 等
  • 小整数类型:i8、u8 等
  • 变量整数类型:isize、usize 等

Binaryen 会前置将 AssemblyScript 静态编译成强类型的 WebAssembly 二进制,然后才会交给 JS 引擎去执行,所以说虽然 AssemblyScript 带来了一层抽象,但是实际用于生产的代码依然是 WebAssembly,保有 WebAssembly 的性能优势。AssemblyScript 被设计的和 TypeScript 非常相似,提供了一组内建的函数可以直接操作 WebAssembly 以及编译器的特性.

内建函数:

  • 静态类型检查:
    • function isInteger(value?: T): ``bool 等
  • 实用函数:
    • function sizeof(): usize 等
  • 操作 WebAssembly:
    • function select(ifTrue: T, ifFalse: T, condition: ``bool``): T 等
    • function load(ptr: usize, immOffset?: usize): T 等
    • function clz(value: T): T 等
    • 数学操作
    • 内存操作
    • 控制流
    • SIMD
    • Atomics
    • Inline instructions

然后基于这套内建的函数向上构建一套标准库。

标准库:

  • Globals
  • Array
  • ArrayBuffer
  • DataView
  • Date
  • Error
  • Map
  • Math
  • Number
  • Set
  • String
  • Symbol
  • TypedArray

如一个典型的 Array 的使用如下:

  1. var arr = new Array<string>(10) 
  2.  
  3. // arr[0]; // 会出错 😢 
  4.  
  5. // 进行初始化 
  6. for (let i = 0; i < arr.length; ++i) { 
  7.   arr[i] = "" 
  8. arr[0]; // 可以正确工作 😊 

可以看到 AssemblyScript 在为 JavaScript 添加类似 TypeScript 那样的语法,然后在使用上需要保持和 C/C++ 等静态强类型的要求,如不初始化,进行内存分配就访问就会报错。

还有一些扩展库,如 Node.js 的 process、crypto 等,JS 的 console,还有一些和内存相关的 StaticArray、heap 等。

可以看到通过上面基础的类型、内建库、标准库和扩展库,AssemblyScript 基本上构造了 JavaScript 所拥有的的全部特性,同时 AssemblyScript 提供了类似 TypeScript 的语法,在写法上严格遵循强类型静态语言的规范。

值得一提的是,因为当前 WebAssembly 的 ES 模块规范依然在草案中,AssemblyScript 自行进行了模块的实现,例如导出一个模块:

  1. // env.ts 
  2.  
  3. export declare function doSomething(foo: i32): void { /* ... 函数体 */ } 

导入一个模块:

  1. import { doSomething } from "./env"

一个大段代码、使用类的例子:

  1. class Animal<T> { 
  2.   static ONE: i32 = 1; 
  3.   static add(a: i32, b: i32): i32 { return a + b + Animal.ONE; } 
  4.  
  5.   two: i16 = 2; // 6   instanceSub<T>(a: T, b: T): T { return a - b + <T>Animal.ONE; } // tsc does not allow this } 
  6.  
  7. export function staticOne(): i32 { 
  8.   return Animal.ONE; 
  9.  
  10. export function staticAdd(a: i32, b: i32): i32 { 
  11.   return Animal.add(a, b); 
  12.  
  13. export function instanceTwo(): i32 { 
  14.   let animal = new Animal<i32>(); 
  15.   return animal.two; 
  16.  
  17. export function instanceSub(a: f32, b: f32): f32 { 
  18.   let animal = new Animal<f32>(); 
  19.   return animal.instanceSub<f32>(a, b); 

AssemblyScript 为我们打开了一扇新的大门,可以以 TS 形式的语法,遵循静态强类型的规范进行高效编码,同时又能够便捷的操作 WebAssembly/编译器相关的 API,代码写完之后,通过 Binaryen 编译器将其编译为 WASM 二进制,然后获取到 WASM 的执行性能。

得益于 AssemblyScript 兼具灵活性与性能,目前使用 AssemblyScript 构建的应用生态已经初具繁荣,目前在区块链、构建工具、编辑器、模拟器、游戏、图形编辑工具、库、IoT、测试工具等方面都有大量使用 AssemblyScript 构建的产物:https://www.assemblyscript.org/built-with-assemblyscript.html#games

上面是使用 AssemblyScript 构建的一个五子棋游戏。

一种鬼才哲学:将 C/C++ 代码跑在浏览器

虽然 AssemblyScript 的出现极大的改善了 WebAssembly 在高效率编码方面的缺陷,但是作为一门新的编程语言,其最大的劣势就是生态、开发者与积累。

WebAssembly 的设计者显然在设计上同时考虑到了各种完善的情况,既然 WebAssembly 是一种二进制格式,那么其就可以作为其他语言的编译目标,如果能够构建一种编译器,能够将已有的、成熟的、且兼具海量的开发者和强大的生态的语言编译到 WebAssembly 使用,那么相当于可以直接复用这个语言多年的积累,并用它们来完善 WebAssembly 生态,将它们运行在 Web、Node.js 中。

幸运的是,针对 C/C++ 已经有 Emscripten 这样优秀的编译器存在了。

可以通过下面这张图直观的阐述 Emscripten 在开发链路中的地位:

即将 C/C++ 的代码(或者 Rust/Go 等)编译成 WASM,然后通过 JS 胶水代码将 WASM 跑在浏览器中(或 Node.js)的 runtime,如 ffmpeg 这个使用 C 编写音视频转码工具,通过 Emscripten 编译器编译到 Web 中使用,可直接在浏览器前端转码音视频。

上述的 JS “Gule” 代码是必须的,因为如果需要将 C/C++ 编译到 WASM,还能在浏览器中执行,就得实现映射到 C/C++ 相关操作的 Web API,这样才能保证执行有效,这些胶水代码目前包含一些比较流行的 C/C++ 库,如 SDL、OpenGL、OpenAL、以及 POSIX 的一部分 API。

目前使用 WebAssembly 最大的场景也是这种将 C/C++ 模块编译到 WASM 的方式,比较有名的例子有 Unreal Engine 4、Unity 之类的大型库或应用。

WebAssembly 会取代 JavaScript 吗?

答案是不会。

根据上面的层层阐述,实际上 WASM 的设计初衷就可以梳理为以下几点:

  • 最大程度的复用现有的底层语言生态,如 C/C++ 在游戏开发、编译器设计等方面的积淀
  • 在 Web、Node.js 或其他 WASM runtime 获得近乎于原生的性能,也就是可以让浏览器也能跑大型游戏、图像剪辑等应用
  • 还有最大程度的兼容 Web、保证安全
  • 同时在开发上(如果需要开发)易于读写和可调试,这一点 AssemblyScript 走得更远

所以从初衷出发,WebAssembly 的作用更适合下面这张图:

WASM 桥接各种系统编程语言的生态,近一步补齐了 Web 开发生态之外,还为 JS 提供性能的补充,正是 Web 发展至今所缺失的重要的一块版图。

Rust Web Framework:https://github.com/yewstack/yew

深入探索 Emscripten

地址:https://github.com/emscripten-core/emscripten

下面所有的 demo 都可以在仓库:https://code.byted.org/huangwei.fps/webassembly-demos/tree/master 找到

Star:21.4K

维护:活跃

Emscripten 是一个开源的,跨平台的,用于将 C/C++ 编译为 WebAssembly 的编译器工具链,由 LLVM、Binaryen、Closure Compiler 和其他工具等组成。

Emscripten 的核心工具为 Emscripten Compiler Frontend(emcc),emcc 是用于替代一些原生的编译器如 gcc 或 clang,对 C/C++ 代码进行编译。

实际上为了能让几乎所有的可移植的 C/C++ 代码库能够编译为 WebAssembly,并在 Web 或 Node.js 执行,Emscripten Runtime 其实还提供了兼容 C/C++ 标准库、相关 API 到 Web/Node.js API 的映射,这份映射存在于编译之后的 JS 胶水代码中。

再看下面这张图,红色部分为 Emscripten 编译后的产物,绿色部分为 Emscripten 为保证 C/C++ 代码能够运行的一些 runtime 支持:

简单体验一下 “Hello World”

值得一提的是,WebAssembly 相关工具链的安装几乎都是以源码的形式提供,这可能和 C/C++ 生态的习惯不无关系。

为了完成简单的 C/C++ 程序运行在 Web,我们首先需要安装 Emscripten 的 SDK:

  1. # Clone 代码仓库 
  2. git clone https: // github . com / emscripten-core / emsdk . git 
  3.  
  4. # 进入仓库 
  5. cd emsdk 
  6.  
  7. # 获取最新代码,如果是新 clone 的这一步可以不需要 
  8. git pull 
  9.  
  10. # 安装 SDK 工具,我们安装 1.39.18,方便测试 
  11. ./emsdk install 1.39.18 
  12.  
  13. # 激活 SDK 
  14. ./emsdk activate 1.39.18 
  15.  
  16. # 将相应的环境变量加入到系统 PATH 
  17. source ./emsdk_env.sh 
  18.  
  19. # 运行命令测试是否安装成功 
  20. emcc -v # 

如果安装成功,上述的命令运行之后会输出如下结果:

  1. emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 1.39.18 
  2. clang version 11.0.0 (/b/s/w/ir/cache/git/chromium.googlesource.com-external-github.com-llvm-llvm--project 613c4a87ba9bb39d1927402f4dd4c1ef1f9a02f7) 
  3. Target: x86_64-apple-darwin21.1.0 
  4. Thread model: posix 

让我们准备初始代码:

  1. mkdir -r webassembly/hello_world 
  2. cd webassembly/hello_world && touch main.c 

在 main.c 中加入如下代码:

  1.  #include <stdio.h> 
  2. int main() { 
  3.   printf("hello, world!\n"); 
  4.   return 0; 

然后使用 emcc 来编译这段 C 代码,在命令行切换到 webassembly/hello_world 目录,运行:

  1. emcc main.c 

上述命令会输出两个文件:a.out.js 和 a.out.wasm ,后者为编译之后的 wasm 代码,前者为 JS 胶水代码,提供了 WASM 运行的 runtime。

可以使用 Node.js 进行快速测试:

  1. node a.out.js 

会输出 "hello, world!" ,我们成功将 C/C++ 代码运行在了 Node.js 环境。

接下来我们尝试一下将代码运行在 Web 环境,修改编译代码如下:

  1. emcc main.c -o main.html 

上述命令会生成三个文件:

  • main.js 胶水代码
  • main.wasm WASM 代码
  • main.html 加载胶水代码,执行 WASM 的一些逻辑

Emscripten 生成代码有一定的规则,具体可以参考:https://emscripten.org/docs/compiling/Building-Projects.html#emscripten-linker-output-files

如果要在浏览器打开这个 HTML,需要在本地起一个服务器,因为单纯的打开通过 file:// 协议访问时,主流浏览器不支持 XHR 请求,只有在 HTTP 服务器下,才能进行 XHR 请求,所以我们运行如下命令来打开网站:

  1. npx serve . 

打开网页,访问 localhost:3000/main.html,可以看到如下结果:

同时开发者工具里面也会有相应的打印输出:

我们成功的将 C 代码跑在了 Node.js 和浏览器!

责任编辑:武晓燕 来源: 程序员巴士
相关推荐

2020-07-03 14:05:26

Serverless云服务商

2023-05-04 07:44:13

编程界小语言Java

2023-03-21 10:16:36

2023-05-17 16:37:29

2023-07-19 08:00:00

Raft分布式系统

2012-02-08 10:02:53

Web

2016-04-28 09:29:35

ZD至顶网网络频道

2020-04-07 18:56:41

区块链网络安全物联网

2022-10-08 06:38:01

元宇宙NFT加密货币

2021-04-07 06:58:32

边缘计算计算云计算

2020-11-02 17:21:07

云计算

2020-12-30 19:19:35

ARM架构X86架构芯片

2022-03-14 08:33:09

TypeScriptJavaScript前端

2018-08-17 09:00:00

2018-11-27 06:25:35

AIoT物联网人工智能

2020-09-21 10:16:44

智能

2023-11-20 22:26:51

Go开发

2019-09-23 13:37:09

Anthos谷歌Kubernetes

2011-10-27 13:37:51

网页设计

2023-05-05 16:26:33

点赞
收藏

51CTO技术栈公众号