Announcing the first Java library to run WebAssembly: Wasmer JNI

This is a copy of an article I wrote for Wasmer.


Image for post

WebAssembly is a portable binary format. That means the same file can run anywhere.

To uphold this bold statement, each language, platform and system must be able to run WebAssembly — as fast and safely as possible.

People who are familiar with Wasmer are used to this kind of announcement! Wasmer is written in Rust, and comes with an additional native C API. But you can use it in a lot of other languages. After having announced libraries to use Wasmer, and thus WebAssembly, in:

…we are jazzed to announce that Wasmer has now landed in Java!

Let’s discover the Wasmer JNI library together.

Installation

The Wasmer JNI (Java Native Interface) library is based on the Wasmer runtime, which is written in Rust, and is compiled to a shared library. For your convenience, we produce one JAR (Java Archive) per architecture and platform. By now, the following are supported, consistently tested, and pre-packaged (available in Bintray and Github Releases):

  • amd64-darwin for macOS, x86 64bits,
  • amd64-linux for Linux, x86 64 bits,
  • amd64-windows for Windows, x86 64 bits.

More architectures and more platforms will be added in the near future. If you need a specific one, feel free to ask! However, it is possible to produce your own JAR for your own platform and architecture.

The JAR files are named as follows: wasmer-jni-$(architecture)-$(os)-$(version).jar. Thus, to include Wasmer JNI as a dependency of your project (assuming you use Gradle), write for instance:

dependencies {
implementation "org.wasmer:wasmer-jni-amd64-linux:0.2.0"
}

JAR are hosted on the Bintray/JCenter repository under the wasmer-jni project. They are also attached to our Github releases as assets.

Calling a WebAssembly function from Java

As usual, let’s start with a simple Rust program that we will compile to WebAssembly, and then execute from Java.

#[no_mangle]
pub extern fn sum(x: i32, y: i32) -> i32 {
    x + y
}

After compilation to WebAssembly, we get a file like this one, named simple.wasm.

The following Java program executes the sum exported function by passing 5 and 37 as arguments:

import org.wasmer.Instance;

import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Paths;

class SimpleExample {
    public static void main(String[] args) throws IOException {
        // Read the WebAssembly bytes.
        byte[] bytes = Files.readAllBytes(Paths.get("simple.wasm"));

        // Instantiate the WebAssembly module.
        Instance instance = new Instance(bytes);

        // Get the `sum` exported function, call it by passing 5 and 37, and get the result.
        Integer result = (Integer) instance.exports.getFunction("sum").apply(5, 37)[0];

        assert result == 42;

        instance.close();
    }
}

Great! We have successfully executed a Rust program, compiled to WebAssembly, in Java. As you can see, it is pretty straightforward. The API is very similar to the standard JavaScript API, or the other API we have designed for PHP, Python, Go, Ruby etc.

The assiduous reader might have noticed the [0] in .apply(5, 37)[0] pattern. A WebAssembly function can return zero to many values, and in this case, we are reading the first one.

Note: Java values passed to WebAssembly exported functions are automatically downcasted to WebAssembly values. Types are inferred at runtime, and casting is done automatically. Thus, a WebAssembly function acts as any regular Java function.

Technically, an exported function is a functional interface as defined by the Java Language Specification (i.e. it is a FunctionalInterface). Thus, it is possible to write the following code where sum is an actual function (of kind org.wasmer.exports.Function):

import org.wasmer.Instance;
import org.wasmer.exports.Function;

import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Paths;

class SimpleExample {
    public static void main(String[] args) throws IOException {
        // Read the WebAssembly bytes.
        byte[] bytes = Files.readAllBytes(Paths.get("simple.wasm"));

        // Instantiate the WebAssembly module.
        Instance instance = new Instance(bytes);

        // Declare the `sum` function, as a regular Java function.
        Function sum = instance.exports.getFunction("sum");
        
        // Call `sum`.
        Integer result = (Integer) sum.apply(1, 2)[0];

        assert result == 3;

        instance.close();
    }
}

But a WebAssembly module not only exports functions, it also exports memory.

Reading the memory

A WebAssembly instance has one or more linear memories, a contiguous and byte-addressable range of memory spanning from offset 0 and extending up to a varying memory size, represented by the org.wasmer.Memory class. Let’s see how to use it. Consider the following Rust program:

