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运行时进行残缺的剖析，以便您比拟并抉择最适宜您的我的项目的技术！

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

当初，咱们所有的编译器都能够并行编译函数。借助这一新策略，咱们在所有编译器中的编译速度均进步了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);

Headless Wasmer

边缘运行的物联网设施正在推动计算的将来，这已不是什么机密。然而，许多设施短少最佳的计算硬件或其余资源，例如电源，网络和存储。过来，用户在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

十分易于应用的API


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(())}

Wasm-C-API

随着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为未来进行更高级的谬误检测和报告奠定了根底。

反对 Apple Silicon

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

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

试用

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