写前端的很好奇， WASM 是怎么做到同时在 ARM 和 x86 CPU 上运行的？如果是转译，性能损耗有多少？ Google 一直没搜到答案。

[edis0n0]

[xieqiqiang00]

直接就写在百科里，“WebAssembly 的设计与实现原则，包含：定义一个可移植，具有大小与加载高效率的二进制格式，作为编译标的。这个编译标的必须可以被编译至常见的平台，包含移动端与物联网，并且可以善用硬件资源、有原生执行码的执行速度。”

[edis0n0]

@xieqiqiang00 编译标的必须可以被编译至常见的平台 所以是编译成 x86 还是 ARM 的文件？

[xieqiqiang00]

@edis0n0 “可以被编译至常见的平台”，啥也不是

[zhouyg]

wasm 本身也是一个中间产物，arm 和 x86 在执行的时候用的也是自己平台上实现的 runtime 来执行

[wxf666]

我目前觉得 wasm 效率比本地原生差很多

我是在使用 squoosh （一个浏览器端图片转码工具）时感受到的

特别是里面的 avif 转码，我拿本地的 avifenc 比了一下。相同照片和参数，浏览器 wasm 实现的耗时，是本地 avifenc 实现的 5~6 倍

[DianQK]

一个不怎么准确的理解方式：Wasm 和 JavaScript 一样，都是用一个解释器（虚拟机）去执行代码，在这一层抹除了底层架构的差异。而二者的差异的话，比如 JavaScript （浏览器上）都是从 js 文件本身的解析开始，Wasm 将不同语言编写的代码编译到 Wasm 字节码。Wasm 详细介绍可以看看 WebAssembly 原理与核心技术。

[someonedeng]

> 计算机科学领域的任何问题都可以通过增加一个简介的中间层来解决。

大概也是有类似的 runtime 吧

[iikebug]

@wxf666 可能本地转码有其他优化手段呗，wasm 用不了或者没编译，不能简单这样比较性能的

[icexin]

一般是通过 jit 编译到机器码的，具体实现上可以有不经过优化的一遍翻译，也可以有多遍的优化编译。可以参考一下 v8 的 https://v8.dev/blog/liftoff

[RobberPhex]

jvm 及其字节码，刚开始大家也觉得性能有问题。
后来也不流行起来了？
主要是 wasm 还没有足够大的场景

[nothingistrue]

@RobberPhex #10 JVM 的性能可不是靠流行解决的，是随着 JIT 的发展才跟上性能的。但这也就仅限非桌面端，桌面端知道 Eclipse SDT 这些放弃跨平台的组件起来后才跟上来。

[andyskaura]

https://github.com/bytecodealliance/wasmtime/releases WASM 运行时

[nothingistrue]

https://developer.mozilla.org/zh-CN/docs/WebAssembly/Concepts

这里对概念性的东西说得很清楚。这玩意不就是一个安全版的 ActiveX 吗。这样同时在 ARM 和 x86 CPU 运行就跟 Web 或 Javascript 无关了，那是 C/C++ 、Rust 、以及汇编该干的事。从他有文本格式，以及总是标明他是低阶语言来推测，最终运行时很有可能就是汇编语言。这样性能损耗基本是没有的，他说接近原生都是太谦虚了。至于汇编语言的跨平台性这一块，请注意概念里没说跨平台，而是可移植，这就很好操作的，最典型的就是 C++ 那种一份代码多平台编译。实际是怎样就不好说了，WebAssembly 毕竟还是试验性的。