#[no_mangle]
pub extern fn return_hello() -> *const u8 {
    b"Hello, World!\0".as_ptr()
}

The return_hello function returns a pointer to the statically allocated string. The string exists in the linear memory of the WebAssembly module. It is then possible to read it in Java:

import org.wasmer.Instance;
import org.wasmer.Memory;

import java.io.IOException;
import java.nio.ByteBuffer;
import java.nio.file.Files;
import java.nio.file.Paths;

class MemoryExample {
    public static void main(String[] args) throws IOException {
        // Read the WebAssembly bytes.
        byte[] bytes = Files.readAllBytes(Paths.get("memory.wasm"));

        // Instantiate the WebAssembly module.
        Instance instance = new Instance(bytes);

        // Get a pointer to the statically allocated string returned by `return_hello`.
        Integer pointer = (Integer) instance.exports.getFunction("return_hello").apply()[0];

        // Get the exported memory named `memory`.
        Memory memory = instance.exports.getMemory("memory");

        // Get a direct byte buffer view of the WebAssembly memory.
        ByteBuffer memoryBuffer = memory.buffer();

        // Prepare the byte array that will hold the data.
        byte[] data = new byte[13];

        // Let's position the cursor, and…
        memoryBuffer.position(pointer);
        
        // … read!
        memoryBuffer.get(data);

        // Let's encode back to a Java string.
        String result = new String(data);

        // Hello!
        assert result.equals("Hello, World!");

        instance.close();
    }
}

As we can see, the Memory API provides a buffer method. It returns a direct byte buffer (of kind java.nio.ByteBuffer) view of the memory. It’s a standard API for any Java developer. We think it’s best to not reinvent the wheel and use standard API as much as possible.

The WebAssembly memory is dissociated from the JVM memory, and thus from the garbage collector.

You can read the Greet Example to see a more in-depth usage of the Memory API.

More documentation

The project comes with a Makefile. The make javadoc command will generate a traditional local Javadoc for you, in the build/docs/javadoc/index.html file.

In addition, the project’s README.md file has an API of the wasmer library Section.

Finally, the project comes with a set of examples. Use the make run-example EXAMPLE=Simple to run the SimpleExample.java example for instance.

Performance

WebAssembly aims at being safe, but also fast. Since Wasmer JNI is the first Java library to execute WebAssembly, we can’t compare to prior works in the Java ecosystem. However, you might know that Wasmer comes with 3 backends: Singlepass, Cranelift and LLVM. We’ve even written an article about it: A WebAssembly Compiler tale. The Wasmer JNI library uses the Cranelift backend for the moment, which offers the best compromise between compilation-time and execution-time.

Credits

Asami (d0iasm on Twitter) has improved this project during its internship at Wasmer under my guidance. She finished the internship before the release of the Wasmer JNI project, but she deserves credits for pushing the project forward! Good work Asami!

This is an opportunity to remind everyone that we hire anywhere in the world. Asami was working from Japan while I am working from Switzerland, and the rest of the team is from US, Spain, China etc. Feel free to contact me (@mnt_io or @syrusakbary on Twitter) if you want to join us on this big adventure!

Conclusion

Wasmer JNI is a library to execute WebAssembly directly in Java. It embeds the WebAssembly runtime Wasmer. The first releases provide the core API with Module, Instance, and Memory. It comes pre-packaged as a JAR, one per architecture and per platform.

The source code is open and hosted on Github at https://github.com/wasmerio/java-ext-wasm. We are constantly improving the project, so if you have feedback, issues, or feature requests please open an issue in the repository, or reach us on Twitter at @wasmerio or @mnt_io.

We look forward to see what you build with this!

Announcing the first Postgres extension to run WebAssembly

This is a copy of an article I wrote for Wasmer.


Image for post
Elephant. Source of the photo.

WebAssembly is a portable binary format. That means the same program can run anywhere.

To uphold this bold statement, each language, platform and system must be able to run WebAssembly — as fast and safely as possible.

Let’s say it again. Wasmer is a WebAssembly runtime. We have successfully embedded the runtime in other languages:

The community has also embedded Wasmer in awesome projects:

