Awesome, I just upgraded our project! We're using wasmer in a browser-based multiplayer game in order to get cross-platform floating point determinism so we can send only input packets over the wire confidently without worrying about state drift. The client and server run the exact same wasm bundle instead of just being compiled from the same source, and the wasm spec guarantees that as long as you don't touch NaN and stick to one thread, you'll get the same results in any runtime [1].
Interested in hearing more about your browser game. Another dev and I are working on a next gen HTML5 gaming platform using WebGL/WASM, and we're looking to back developers creating interesting titles. We provide access to our suite of devtools for optimizingprojects for the browser, and deploying on our platform.
Note: this says NaNs one place will be NaNs everywhere, just the precise choice of NaN bit pattern is unspecified.
So there is no issue “touching NaN”; the issue would be trying to pack some additional information into the fraction bits of the NaN, and expecting every implementation to treat it the same.
The game using Wasmer is currently fairly early in development, but we have a few games in production built using various technologies, with the most recent one that I worked on done entirely in typescript. Both this previous game and the upcoming game are fast-paced action games. As much as I enjoy typescript, there are lots of annoying things that crop up in game dev in particular with regards to memory management, such as needing to pool instances of small classes, etc, so I figured it's time to switch to rust+wasm since the ecosystem seems mature enough now for it and Rust is a joy to program in.
The architecture of the games are such that the main game logic runs both on the client and the server. The server runs the logic to provide the authoritative game state and send it out to all the clients, and the clients run the logic to predict where they're going to be immediately after you press an input to compensate for the network latency. Since the client is predicting what will happen using the same code paths, the game logic need to be completely deterministic so that it desynchronizes from the server as little as possible.
With the TS/JS game we essentially just hope that running the same JS bundle in node and any client browser produces the same results for all the collision/gameplay math, and it seems to luckily not cause us any problems. For the game in rust though, compiled and optimized native rust floating point math would drift from our client webassembly builds surprisingly quickly, so we decided to pack all the shared logic in to a wasm bundle that gets loaded on both the server and the client, and we're using Wasmer to do that :)
The Wasmer API is super ergonomic and it's been a pleasure to work with. I think the only thing that would make our lives better that I can think of is being able to ignore imports and have them auto-bind to noop functions or functions that immediately return zero in the case of non-void imports. Since we're using the same wasm bundle for the client and server, there's a bunch of client-only rendering bindings that we just ignore and never call from the server-only and shared wasm code in the bundle, and currently we're using a hacky script that uses wasm-objdump to generate a rust module with a bunch of noops in imports!{}.
> If you're new to the Wasmer community, you'll be delighted with the incredible performance that you can achieve with Wasmer 2.0, bringing your Wasm programs and libraries very close to native speeds.
Is there any set of benchmarks comparing Wasmer to native at a larger scale, real-life based examples?
It's a spec in addition to the initial we assembly spec. It's supported by clang/llvm, V8, firefox, and some standalone runtimes like wasmer.
SIMD for wasm is all 128bit operations. I've been working with it and so far it works pretty fast, but there's missing support for some operations. Namely lack of support for saturation/truncation operations.
Quick question about Wasmer and C programming: can I use Wasmer to compile a simple Hello World C program only once and then run this program on all supported architectures like I can use Cordova with Javascript to do the same?
Quickly exploring the wasmer-c-api examples just now[1], this does not appear to be the case: I get the impression one must write a bunch of high-friction boilerplate code to load/unload/configure/run wasm in order to do a simple hello world program. I have recently converted from being a C programmer to a Javascript programmer because I just can't deal with complicated C build systems and cross-compiling anymore: CMake, Gradle, etc. I spend more time trying to get a dependency to compile and learning the CMake language than I do actually solving my problem. People say "Electron is cancer" but at least I can get Cordova quickly working to ship an app for Windows/Mac/Linux/Android/iOS. I'd love to go back to lightweight, fast C programs though if I had the option. I tried using SDL2 but many of the examples will run fine on one platform but then fail to run on a different platform (say iOS or Android) and as a lone indie dev I don't have the time to investigate such issues. (I tried and managed to fix a few broken builds, but grew frustrated and gave up.) Cordova with Javascript so far is the only thing I've tried that just works for universal cross-platform dev.
The easiest way to compile C code to WebAssembly is by using Zig (https://ziglang.org): zig cc -target=wasm32-wasi and you’re done. Nothing else to install. It is equally easy to cross-compile to another platform, against without installing anything else.
Thanks! I see that Zig is much more than just a programming language then; it has its own C compiler that addresses much of the toil of cross compiling C code.
The impression that I get is that wasmer is more targeted towards people who want to embed a wasm runtime inside an existing application that they're building, whereas wasmtime is more meant to be used as a standalone program that runs WASI binaries directly. I think both projects support both use cases, but they seem to be geared that way.
- Not the same bakers (wasmtime is supported by the Bytecode Alliance nonprofit, which is behind the wasm specs, whereas wasmer is a startup)
- Not the same implementations, so not the same optimizations performances everywhere (you can see that a bit like clang vs GCC).
So which one to use depends on your tradeoffs. For me personally, I saw firsthand what an ecosystem tool could become once owned by a startup, and I would be very careful about this path.
There are more technical comparisons here and there if you look a bit (for example in /r/rust).
I'll not enter on the technical comparisons but more on the philosophical view of your comment.
Somehow you are not wary of an organization that is 90% directed by one entity.
It might be useful to know that 95%+ of the code changes in wasmtime are by people working in Fastly.
Google is the main pusher to Chrome, the fact that Google is a commercial entity doesn't make good or bad on how they move the ecosystem forward.
It makes it more effective.
I'm usually wary and careful when people advise for software and commercial value to be separated.
> Somehow you are not wary of an organization that is 90% directed by one entity. It might be useful to know that 95%+ of the code changes in wasmtime are by people working in Fastly.
I'm not overly worried about some companies investing more in communities than others, that's true, as long as there's some level of oversight (those 5% you mention).
I also suspect that a lot of those Fastly employees you mention came after the Mozilla layoffs we heard about a year ago, which I think invalidates a bit your point as the responsibilities were then shared before being unfortunately moved in to Fastly in short notice. It makes sense it would take time to address that perfectly, considering the context.
> Google is the main pusher to Chrome, the fact that Google is a commercial entity doesn't make good or bad on how they move the ecosystem forward. It makes it more effective.
That's not a great example - Chrome famously pushes changes without any oversight, which leads to useless APIs in the best cases to downright harm to their users in the worsts.
It's funny because the oversight in a startup is usually much bigger than in a big organization (the 5% mentioned is usually much, much bigger).
Their success depends so much on community that if fails to deliver, it dies. Thus it usually listens much more carefully. While other big organizations don't have that issue (in fact, they can go on much bigger losses just to capture markets).
What I wanted to showcase is that at the end, power (which usually means a stronger monetary input, which translates to how many people can work and experiment on new stuff) is what leads most of the changes, even if those changes are masked as organizations pushes or what not.
And to reinforce, its great to see Fastly pushing forward and doubling down on WebAssembly. Same as is great seeing Google pushing forward on the W3C standards. The advancements doesn't make it good or bad per se just because it's lead by one organization or another. It's what is delivered what matters.
> Somehow you are not wary of an organization that is 90% directed by one entity.
I'm wary about building on a project from a company whose CEO doesn't disclose they have a pre-existing grievance with the Bytecode Alliance related to:
1) Attempting to trademark "WebAssembly";
2) Inappropriate behaviour.
And who has previously:
3) Used sock-puppet accounts on HN in an attempt to Boost their project.
I'm very curious why Wasmer 2.0 can't deserialize modules that are serialized by Wasmer 1.0. Are they serializing to a non-spec complaint format? Are there extra custom sections that Wasmer 2.0 expects? This seems like a relatively small problem but I'm curious why it's there.
We use a custom serializer for serializing the metadata related to the WebAssembly module and other compilation information.
We changed the serialization mechanism to speed up startup speed and with that the incompatibility came.
Congrats on the release and thanks for the detailed post. I thought I'd share that, reading through it, I found that the 3D in the charts made them harder to read. You can still figure it out, but it's harder to understand at a glance.
Handling NaNs (Not a Number, usually referring to operations that trigger non arithmetic numbers, such as 0/0) was not optimally handled by Wasmer LLVM compiler.
We had a custom NaN "canonicalizer" that was always canonicalizing NaNs (that means: making sure the NaN bits were always the same in any chipset) regardless of use case and need. We took a look on how other runtimes were doing it more optimally and realized we could use LLVM intrinsic calls for math operations so LLVM would handle it directly.
Sorry about that! I was trying to explain it so people with little understanding could see how NaNs are handled/generated in a Wasm context (for example: 0/0 will trigger a NaN), but it's true that Infinite and NaNs are not the same. I'll correct my comment :)
I looked at the docs and running this shell script from internet is the only mentioned installation method.
Then I took a look at the script, it only supports bash, zsh and fish and will try to inject stuff in my shell config, add a new executable directory, and download and run an executable without even verify file checksum
I am sure there are many ways to install it securely. But why aren't any of them mentioned in the documentation? Besides searching the entire github organization, how can people discover these alternative installation methods?
Ah, I did miss this section when I was browsing the main repo, it is kinda difficult to spot, especially since the section is collapsed by default.
However, I was mainly talking about the documentation site, because documentation is always my first stop when exploring a new project. The README real estate on github is limited, but on the documentation site you have a whole page dedicated to describing how to install it, so I would love to see some installation methods there that are safer than blindly executing a random script from internet.
WebAssembly only supports i32, i64, f32, and f64 for the moment. So you need to allocate the string manually inside the Wasm memory, then pass the pointer of that string to the Wasm function.
I will add an example to showcase that, many people are asking this :-).
Would it be possible to make go functions that wrap string passing, and add them to the go api? Is freeing the memory manually inside the wasm vm something that can be delegated to the vm?
Walrus is great although because it was intended for editing existing WASM binaries and not being a WASM compiler backend, it has some limitations. For instance it can't easily generate recursive functions cause you need the function id before generating the function body and that's not easy in Walrus.
For what it's worth, I spent a bit of time setting up assemblyscript (basically typescript) compilation driven by a rust program (with the actual compilation happening in a js vm) not too long ago for an (unpublished) side project.
If that's something you'd be interested in I could see about reviving it and refactoring it out, or you could probably do the same from scratch, but it is a bit janky, and it sounds like you really want a backend for a homegrown compiler not an entire compiler.
I also think you might be able to use cranelift as the sort of backend you are looking for, but I haven't tried.
Its just me or it seems that Java is being reinvented again? With improvements, off course, but the whole thing looks like just another virtual machine, but this time directly connected to the web.
[1] https://github.com/WebAssembly/design/blob/main/Nondetermini...