backgroundradial

Announcing Wasmer 4.3.0

Wasmer 4.3.0 ships with 25% faster cold starts and a new `wasmer deploy` flow

syrusakbary avatar
syrusakbary
Syrus Akbary

Founder & CEO

runtime

May 10, 2024

arrowBack to articles
Post cover image

Today we are incredibly excited to share the latest Wasmer release: 4.3.0.

Wasmer 4.3.0 ships shiny new updates:

  • ✨ New wasmer publish and wasmer deploy flows with awesome DX
  • 🚀 25% faster cold starts
  • 🔥 Improvements to the Singlepass compiler
  • 🦾 Various fixes and stability improvements

You can install Wasmer CLI 4.3.0 in your system very easily with:

$ curl https://get.wasmer.io -sSfL | sh

Thanks to the new DX improvements, you can deploy new apps super easily, just a wasmer deploy away:

New wasmer publish and wasmer deploy flows

What we showed above is just a sneak peek of how much the deployment flow has been improved:

  • We automatically prompt the user to log in if needed
  • Ask for the app name/owner upon deploying a new app
  • Automatically publishing packages for you when deploying, without the hassle of even requiring a package name (and thus, a leaner wasmer.toml file!)
  • Added a wasmer package push and wasmer package tag (in beta) to allow publishing flows similar to Docker
  • Incredibly fast deploy times… we went from 10s of seconds to 1-2 seconds to have your application live in Wasmer Edge.

We hope you are as excited as we are about the new Developer Experience 🚀

Please try wasmer deploy and let us know your thoughts!

25% Faster Cold starts

In the last months, we have been trying to make cold starts as fast as humanly possible.

This helps to improve startup time when running packages via wasmer run but also for cold-starts in Wasmer Edge… which is very important to spin up websites fast after a long period of inactivity.

As part of these efforts, we identified one improvement we could do in Module::deserialize that would help shave even more the timings thanks to rkyv 0-copy deserialization mechanism.

We were not using 0-copy for the frame information deserialization (used to show stack traces when certain functions trap), so we did make that part of deserialization also be 0-copy.

We also realized that we were always hashing the modules upon wasmer run, which can be a costly process depending on how big the Wasm module is. So we decided to store those hashes in the registry and use them when possible, as well as compute them lazily when running local packages.

Once we made these improvements, we unlocked the ~25% speedup in Module::deserialize and thus, we achieved 25% faster cold starts!

Wasmer v4.3.0- Python Startup Time

You can test some packages with Wasmer and see how they run at the speed of light compared to previous versions:


# Wasmer 4.2.8
$ hyperfine --warmup 3 -r 30 "wasmer run python/python -- --version"
Benchmark 1: wasmer run python/python -- --version
  Time (mean ± σ):     196.8 ms ±  20.3 ms    [User: 66.9 ms, System: 130.1 ms]
  Range (min … max):   159.7 ms … 225.5 ms    30 runs
 
# Wasmer 4.3.0
$ hyperfine --warmup 3 -r 30 "wasmer run python/python -- --version"
Benchmark 1: wasmer run python/python -- --version
  Time (mean ± σ):     149.3 ms ±  16.9 ms    [User: 53.3 ms, System: 100.3 ms]
  Range (min … max):   117.0 ms … 185.6 ms    30 runs

Improvements to Singlepass

We improved the Singlepass compilation flow to prevent panics when encountering unhandled edge cases not generating the proper assembly code for the chipset.

We also fixed one bug in Singlepass when compiling a very big wasm function to ARM, causing relocation offsets to be more than 2^19 bits of difference between them.

Stay tuned… because many more improvements to Singlepass will come soon!

Various fixes

As part of trying to run PHP as seamlessly as possible, we discovered an obscure bug:

After saving the stack so we can rewind it later (used when calling longjmp, setjmp, and other syscalls), the stack was getting corrupted for unknown reasons.

Later on, we realized that the stack was actually being rewritten by the unwind/rewind logic because it was not aware of the region that contains thread locals and globals.

We realized that in newer versions of LLVM, there are new globals in wasm (namely __stack_low and __stack_high) that can allow us to safely store data on the unused part of the stack without worrying about corruption issues.

So we did… and the PHP-cli was working, without any issues.

Stay tuned for more updates on this front!


We are incredibly excited to see how you are going to use all the improvements!

Read the full Changelog of Wasmer 4.3 here, or feel free to give us a star on GitHub! https://github.com/wasmerio/wasmer

You can also:

About the Author

Syrus Akbary is an enterpreneur and programmer. Specifically known for his contributions to the field of WebAssembly. He is the Founder and CEO of Wasmer, an innovative company that focuses on creating developer tools and infrastructure for running Wasm

Syrus Akbary avatar
Syrus Akbary
Syrus Akbary

Founder & CEO

Read more

engineeringruntimewasmer runtime

Wasmer 2.3

Syrus AkbaryJune 7, 2022

engineeringruntimewasmer runtime

Wasmer 3.2

Syrus AkbaryApril 18, 2023

engineeringruntimewasmer runtime

Wasmer 2.0, It's a big deal!

Syrus AkbaryJune 2, 2021

engineeringruntimewasmer 2.1

Wasmer-JS: A New Hope

Syrus AkbaryDecember 7, 2021