It is now time to continue the story and to hang around… Postgres!

We are so happy to announce a newcrazy idea: WebAssembly on Postgres. Yes, you read that correctly. On Postgres.

Calling a WebAssembly function from Postgres

As usual, we have to go through the installation process. There is no package manager for Postgres, so it’s a manual step. The Installation Section of the documentation explains the details; here is a summary:

$ # Build the shared library.
$ just build

$ # Install the extension in the Postgres tree.
$ just install

$ # Activate the extension.
$ echo 'CREATE EXTENSION wasm;' | \
      psql -h $host -d $database

$ # Initialize the extension.
$ echo "SELECT wasm_init('$(pwd)/target/release/libpg_ext_wasm.dylib');" | \
      psql -h $host -d $database

Once the extension is installed, activated and initialized, we can start having fun!

The current API is rather small, however basic features are available. The goal is to gather a community and to design a pragmatic API together, discover the expectations, how developers would use this new technology inside a database engine.

Let’s see how it works. To instantiate a WebAssembly module, we use the wasm_new_instance function. It takes 2 arguments: The absolute path to the WebAssembly module, and a prefix for the module exported functions. Indeed, if a module exports a function named sum, then a Postgres function named prefix_sum calling the sum function will be created dynamically.

Let’s see it in action. Let’s start by editing a Rust program that compiles to WebAssembly:

#[no_mangle]
pub extern fn sum(x: i32, y: i32) -> i32 {
    x + y
}

Once this file compiled to simple.wasm, we can instantiate the module, and call the exported sum function:

-- New instance of the `simple.wasm` WebAssembly module.
SELECT wasm_new_instance('/absolute/path/to/simple.wasm', 'ns');

-- Call a WebAssembly exported function!
SELECT ns_sum(1, 2);

--  ns_sum
-- --------
--       3
-- (1 row)

Et voilà ! The ns_sum function calls the Rust sum function through WebAssembly! How fun is that 😄?

Inspect a WebAssembly instance

This section shows how to inspect a WebAssembly instance. At the same time, it quickly explains how the extension works under the hood.

The extension provides two foreign data wrappers, gathered together in the wasm foreign schema:

  • wasm.instances is a table with the id and wasm_file columns, respectively for the unique instance ID, and the path of the WebAssembly module,
  • wasm.exported_functions is a table with the instance_id,name, inputs, and outputs columns, respectively for the instance ID of the exported function, its name, its input types (already formatted for Postgres), and its output types (already formatted for Postgres).

Let’s see:

-- Select all WebAssembly instances.
SELECT * FROM wasm.instances;

--                   id                  |          wasm_file
-- --------------------------------------+-------------------------------
--  426e17af-c32f-5027-ad73-239e5450dd91 | /absolute/path/to/simple.wasm
-- (1 row)

-- Select all exported functions for a specific instance.
SELECT
    name,
    inputs,
    outputs
FROM
    wasm.exported_functions
WHERE
    instance_id = '426e17af-c32f-5027-ad73-239e5450dd91';

--   name  |     inputs      | outputs
-- --------+-----------------+---------
--  ns_sum | integer,integer | integer
-- (1 row)

Based on these information, the wasm Postgres extension is able to generate the SQL function to call the WebAssembly exported functions.

It sounds simplistic, and… to be honest, it is! The trick is to use foreign data wrappers, which is an awesome feature of Postgres.

How fast is it, or: Is it an interesting alternative to PL/pgSQL?

As we said, the extension API is rather small for now. The idea is to explore, to experiment, to have fun with WebAssembly inside a database. It is particularly interesting in two cases:

  1. To write extensions or procedures with any languages that compile to WebAssembly in place of PL/pgSQL,
  2. To remove a potential performance bottleneck where speed is involved.

Thus we run a basic benchmark. Like most of the benchmarks out there, it must be taken with a grain of salt.

The goal is to compare the execution time between WebAssembly and PL/pgSQL, and see how both approaches scale.

The Postgres WebAssembly extension uses Wasmer as the runtime, compiled with the Cranelift backend (learn more about the different backends). We run the benchmark with Postgres 10, on a MacBook Pro 15″ from 2016, 2.9Ghz Core i7 with 16Gb of memory.

The methodology is the following:

  • Load both the plpgsql_fibonacci and the wasm_fibonacci functions,
  • Run them with a query like SELECT *_fibonacci(n) FROM generate_series(1, 1000) where n has the following values: 50, 500, and 5000, so that we can observe how both approaches scale,
  • Write the timings down,
  • Run this methodology multiple times, and compute the median of the results.

Here come the results. The lower, the better.

Comparing WebAssembly vs. PL/pgSQL when computing the Fibonacci sequence with n=50, 500 and 5000.

We notice that the Postgres WebAssembly extension is faster to run numeric computations. The WebAssembly approach scales pretty well compared to the PL/pgSQL approach, in this situation.

When to use the WebAssembly extension?

So far, the extension only supports integers (on 32- and 64-bits). The extension doesn’t support strings yet. It also doesn’t support records, views or other Postgres types. Keep in mind this is the very first step.

Hence, it is too soon to tell whether WebAssembly can be an alternative to PL/pgSQL. But regarding the benchmark results above, we are sure they can live side-by-side, WebAssembly has clearly a place in the ecosystem! And we want to continue to pursue this exploration.

Conclusion

We are already talking with people that are interested in using WebAssembly inside databases. If you have any particular use cases, please reach us at wasmer.io, or on Twitter at @wasmerio directly or me @mnt_io.

Everything is open source, as usual! Happy hacking.

Announcing the fastest WebAssembly runtime for Go: wasmer

This is a copy of an article I wrote for Wasmer.


Image for post
Go loves WebAssembly — image attributions to the original Gopher drawing.

WebAssembly is a portable binary format. That means the same file can run anywhere.

To uphold this bold statement, each language, platform and system must be able to run WebAssembly — as fast and safely as possible.

Wasmer is a WebAssembly runtime written in Rust. It goes without saying that the runtime can be used in any Rust application. We have also successfully embedded the runtime in other languages:

We are super happy to announce github.com/wasmerio/go-ext-wasm/wasmer, a Go library to run WebAssembly binaries, fast.

Calling a WebAssembly function from Go

First, let’s install wasmer in your go environment (with cgo support).

export CGO_ENABLED=1; export CC=gcc; go install github.com/wasmerio/go-ext-wasm/wasmer

Let’s jump immediately into some examples.github.com/wasmerio/go-ext-wasm/wasmer is a regular Go library. The installation is automated with import "github.com/wasmerio/go-ext-wasm/wasmer".

Let’s get our hands dirty. We will write a program that compiles to WebAssembly easily, using Rust for instance:

#[no_mangle]
pub extern fn sum(x: i32, y: i32) -> i32 {
    x + y
}

After compilation to WebAssembly, we get a file like this one, named simple.wasm.
The following Go program executes the sum function by passing 5 and 37 as arguments:

package main

import (
	"fmt"
	wasm "github.com/wasmerio/go-ext-wasm/wasmer"
)

func main() {
	// Reads the WebAssembly module as bytes.
	bytes, _ := wasm.ReadBytes("simple.wasm")
	
	// Instantiates the WebAssembly module.
	instance, _ := wasm.NewInstance(bytes)
	defer instance.Close()

	// Gets the `sum` exported function from the WebAssembly instance.
	sum := instance.Exports["sum"]

	// Calls that exported function with Go standard values. The WebAssembly
	// types are inferred and values are casted automatically.
	result, _ := sum(5, 37)

	fmt.Println(result) // 42!
}

Great! We have successfully executed a WebAssembly file inside Go.

Note: Go values passed to the WebAssembly exported function are automatically cast to WebAssembly values. Types are inferred and casting is done automatically. Thus, a WebAssembly function acts as any regular Go function.

WebAssembly calling Go funtions

A WebAssembly module exports some functions, so that they can be called from the outside world. This is the entry point to execute WebAssembly.

Nonetheless, a WebAssembly module can also have imported functions. Let’s consider the following Rust program:

extern {
    fn sum(x: i32, y: i32) -> i32;
}

#[no_mangle]
pub extern fn add1(x: i32, y: i32) -> i32 {
    unsafe { sum(x, y) } + 1
}

The exported function add1 calls the sum function. Its implementation is absent, only its signature is defined. This is an “extern function”, and for WebAssembly, this is an imported function, because its implementation must be imported.

