[jariel]

It'd be interesting to get a true measure of the performance opportunities from WASM.

Every app has performance opportunities, but they usually not quite related to the raw performance of the language, usually, it's loading and backend latency.

People don't realize that V8 is really, really fast and always getting faster, and that WASM was never really super fast.

As V8 gets faster the delta opportunity for WASM is reduced at least in terms of raw, algorithmic performance.

[titzer]

I worked on both V8, Wasm, and Wasm in V8. The two have separate goals. V8's priority for JavaScript is to run the trillions of lines of JavaScript code found in the wild well and to support the language's evolution. It is no longer primarily about top-level throughput performance on computational kernels. Wasm has the goal of high, predictable performance for numeric-heavy, legacy-, and low-level code. Wasm is also focused on bringing more languages to the web that could reasonably be accomodated by a compile-to-JavaScript approach.

[jillesvangurp]

V8 is not the only implementation of WASM. Safari and Mozilla also provide implementations. Though Apple is probably dragging their feet here, Mozilla has been quite active with WASM development, supporting it in their browser, making sure Rust (which they created) can use it, and doing lots of developer support and outreach for WASM.

The word legacy is a bit biased here. From where I'm sitting, Javascript as implemented by browsers is increasingly the legacy language. Even most javascript webapps are actually transpiled to it. It's a compilation target more often than something people write natively. And as such it is used because until WASM came along, it was the only viable way to run anything on the web.

WASM provides developers a better compilation target that can ultimately support just about anything and already is used to run a wide variety of languages that have the ability to target it (in various stages of completion and maturity). Most mainstream languages at this point basically.

And of course WASM is not limited to the web. It's also showing up in edge computing solutions pushed by e.g. Digital Ocean, Cloudflare, etc. Many node.js applications can leverage WASM as well. It's probably used in a fair amount of desktop applications using electron, like VS Code for example. People are even experimenting with embedding wasm in operating system kernels and firmware even. It turns out that performance and sandboxing are very desirable properties in lots of places.

So, it's a general purpose runtime intended to sandbox and efficiently run just about any code. Including javascript interpreters ultimately. My prediction is that the latter will happen before the end of this decade and that Javascript will lose its status as a special language that is exclusively supported in browsers in addition to WASM. It will allow browser creators to focus on optimizing and securing WASM instead of WASM + Javascript.

[micrio]

I wholeheartedly agree with this. V8 is definitely incredible impressive and keeps improving. However Micrio uses a lot of low level Matrix4 maths, which is substantially faster in Wasm.

The second point is also great; having the base Micrio engine as a Wasm module now really makes me itch to use it in different environments. Perhaps I can use it in a serverside rendering flow, or even on an embedded device with a touch screen? Perhaps even as a native mobile app component in the future.

Also from the developer point of view it offers improvements over JS. Type/memory wise it gives more control. It's great to be able to use (u)int, f32 and f64 types, whereas with JS this is impossible from a coding perspective. The buffers passed from Wasm to WebGL are all Float32Arrays and are casted from f64's to f32's manually; giving me that 100% control instead of the black box that V8 gives.

[titzer]

Just for the record, the Wasm implementation in Chrome is a subsystem of V8. It's integrated into the main codebase and shares a lot of runtime services with the JavaScript support, primarily the optimizing compiler tier. So improvements to the (backend) of the optimizing compiler in V8 benefit both JavaScript and Wasm. There is also a baseline JIT compiler which is specifically built solely for faster Wasm startup and not used by JS.

The team (my former team) that maintains Wasm is a subteam of V8 and they all work together. This is unlike (P)NaCl which was both a separate team and a separate subsystem within Chrome. All of the former NaCl people work on Wasm now, primarily tooling and standards.

[maxgraey]

That's true. But wasm also required some extra codegen and optimizations for i64 types for example (also simd and atomics). In addition, wasm will have more specific CFG optimizations for WebAssembly. For example https://bugs.chromium.org/p/v8/issues/detail?id=11298

[jariel]

"predictable performance for numeric-heavy, legacy"

You mean all that 'legacy' C++ meant for the web?

