关于webassembly:通用WebAssembly运行时Wasmer-10-GA

Wasmer 是第一个可能在服务器端运行 Nginx 的 WebAssembly(Wasm)运行时。

利用 Wasm 进行软件容器化，咱们创立了通用二进制文件，无需批改即可在任何中央运行，包含 Linux，macOS，Windows 以及 Web 浏览器等操作系统。Wasm 默认状况下会主动沙盒化应用程序以平安执行，从而爱护主机环境免受运行中软件中的恶意代码，谬误和破绽的侵害。Wasm 还提供了一个精益执行环境，使 Wasmer 容器能够在 Docker 容器过重而无奈工作的中央运行。置信 WebAssembly 将是将来软件运行和容器化的要害组件。

通过两年多的开发，Wasmer 1.0 GA，包含如下 Future:

生产就绪性能
可插拔基础架构
原生对象引擎
Headless Wasmer — 物联网的现实抉择
穿插编译
超级易用且可扩大的 API
Wasm-C-API 反对
错误处理和调试

接下来咱们深度论述一下各个 Future！

Wasmer 1.0 性能基准测试须要独立公布。将 Wasmer 与其余 Wasm 运行时进行残缺的剖析，以便您比拟并抉择最适宜您的我的项目的技术！

当初，咱们所有的编译器都能够并行编译函数。借助这一新策略，咱们在所有编译器中的编译速度均进步了 9 倍。

通过理论示例比拟，这些数字更容易了解。在这里，咱们能够看到 Wasmer 0.17.1 与 Wasmer 1.0 中 clang.wasm 的编译工夫：

Singlepass: from 18s to 2s (9x speedup)
Cranelift: from 27s to 9s (3x speedup)
LLVM: from 1140s to 117s (9x speedup)

可扩展性是任何基础架构产品中最要害的性能之一。咱们最重要的性能之一就是反对多个编译器。Wasmer 1.0 附带了以下方面的反对：

Singlepass: 实用于不受 JIT bombs 影响的超疾速编译工夫（区块链）
Cranelift: 在须要起码优化的状况下实现疾速编译（现实的开发方式）
LLVM: 当必须具备最佳性能时（现实的生产方式），生成最佳的机器代码

除了编译器，咱们还引入了对可插入引擎的反对。WebAssembly 引擎是一种形象，它决定编译器如何管理所生成的汇编代码，包含如何对其进行加载和序列化。Wasmer 1.0 反对以下编译器引擎：

JIT engine: 它将生成的代码间接推送到内存中
Native engine: 它生成能够作为共享对象加载的原生代码。另外，原生引擎共享的对象和模块在短短几微秒内的执行和启动性能令人难以置信！

Wasmer 1.0 引入了“wasmer compile”，这是一个用于预编译 Wasm 文件的新命令。咱们的客户和开发人员应用“wasmer compile –native”将 WebAssembly 模块预编译为原生对象文件，例如 .so，.dylib 和.dll。预编译的对象和模块与 Wasmer CLI 兼容，或与 Wasmer 嵌入（Rust，Python，Go 等）一起应用。

预编译原生对象的外围劣势在于，它们只须要起码的运行工夫即可运行已编译模块，同时仍提供残缺的沙盒环境。打消了编译工夫，能够在极快的启动工夫间接执行工件。

首先运行：

wasmer compile --native python.wasm -o python.so

对于独立执行，请运行：

wasmer run python.so

或运行嵌入式程序（Rust 示例……反对许多其余示例）：

let module = Module::deserialize_from_file(“python.so”);
let instance = Instance::new(module, &wasi_imports);

边缘运行的物联网设施正在推动计算的将来，这已不是什么机密。然而，许多设施短少最佳的计算硬件或其余资源，例如电源，网络和存储。过来，用户在 Wasm 应用程序中附带了 Wasmer 和所有编译器。这种做法不是最现实的，尤其是对于物联网和边缘计算用例。