Let’s implement the sum function in Go! To do so, need to use cgo:

  1. The sum function signature is defined in C (see the comment above import "C"),
  2. The sum implementation is defined in Go. Notice the //export which is the way cgo uses to map Go code to C code,
  3. NewImports is an API used to create WebAssembly imports. In this code "sum" is the WebAssembly imported function name, sum is the Go function pointer, and C.sum is the cgo function pointer,
  4. Finally, NewInstanceWithImports is the constructor to use to instantiate the WebAssembly module with imports. That’s it.

Let’s see the complete program:

package main

// // 1️⃣ Declare the `sum` function signature (see cgo).
//
// #include <stdlib.h>
//
// extern int32_t sum(void *context, int32_t x, int32_t y);
import "C"

import (
	"fmt"
	wasm "github.com/wasmerio/go-ext-wasm/wasmer"
	"unsafe"
)

// 2️⃣ Write the implementation of the `sum` function, and export it (for cgo).
//export sum
func sum(context unsafe.Pointer, x int32, y int32) int32 {
	return x + y
}

func main() {
	// Reads the WebAssembly module as bytes.
	bytes, _ := wasm.ReadBytes("import.wasm")

	// 3️⃣ Declares the imported functions for WebAssembly.
	imports, _ := wasm.NewImports().Append("sum", sum, C.sum)

	// 4️⃣ Instantiates the WebAssembly module with imports.
	instance, _ := wasm.NewInstanceWithImports(bytes, imports)

	// Close the WebAssembly instance later.
	defer instance.Close()

	// Gets the `add1` exported function from the WebAssembly instance.
	add1 := instance.Exports["add1"]

	// Calls that exported function.
	result, _ := add1(1, 2)

	fmt.Println(result)
	//   add1(1, 2)
	// = sum(1 + 2) + 1
	// = 1 + 2 + 1
	// = 4
	// QED
}

Reading the memory

A WebAssembly instance has a linear memory. Let’s see how to read it. Consider the following Rust program:

#[no_mangle]
pub extern fn return_hello() -> *const u8 {
    b"Hello, World!\0".as_ptr()
}

The return_hello function returns a pointer to a string. The string terminates by a null byte, à la C. Let’s jump on the Go side:

bytes, _ := wasm.ReadBytes("memory.wasm")
instance, _ := wasm.NewInstance(bytes)
defer instance.Close()

// Calls the `return_hello` exported function.
// This function returns a pointer to a string.
result, _ := instance.Exports["return_hello"]()

// Gets the pointer value as an integer.
pointer := result.ToI32()

// Reads the memory.
memory := instance.Memory.Data()

fmt.Println(string(memory[pointer : pointer+13])) // Hello, World!

The return_hello function returns a pointer as an i32 value. We get its value by calling ToI32. Then, we fetch the memory data with instance.Memory.Data().

This function returns a slice over the WebAssembly instance memory. It can be used as any regular Go slice.

Fortunately for us, we already know the length of the string we want to read, so memory[pointer : pointer+13] is enough to read the bytes, that are then cast to a string. Et voilà !

You can read the Greet Example to see a more advanced usage of the memory API.

Benchmarks

So far, github.com/wasmerio/go-ext-wasm/wasmer has a nice API, but …is it fast?

Contrary to PHP or Ruby, there are already existing runtimes in the Go world to execute WebAssembly. The main candidates are:

  • Life, from Perlin Network, a WebAssembly interpreter
  • Wagon, from Go Interpreter, a WebAssembly interpreter and toolkit.

In our blog post about the PHP extension, we have used the n-body algorithm to benchmark the performance. Life provides more benchmarks: the Fibonacci algorithm (the recursive version), the Pollard’s rho algorithm, and the Snappy Compress operation. The latter works successfully with github.com/wasmerio/go-ext-wasm/wasmer but not with Life or Wagon. We have removed it from the benchmark suites. Benchmark sources are online.

We use Life 20190521143330–57f3819c2df0, and Wagon 0.4.0, i.e. the latest versions to date.

The benchmark numbers represent the average result for 10 runs each. The computer that ran these benchmarks is a MacBook Pro 15″ from 2016, 2.9Ghz Core i7 with 16Gb of memory.

