一分钟读论文:《我们走了多远——WebAssembly 运行时的全面特征研究》

2023-02-07 10:15:39 +08:00
 Micropaper

WebAssembly ⼆进制⽂件依赖 Web 浏览器的 JavaScript 引擎来执⾏,需要独⽴的 WebAssembly 运⾏时才能在⾮ Web 浏览器中运⾏ WebAssembly 代码。美国佐治亚大学的论文[《 How Far We’ve Come – A Characterization Study of Standalone WebAssembly Runtimes 》][paper1-url]构建了一个标准的 WABench 的基准套件,对独立的 WebAssembly 运行时进行了全面的表征研究,包含性能、内存开销和架构特征。分析了33 个独⽴ WebAssembly 运⾏时的 TOP5 ,发现这些独立运⾏时在运⾏ WebAssembly ⼆进制⽂件时平均会降低 1.59 到 9.57 倍的性能

通常有两种执行 WebAssembly 代码的方法:解释型和 JIT ( SinglePass, Cranelift, LLVM )。WebAssembly 独立运行时的标准:

论文研究了符合以上标准的 WebAssembly 独立运行时 TOP5:Wasmtime ( Rust ,JIT )、WAVM ( C/C++,JIT )、Wasmer ( Rust ,JIT )、Wasm3 ( C ,解释型)、WAMR (C, 解释型)

阅读全文一分钟读论文:《我们走了多远——WebAssembly 运行时的全面特征研究》

2944 次点击
所在节点    程序员
10 条回复
tool2d
2023-02-07 10:34:51 +08:00
这文章有点意思,支持一下。wasm 最大的用途,并不是网页开发,根本就打不过传统的 JS/TS 框架。而是利用规范化的虚拟机,把繁杂的业务代码统一起来运行。

业务代码随时会变,随时会改,那么 wasm 的解释器很有用。
业务代码需要高性能,那么 wasm 的 jit 很有用。
业务代码会用不同的语言编写,那么 wasm 编译器很有用。

总是 wasm 用的好,就是新一代写业务代码的杀手锏。
fengjianxinghun
2023-02-07 10:59:11 +08:00
已经用起来了。
用在 Rust 插件上,选的 wasmtime = { version = "4.0", optional = true}
fengjianxinghun
2023-02-07 11:00:07 +08:00
@fengjianxinghun 好处是 wasm 插件可以用任意语言写,比如直接继续用 rust 写
zhlxsh
2023-02-07 11:06:41 +08:00
一楼二楼说的都挺好的,拓展一下,WebAssembly 会是未来吗?

建议建一个 WebAssembly 节点
superares
2023-02-07 12:02:44 +08:00
flyqie
2023-02-07 13:01:36 +08:00
wasm 的应用场景是在浏览器端与 js/ts 配合完成业务需求。

单拎出来目前来说目前没有太大意义(不管是是独立还是依托浏览器)。
mcfog
2023-02-07 15:34:37 +08:00
近几年有好几次想用,研究以后的结论都差不多,wasm 社区心不齐很多波不同的人各搞各的,看不到未来

客户端性能优势完全错过窗口期 99%的场景性价比不如让千锤百炼的 JS 硬跑 JIT ;服务端 wasi 空有几个 runtime ,没几种语言支持实际写 wasi 模块,还和 AssemblyScript 闹掰了

希望干脆点客户端服务端分家算了,各玩各的可能反而发展迭代更快,客户端研究研究 app 之类的场景能不能拓展,想办法和 js/ts 互操作性更强一些;服务端看看 wasi 到底行不行,早点达成一致,不行赶紧来个替代者,后面 gc 什么的早点弄出来,语言(真正意义上)多支持几种,Docker ,IOT 这些场景落地落好
Micropaper
2023-02-07 16:41:33 +08:00
@mcfog 之前看了个论文写了 IoT 的应用场景,效果很好,我有时间下次分享个,欢迎关注。
fakeshadow
2023-02-07 18:05:52 +08:00
标准进度缓慢,社区分裂严重。wasi 还有很长的路要走。
Smilecc
2023-02-07 18:50:47 +08:00
@mcfog GC 是不可能的,读过 wasm 标准就知道,wasm 连数据类型尚且都只有 3 种( number 、ref 、vector ),连没有原生 string 都没有,更别说什么 gc 了,wasm 的定位并不是 VM ,而是跨平台的汇编语言。

实际上 wasm 和 wasi 从显示角度上来说我认为分家还是比较彻底的,不然 as 也不会和 wasi 决裂,wasi 程序是很难跑在 wasm 环境下的,反之也是如此。

语言层面上面也说了,wasm/wasi 的定位并不是 VM ,所以我认为对于多语言的支持分为解释型语言( Python 、php 等)和基于 VM 的编译型语言( Java )。

对于前者解释型语言很好处理,只要把解释器编译成 wasm 或 wasi 即可,例如 RustPython 做的就很好,CPython 也有了进展,但还是实验性的。

但对于 Java 这种语言来说,本身把 Java 编译成 wasi 是没有意义的,因为 Java 本身的定位就是 write once run everywhere ,Java 虽然也能支持 AOT 编译,但是 Java 框架大量使用反射,并且在 Java 生态这么做的人实在是太少了,所以我认为把 Java 编译成 wasi 现实是不行的,但如果把 JVM 编译到 wasi 又太过于愚蠢。

C#和 Java 类似,官方具有本身有.NET Native 特性,而且微软积极拥抱 WASM ,Blazor 使用了大量的 WASM ,我还没有太深入研究,我觉得未来肯定是可以编译到 WASI 的。

所以现在 wasi 生态可以用语言:C/C++、Python ( RustPython )、Rust 、Go ( TinyGo ),我认为还是有一定选择的余地的。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/913823

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX