WasmKit

[kkebo]

wasm3 is great, but there is another great runtime. It's WasmKit.

https://github.com/swiftwasm/WasmKit

I think WasmKit has potential for the following reasons:

1. It's now as fast as wasm3 with recent changes.
2. It's standalone and embeddable (according to README).
3. It's written in Swift and supports iOS 12+, so it may be easier to use from a-Shell.
4. wasm3 is in a minimal maintenance phase for some unfortunate reasons, but WasmKit is actively maintained.
5. It's used in swiftlang/swift.

[holzschu]

Thanks. I've tried WasmKit in the past (but before the recent changes that make it faster) and wasn't impressed by the speed.

The key feature that I'm missing in Wasm3 and would make me switch very fast to WasmKit is the support for exceptions. As far as I can tell, it's not yet present in WasmKit either. But let's keep monitoring their site, it can change in the future.

I've also experimented with "Web Assembly Micro-Runtime", which has exceptions, but was 10x slower than Apple's engine, and WasmEdge, which has exceptions, but requires mmap(), and thus doesn't work on iOS.

[kkebo]

The key feature that I'm missing in Wasm3 and would make me switch very fast to WasmKit is the support for exceptions. As far as I can tell, it's not yet present in WasmKit either.

Is this the "exception" you are referring to?

https://github.com/WebAssembly/exception-handling

[holzschu]

Yes.
It is present in the WebAssembly generated by LLVM 18 and above, and it makes it possible to compile C++ code without the --no-exceptions flag. C++ uses exceptions a lot, and C code that uses setjmp() and longjmp() also compiles to WebAssembly using exceptions.

On the execution side, it is supported by Apple's WebAssembly engine, but not by Wasm3 (and not by WasmKit, as far as I can tell). Since a lot of existing C code uses setjmp() / longjmp(), not having exceptions available limits the range of code the interpreter can run.

[NobodyXu]

Hello, wasmer has recently added native support for iOS

Leveraging the capabilities of V8, Wasmi and WebAssembly Micro Runtime (WAMR), developers can now run WebAssembly modules seamlessly on iOS thanks to Wasmer 5.0.

https://wasmer.io/posts/introducing-wasmer-v5

Wasmer also supports WASIX and is quite optimised, I wonder if it would make executing wasm on a-shell faster.

[holzschu]

Thanks. With that information, and looking at the Makefile (because we have to use the Makefile to compile wasmer), I see that I can force the use of "wamr" by calling: env CARGO_TARGET=aarch64-apple-ios make build-wasmer-wamr. It fails with the following error:

(...) 8" "-Wl,-dead_strip" "-nodefaultlibs"
  = note: ld: library 'vmlib' not found
          clang: error: linker command failed with exit code 1 (use -v to see invocation)
          

error: could not compile `wasmer-cli` (bin "wasmer") due to 1 previous error
make: *** [build-wasmer-wamr] Error 101

[NobodyXu]

I've found the wasmer CI which runs make build-wasmer-wamr on macos arm, it seems that they got a dependency installation step there.

https://github.com/wasmerio/wasmer/actions/runs/11594383402/job/32280516014

[holzschu]

Awesome detective work! But when I look under "Set up dependencies for MacOS", I don't see anything fancy: only automake, m4 and autoconf. None of these should be an issue, they are standard commands. Am I missing another dependency step installation?

[NobodyXu]

It seems that they also do:

brew install ninja gcc
sudo xcode-select -s /Library/Developer/CommandLineTools

and install LLVM.

Perhaps there's some missing stuff for cross compiling to aarch64-apple-ios?

Or maybe try rm -r target/ and start from fresh, perhaps some caching has gone wrong.

[holzschu]

Again, these are very standard tools, already installed on my machine. If they were missing, the issue would have happened on the first line. I've tried cargo clean (which is, in practice, rm -rf target/*) and rebuilt several times, with no difference.

I can tell you that libvmlib.a is generated when you build WAMR, somewhere inside ./lib/api/third_party/wamr/. For some reasons, it is not automatically generated when building for iOS. I can generate it on my own, inside my separate clone of wasm-micro-runtime I'll need to find where to place it in order for cargo to use it.

I've also tracked that wasm_instance_new (in lib/c-api/src/wasm_c_api/instance.rs) calls new_by_index in lib/api/src/instance.rs, which calls itself a second time and then raises an error.

[holzschu]

Report:

• on the Wasmer front, we're still waiting for an answer from their Discord channel (which is totally normal, it's the weekend).
• I'm uploading a new TestFlight version of a-Shell, with the WebAssembly Micro-Runtime included, so you can run tests. It doesn't have full access to the file system (as it common with Wasm interpreters before I hack them), so tests are mostly with standard input and output. Since Wasmer, according to its own documentation, is using Wamr as a backend on iOS, speed results should be the same.

I've been running tests on zipping a large file (105 MB), sent using the standard input.

• wasm3: 90 s (5 runs: 92, 89, 89, 89, 90)
• wasm (Apple's engine): 102 s (107, 62, 102, 9, 102. The 9 second runs produced a truncated file)
• wamr: 330s (330, 331, 330, 333, 331)
  So wamr is between 3 and 3.5 times slower on this test. That's better than the 10x on my previous tests.

[NobodyXu]

https://github.com/bytecodealliance/wasm-micro-runtime/blob/main/doc/build_wamr.md

Looking at its doc, there seems to have some ways of tuning its performance?

E.g. bulk memory, WAMR_BUILD_MINI_LOADER

[holzschu]

I read it before, but the performance tuning options are actually pretty limited if you want to have exception handling:

Note: Currently, the exception handling feature is only supported in classic interpreter running mode.

I don't think a computation time of 300+ seconds is related to loading, and most likely not compiling either (these are at most 1-2 seconds each).

[NobodyXu]

Could it be partially be bulk memory or WAMR_BUILD_TAIL_CALL?

Maybe enable them could improve performance.

Though the biggest performance blocker is probably the fast interpreter, if it supports exception handling then it's going to be 2x faster, so it'd only be 1.5x~2x slower.

bytecodealliance/wasm-micro-runtime#3435

There's an issue for that but seems no one working on it.

[holzschu]

I ran another test, this time pure CPU computations (computing the 40th Fibonacci number):

• wasm3: 22.6 seconds
• wasm (Apple's engine): 4.3 seconds
• wamr: 78.3 seconds
  These cases (small binary, no I/O at all) are where Apple's engine outperforms everyone else. Compared to Wasm3, we still have the 3.5x slower ratio. But that tells us it's the CPU instructions that are running 3.5x slower, even with no memory access.

[NobodyXu]

Out of curiosity, does apple's wasm have access to JIT?

Shame that we can't use JIT there on iOS.

[holzschu]

Report:

• I've had some response on the Wasmer Discord channel. The first response was not working, but they've promised a more detailed response soon.
• I could make wamr work with local files (but that required some hacking, because weirdly fstatat() does not work with files in pre-opened directories), but I cannot make it work with readdir(): it reports an error "failed to find a pre-opened file descriptor through which directory could be opened", which happens outside of wamr source code.