Results are grouped by benchmark algorithm on the X axis. The Y axis represents the time used to run the algorithm, expressed in milliseconds. The lower, the better.

Speed comparison between Wasmer, Wagon and Life. Benchmark suites are the n-body, Fibonacci, and Pollard’s rho algorithms. Speed is expressed in ms. Lower is better.

While both Life and Wagon provide on average the same speed, Wasmer (github.com/wasmerio/go-ext/wasmer) is on average 72 times faster 🎉.

It is important to know that Wasmer comes with 3 backends: Singlepass, Cranelift, and LLVM. The default backend that is used by the Go library is Cranelift (learn more about Cranelift). Using LLVM will provide performance close to native, but we decided to start with Cranelift as it offers the best tradeoff between compilation-time and execution-time (learn more about the different backends, when to use them, pros and cons etc.).

Conclusion

github.com/wasmerio/go-ext-wasm/wasmer is a new Go library to execute WebAssembly binaries. It embeds the Wasmer runtime. The first version supports all the required API for the most common usages.

The current benchmarks (a mix from our benchmark suites and from Life suites) show that Wasmer is — on average — 72 times faster than Life and Wagon, the two major existing WebAssembly runtimes in the Go world.

If you want to follow the development, take a look at @wasmerio and @mnt_io on Twitter, or @wasmer@webassembly.social on Mastodon. And of course, everything is open source at https://github.com/wasmerio/go-ext-wasm.wasmerio/go-ext-wasm🐹🕸️ Go library to run WebAssembly binaries. Contribute to wasmerio/go-ext-wasm development by creating an account on…github.com

Thank you for your time, we can’t wait to see what you build with us!

🐘+🦀+🕸 php-ext-wasm: Migrating from wasmi to Wasmer

This is a copy of an article I wrote for Wasmer.


Image for post
Elephant in the forest. Source of the photo.

First as a joke, now as a real product, I started to develop php-ext-wasm: a PHP extension allowing to execute WebAssembly binaries.

The PHP virtual machine (VM) is Zend Engine. To write an extension, one needs to develop in C or C++. The extension was simple C bindings to a Rust library I also wrote. At that time, this Rust library was using wasmi for the WebAssembly VM. I knew that wasmi wasn’t the fastest WebAssembly VM in the game, but the API is solid, well-tested, it compiles quickly, and is easy to hack. All the requirements to start a project!

After 6 hours of development, I got something working. I was able to run the following PHP program:

<?php

$instance = new Wasm\Instance('simple.wasm');
$result = $instance->sum(1, 2);

var_dump($result); // int(3)

The API is straightforward: create an instance (here of simple.wasm), then call functions on it (here sum with 1 and 2 as arguments). PHP values are transformed into WebAssembly values automatically. For the record, here is the simple.rs Rust program that is compiled to a WebAssembly binary:

#[no_mangle]
pub extern fn sum(x: i32, y: i32) -> i32 {
    x + y
}

It was great! 6 hours is a relatively small number of hours to go that far according to me.

However, I quickly noticed that wasmi is… slow. One of the promise of WebAssembly is:

WebAssembly aims to execute at native speed by taking advantage of common hardware capabilities available on a wide range of platforms.

And clearly, my extension wasn’t fulfilling this promise. Let’s see a basic comparison with a benchmark.

I chose the n-body algorithm from the Computer Language Benchmarks Game from Debian, mostly because it’s relatively CPU intensive. Also, the algorithm has a simple interface: based on an integer, it returns a floating-point number; this API doesn’t involve any advanced instance memory API, which is perfect to test a proof-of-concept.

As a baseline, I’ve run the n-body algorithm written in Rust, let’s call it rust-baseline. The same algorithm has been written in PHP, let’s call it php. Finally, the algorithm has been compiled from Rust to WebAssembly, and executed with the php-ext-wasm extension, let’s call that case php+wasmi. All results are for nbody(5000000):

  • rust-baseline: 287ms,
  • php: 19,761ms,
  • php+wasmi: 67,622ms.

OK, so… php-ext-wasm with wasmi is 3.4 times slower than PHP itself, it is pointless to use WebAssembly in such conditions!

