WebAssembly 为 32 位和 64 位

Question

emscripten 发出的 webAssembly 是 32 位的，也可以是 64 位的。 emscripten 的目标设备是浏览器。为什么它甚至依赖于 32 位、64 位架构，因为浏览器与操作系统（与 CPU 交互）交互。为什么我们需要 32 位 64 位？

解释一下

Answer 1

wasm64 二进制文件通常应该在 32 位浏览器上运行良好。 当然，您不会请求更大的内存，就像您无法创建大于 2^32 的 JavaScript ArrayBuffer 一样。

Answer 2

emscripten 的目标设备是浏览器。

目标是 WASM“运行时”，它要么解释字节码，要么进行 JIT 编译以将其转换为 CPU 指令。

当浏览器与操作系统交互时（操作系统与CPU交互） 浏览器与操作系统交互以显示窗口和请求内存，...但它也直接与 CPU 和其他硬件交互。

为什么它甚至依赖于32位、64位架构

为了提高性能，字节码不会被解释，而是针对正在运行的 CPU 进行 JIT 编译。因此，一般来说，为 32 位环境生成的字节码可以在 64 位系统上正常运行。为 64 位生成的字节码也可能在 32 位系统上运行，但性能可能会很差。

WASM 是一种可以在任何架构上运行的字节码表示形式。

便携性：

WebAssembly 的二进制格式设计为可在各种 [...] 指令集架构上高效执行。

执行环境尽管有限、本地、不确定，但不提供以下特征，但仍然可以执行 WebAssembly 模块。在某些情况下，它们“可能必须模拟主机硬件或操作系统不提供的行为”，以便 WebAssembly 模块执行时就像支持该行为一样。

这有时会导致性能不佳。

为什么有 wasm32 和 wasm64，而不是仅仅使用 8 个字节来存储指针？

大量应用程序不需要多达 4 GiB 的内存。强制所有这些应用程序为它们存储的每个指针使用 8 个字节将显着增加它们所需的内存量，并降低它们对重要硬件资源（例如缓存和内存带宽）的有效利用率。 这里的动机和性能影响应该与那些推动 Linux 的 x32 ABI 开发的动机和性能效果基本相同。