在 Wasmer 1.0 中，咱们看到 Wasm 和 Wasmer 在提供尽可能轻量级的执行环境方面处于领先地位，这对于在边缘的 IoT 设施上高效运行 Wasm 至关重要。借助咱们对 AOT 编译的新增反对，您能够运行“headless”版本的 Wasmer，其分量仅为数百 KB，并且能够在任何设施上运行任何预编译的 Wasm 二进制文件。

Wasmer 1.0 当初具备穿插编译性能。在以前的 Wasmer 版本中，以原生编译的 Wasm 应用程序为指标并在同一体系结构上运行。应用 Wasmer 1.0，您能够从 x86_64 机器为 aarch64 体系结构预编译 Wasm，反之亦然。

在任何 x86_64 机器上运行：

wasmer compile python.wasm -o python-arm.so --native --target=aarch64-linux-gnu

而后在您的 ARM 机器上本地运行编译后果：

wasmer run python-arm.so

Wasmer 1.0 的次要指标是使对高级 WebAssembly 概念或 WebAssembly 生态系统常识无限的开发人员能够轻松应用 API。Wasmer 1.0 进一步改良了咱们的 API，通过依据规范 Wasm-C-API 所具备的类似构造对其进行调整，使其具备将来的弹性。

use wasmer::{Store, Module, Instance, Value, imports};

fn main() -> Result<(), Box<dyn std::error::Error>> {
    let module_wat = r#"
    (module
    (type $t0 (func (param i32) (result i32)))
    (func $add_one (export "add_one") (type $t0) (param $p0 i32) (result i32)
        get_local $p0
        i32.const 1
        i32.add))
    "#;
    
    let store = Store::default();
    let module = Module::new(&store, &module_wat);
    let import_object = imports! {};
    let instance = Instance::new(module, &import_object)?;

    let add_one = instance.exports.get_function("add_one")?;
    let result = add_one.call([Value::I32(42)])?;
    assert_eq!(result[0], Value::I32(43));

    Ok(())
}

随着 WebAssembly 生态系统的成熟，业界将正确地推动和对立与 WebAssembly 交互的 API。Wasm-C-API 比拟新，因而咱们决定构建一个与内部结构严密匹配的 API。

然而，随着行业朝着通用 API 迈进，咱们决定将其作为 Wasmer 1.0 的一部分并做出奉献，以便每个人都能从中受害。

留神：咱们将持续反对 Wasmer-C-API。然而，咱们倡议以后用户切换到规范 Wasm-C-API。

Wasmer 1.0 齐全从新定义并提供了新的改良的错误处理性能，使开发人员能够释怀地与 Wasmer 集成。大大缩短了构建可投入生产的 Wasm 应用程序所需的工夫。例如，每次产生谬误时，都要精确晓得谬误的起源：它是虚拟机的吗？是因为没有足够的可用资源吗？还是仅仅是某些原生性能触发的预期谬误？Wasmer 1.0 为未来进行更高级的谬误检测和报告奠定了根底。

就在几周前，苹果公司推出了其新系列的计算机，该计算机系列具备基于 ARM 的全新芯片组：Apple Silicon。

服务器端工作负载中的 ARM 有着光明的将来，它坚固了跨芯片组通用二进制文件的需要。咱们非常高兴地发表 Wasmer 是第一个在 Apple Silicon 中反对 Wasm 的服务。

如果您想尝试 Wasmer，则能够从 wasmer.io 装置 CLI，以独立运行 Wasmer 或将 Wasmer 嵌入您喜爱的编程语言中。

关于webassembly:通用WebAssembly运行时Wasmer-10-GA

性能基准测试

Wasmer 1.0 的编译速度进步了 9 倍

可插拔基础架构

原生对象引擎

Headless Wasmer

穿插编译

十分易于应用的 API

Wasm-C-API

错误处理和调试

反对 Apple Silicon

试用