It confirms my first intuition though: In our case, wasmi is really great to mock something up, but it’s not fast enough for our expectations.

Faster, faster, faster…

I wanted to use Cranelift since the beginning. It’s a code generator, à la LLVM (excuse the brutal shortcut, the goal isn’t to explain what Cranelift is in details, but that’s a really awesome project!). To quote the project itself:

Cranelift is a low-level retargetable code generator. It translates a target-independent intermediate representation into executable machine code.

It basically means that the Cranelift API can be used to generate executable code.

It’s perfect! I can replace wasmi by Cranelift, and boom, profit. But… there is other ways to get even faster code execution — at the cost of a longer code compilation though.

For instance, LLVM can provide a very fast code execution, almost at native speed. Or we can generate assembly code dynamically. Well, there is multiple ways to achieve that. What if a project could provide a WebAssembly virtual machine with multiple backends?

Enter Wasmer

And it was at that specific time that I’ve been hired by Wasmer. To be totally honest, I was looking at Wasmer a few weeks before. It was a surprise and a great opportunity for me. Well, the universe really wants this rewrite from wasmi to Wasmer, right 😅?

Wasmer is organized as a set of Rust libraries (called crates). There is even a wasmer-runtime-c-api crate which is a C and a C++ API on top of the wasmer-runtime crate and the wasmer-runtime-core crate, i.e. it allows running the WebAssembly virtual machine as you want, with the backend of your choice: Cranelift, LLVM, or Dynasm (at the time of writing). That’s perfect, it removes my Rust library between the PHP extension and wasmi. Then php-ext-wasm is reduced to a PHP extension without any Rust code, everything goes to wasmer-runtime-c-api. That’s sad to remove Rust from this project, but it relies on more Rust code!

Counting the time to make some patches on wasmer-runtime-c-api, I’ve been able to migrate php-ext-wasm to Wasmer in 5 days.

By default, php-ext-wasm uses Wasmer with the Cranelift backend, it does a great balance between compilation and execution time. It is really good. Let’s run the benchmark, with the addition of php+wasmer(cranelift):

  • rust-baseline: 287ms,
  • php: 19,761ms,
  • php+wasmi: 67,622ms,
  • php+wasmer(cranelift): 2,365ms 🎉.

Finally, the PHP extension provides a faster execution than PHP itself! php+wasmer(cranelift) is 8.6 times faster than php to be exact. And it is 28.6 times faster than php+wasmi. Can we reach the native speed (represented by rust-baseline here)? It’s very likely with LLVM. That’s for another article. I’m super happy with Cranelift for the moment. (See our previous blog post to learn how we benchmark different backends in Wasmer, and other WebAssembly runtimes).

More Optimizations

Wasmer provides more features, like module caching. Those features are now included in the PHP extension. When booting the nbody.wasm file (19kb), it took 4.2ms. By booting, I mean: reading the WebAssembly binary from a file, parsing it, validating it, compiling it to executable code and a WebAssembly module structure.

PHP execution model is: starts, runs, dies. Memory is freed for each request. If one wants to use php-ext-wasm, you don’t really want to pay that “booting cost” every time.

Hopefully, wasmer-runtime-c-api now provides a module serialization API, which is integrated into the PHP extension itself. It saves the “booting cost”, but it adds a “deserialization cost”. That second cost is smaller, but still, we need to know it exists.

Hopefully again, Zend Engine has an API to get persistent in-memory data between PHP executions. php-ext-wasm supports that API to get persistent modules, et voilà.

Now it takes 4.2ms for the first boot of nbody.wasm and 0.005ms for all the next boots. It’s 840 times faster!

Conclusion

Wasmer is a young — but mature — framework to build WebAssembly runtimes on top of. The default backend is Cranelift, and it shows its promises: It brings a correct balance between compilation time and execution time.

wasmi has been a good companion to develop a Proof-Of-Concept. This library has its place in other usages though, like very short-living WebAssembly binaries (I’m thinking of Ethereum contracts that compile to WebAssembly for instance, which is one of the actual use cases). It’s important to understand that no runtime is better than another, it depends on the use case.

The next step is to stabilize php-ext-wasm to release a 1.0.0 version.

See you there!

If you want to follow the development, take a look at @wasmerio and @mnt_io on Twitter.