Wasmer: Expose `compile_with` to C API

[mankash]

Expose compile_with from C API

Motivation

Current C API doesn't expose the compiler back-end to be used with the runtime. Exposing compile_with would allow choosing the LLVM back-end. LLVM back-end might be preferred for the speed of execution of the output, and also features like SIMD that are currently exclusive to LLVM

Proposed solution

Expose compile_with in C API

Alternatives

N/A

Additional context

N/A

[syrusakbary]

That would be a great addition indeed.
We will discuss with the team and try to come with a roadmap for it.

Are you using the C-api directly or using Wasmer from some other embedding? (Python, PHP, Ruby, Go, ...)

[mankash]

I intend to use Wasmer directly in C

[mankash]

Hello - I know the wasmer team is busy, and also have an upcoming release enabling threading.

Wondering if this feature can also make it into the the upcoming release.

Thank you

[ethanfrey]

HI @mankash, I have been working with enabling other features in the backend, and the issue with simply adding compile_with is feature gating, the llvm code is not in the default build.

You can build the runtime with

cargo build --features llvm-backend --no-default-features

Then the output will only use llvm instead of cranelift, which I believe is what you need for your use case? This does involve installing some llvm libs and setting env variables, but is also quite a bit faster at runtime. (I tried this out just calling it in rust, not through the c api)

[mankash]

Hello @ethanfrey -
Can you please consider adding LLVM-only C runtime libraries to the release?

If so, along with the existing released assets, Wasmer would add 3 additional libraries:

1. libwasmer-llvm_runtime_c_api.so
2. libwasmer-llvm_runtime_c_api.dylib
3. wasmer-llvm_runtime_c_api.dll

An embedder would have the choice between the default and llvm compilers, negating the requirement for this issue.

Many thanks

[ethanfrey]

Hi @mankash I am not a maintainer, just a user of wasmer that upstreamed a few enhancements.

I had another issue on the c api blocked by the backend defaulting to cranelift, when I needed singlepass.

I do think it is a nice idea to provide a whole matrix of builds for the c runtime if there is bandwidth to set up the ci. (And then feature switch which to link to in the language-specific bindings).

In particular, it would be a 3x3 matrix:

OS: Linux, MacOS, Windows
Backend: Cranelift, Singlepass, LLVM

And ideally, singlepass and llvm libraries would expose compile_with_limit or such from https://github.com/wasmerio/wasmer/pull/736 This would let users chose simple cranelift, or potentailly gas metered compilation with another backend.

That said, cross-compiling the llvm backend is most likely impossible. I had enough issues cross-compiling singlepass (from linux to macos), but llvm requires linking in platform-specific C++ libraries.

@syrusakbary Would you be open to such an enhancement to wasmer-runtime-c-api to add 3x3 backends if someone updated ci scripts to build them? Or how do you build them now?

[syrusakbary]

One quick question that I'd love to get more info about:

Is common for your use case to use two backends at the same time?

If that's not the case, perhaps we can link a library with a specific backend? (for example, libwasmer_runtime_c_api-cranelift.so, libwasmer_runtime_c_api-singlepass.so, libwasmer_runtime_c_api-llvm.so, ...)

Thoughts?

[ethanfrey]

My design would only be one backend, selected at compile time. So the above suggestion would work for my use case. Anything that allows selecting a backend without forking wasmer-runtime-c-api would be helpful.

Curious if anyone wants to dynamically select backend at runtime?

[robinvanemden]

One quick question that I'd love to get more info about:

Is common for your use case to use two backends _at the same time_?

If that's not the case, perhaps we can link a library with a specific backend? (for example, libwasmer_runtime_c_api-cranelift.so, libwasmer_runtime_c_api-singlepass.so, libwasmer_runtime_c_api-llvm.so, ...)

Thoughts?

It would be useful for us to be able to select a backend through (for instance) the go-ext-wasm library depending on compute task specifications.

For now, though, we are happy with defaulting to building libwasmer_runtime_c_api with LLVM. This provides fast run times, while LLVM's comparatively slow compile times can be circumvented by serializing the module on compilation. For that use case, it would be useful to provide prebuild libraries for each backend option.

[Hywan]

I would like to close this issue because the Wasmer C API is now deprecated in favor of the standard Wasm C API. But, we might add extra functions to use a specific engine and/or compiler.

Is it OK to close this issue for the moment, and reopen if the incoming API will miss some functions for you? Let's do this: I'm closing the issue, but feel free to ping me and I'll reopen according to your needs!