V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Micropaper
V2EX  ›  程序员

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

  •  
  •   Micropaper ·
    unbug · 2023-02-07 10:15:39 +08:00 · 2866 次点击
    这是一个创建于 416 天前的主题,其中的信息可能已经有所发展或是发生改变。

    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 运行时,支持使用 WASI 编译的 WebAssembly 二进制代码。
    • 运行时足够成熟,可以运行广泛的 WebAssembly 应用程序。
    • 运行时随着 WebAssembly 和 WASI 的发展而积极开发和维护。

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

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

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

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

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

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

    单拎出来目前来说目前没有太大意义(不管是是独立还是依托浏览器)。
    mcfog
        7
    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
        8
    Micropaper  
    OP
       2023-02-07 16:41:33 +08:00
    @mcfog 之前看了个论文写了 IoT 的应用场景,效果很好,我有时间下次分享个,欢迎关注。
    fakeshadow
        9
    fakeshadow  
       2023-02-07 18:05:52 +08:00
    标准进度缓慢,社区分裂严重。wasi 还有很长的路要走。
    Smilecc
        10
    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 ),我认为还是有一定选择的余地的。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   2945 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 29ms · UTC 11:08 · PVG 19:08 · LAX 04:08 · JFK 07:08
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.