Yes, I see what someone might mean, i.e Autocad able to re-use a lot of code, but those are small use cases.

And as for 'predictability' ... is it really predictable in application, given the amount of quasi-compilation that has to happen to get to WASM, and, more important, does it matter if it's predictable if it's slow, or rather, V8 is 'fast enough' in comparison?

The fact is, WASM is a Zombie Technology. It's odd that it continues to exist, like Bitcoin it has a few vested interests, and the 'dream' seems real, but there are just very few material uses cases, and the practical reality of doing anything functional with WASM is very small.

It's an intellectual concept, created without any specific customers/users in mind, and as such has very little adoption.

Because V8 is 'so good' and 'fit to purpose' and increasingly so (whatever stated objectives are), it means the real opportunity for WASM just fades.

Porting old C++ is a narrow case, and writing new C++ with a janky toolchain, and very limited ways to interact with networking, and UI ... all for what reason again?

[oscargrouch]

I think this line from the parent is right at the spot

> Wasm has the goal of high, predictable performance for numeric-heavy, legacy-, and low-level code

The OP was porting a application that is in the class of "numeric-heavy" so he had a good profit from his endeavor, as this is a right case for it.

In the low-level class there's great cases like porting MMPEG and using it straight from the browser. Of course it will be not as usable as a native application that links to MMPEG, but it will make a lot of cool things possible.

legacy: Now for instance Adobe could port Flash to WebAssembly with probably the same result. Or we could have that sweet atari emulator right in the browser.

This is not hyped as some other point of views that see WASM as a universal IR that will take the world.

I dout a lot of Javascript and Typescript code will have major benefits into porting to WebAssembly if they dont fall into one of those three categories, so most people dont need to see it as a menace, as Javascript is still being treated as a first-class citizen in the VM's.

[stagas]

V8 JS is equally fast or even faster for the same code after 3-4 runs. Cold paths, however, are usually 2 orders of magnitude slower than what you can achieve with WASM, for the same code. So it kind of depends on what you're building. Do you need a <5ms response at all times or can you live with an ~150ms response sometimes? 150ms randomly blocking code can be unacceptable for some cases and WASM doesn't suffer from that.

That said, you can't simply swap certain functions for WASM. There is an overhead for calling WASM functions, though very tiny - so if you're really going for performance then your app should be entirely living in WASM and interfacing directly with native browser APIs.

[jariel]

So that's a good point - however, in some recent benchmarks I've run V8 vs. JS code in GraalVM JS module, it seems that V8 does move to that optimal state fairly quickly, and 3-4 runs for a specific line of code is usually a small price to pay, given the alternative would be to use an entirely different stack, which even a decade in, barely integrates with the host environment - and - one must account for the inevitable 'bridging' costs between WASM and JS domains.

For example, some kind of 'pre optimized' 'JS engine byte code' that a regular JS engine could load as a module - which could be used by any other, regular JS code, would be considerably more optimal in terms of adapting to real world needs.

Oddly, that could probably be done right now if the world just happened to agree on a JS implementation like V8, I'm not suggesting we all do that, but at least we should be aware of the price we are paying.

I give WASM a 50/50 chance of becoming relevant, some of the new APIs may make a big difference, it remains to be seen if they do.

[stagas]

I agree, I'd love to be able to explicitly annotate a certain function for pre-optimization even if there was some initialization cost but that would also guarantee its performance throughout the app's lifetime. I'm not sure if that can be achieved with the dynamic nature of JS. Anecdotally also, in my benchmarks what I observe is that you get optimizations only for things that run consecutively i.e in a loop. When you switch to other paths and return it treats it like a cold path all over again. So when you're switching paths very often you may never get any optimization benefits and then the only option, at least for now, is to use WASM.

Also, all of this without ever mentioning GC, which is extremely hard to avoid using vanilla JS and will certainly cause hiccups.

I also agree that tooling around WASM could be improved but we should give it some time given that it's a fairly new thing (I think it's less than a decade even if you include asm.js). I believe it will become relevant not necessarily because it can run on the web, but because of the feature that it's a sandboxed target environment that is extremely portable. WASM runs almost everywhere already and I think that's it's main winning point and not so much the browser side.