Wasmer 2.0
wasmer.io
wasmer.io
[1] https://github.com/WebAssembly/design/blob/main/Nondetermini...
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 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!{}.
Link to our Discord if you're interested in discussing this further: https://discord.gg/zUSZ3T8
Is there any set of benchmarks comparing Wasmer to native at a larger scale, real-life based examples?
A new round will be made soon.
It would also be great to have a benchmark in there that measures host <-> guest interaction with lots of guest -> host and host -> guest calls.
Deno is using the V8 engine, so is the performance expected to differ from Node?
Probably not but there’s one way to find out
I actually started working on a benchmark suite for various runtimes a while ago. I didn't get too far in, maybe you'd like to collaborate?
As wasm grows it would be great to have a comprehensive set of benchmarks to refer to.
Especially also for things that are unique to Webassembly, like reference types, cross calls, module instantiation time, ...
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.
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.
- 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).
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.
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.
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.
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.
All of which I learned as a result of reading this thread: https://news.ycombinator.com/item?id=24900186
In any case, context matters. I will be very happy the day that we no longer need gaslighting as a way to push certain projects or ideas forward :)
> [floating point math is faster] thanks to optimal management of NaNs
Curious what's involved here if someone from the team can chime in.
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.
If you are curious about the tech details, here's the PR! https://github.com/wasmerio/wasmer/pull/2161
Huh? This sounds totally incorrect to me.
> curl https://get.wasmer.io -sSfL | sh
No, thanks.
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
You can use cargo (it will compile from source):
cargo install wasmer-cli --features singlepass,cranelift
Or a package manager: brew install wasmer
You can check all available methods here. Hope this helps!https://github.com/wasmerio/wasmer-install#install-via-packa...
Do you think it will be useful to be showcased more prominently somewhere else?
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.
More specifically, here's how you can call Go host functions: https://github.com/wasmerio/wasmer-go/blob/master/examples/e...
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?
Any suggestion for ways to generate programatically with Rust?
https://www.reddit.com/r/rust/comments/nvxh12/for_building_a...
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.
Everything old, is new again...
The JVM and JVM bytecode was written with Java in mind, whereas WASM wasn't designed for a single language.