5 ms·

> I don’t expect the WASM translations to be much (or any) faster at the moment, but I do expect them to get faster over time, as the WASM engines in web browse

> I don’t expect the WASM translations to be much (or any) faster at the moment, but I do expect them to get faster over time, as the WASM engines in web browsers improve (just as JS engines have). I haven't been following WASM progress, do people generally share this optimism for WASM performance improvement over time, relative to JS? I was under the vague impression that all the "obvious" optimizations had already been done (i.e. JIT, and more recently, SIMD support)

deleted 2y ago
[deleted]
deleted 2y ago
[deleted]
afavour 2y ago
Yeah, I'd be surprised. I'm sure there are improvements to be made out there (e.g. maybe the sandbox could be faster) but the crazy leaps we've seen in JS performance are primarily because the complexity in the language makes for a very complex implementation with plenty of inefficiencies. By comparison WASM is already pretty close to the metal.
dgb23 2y ago
There seems to be alot of work going into WASM itself, much of it is performance related: https://github.com/WebAssembly/proposals https://github.com/WebAssembly/proposals
- mjhay 2y ago
  If only you could directly access the DOM or other browser APIs. I understand the GC proposal might help with this (?).
  - dgb23 2y ago
    I found a discussion with some explanations to why that is and what other solutions could be looked at: https://github.com/WebAssembly/design/issues/1184 https://github.com/WebAssembly/design/issues/1184
    - mjhay 2y ago
      Thank you. That helps with my confusion a lot.
    - andsoitis 2y ago
      ”The main reason is that direct access to the DOM requires the ability to pass references to DOM/JS objects through Wasm. Consequently, when GC happens for JavaScript, the collector must be able to find and update such references on the live Wasm stack, in Wasm globals, or in other places controlled by the Wasm engine. Hence the engine effectively needs to support GC in some form. However, the new proposal for reference types that we split off from the GC proposal tries to give a more nuanced answer to that. It introduces reference types without any functionality for allocating anything within Wasm itself. In an embedding where host references are garbage-collected that still requires a Wasm implementation to understand GC. But in other embeddings it does not need to.”
  - mason_mpls 2y ago
    As someone who wants WASM to free us all from JS. Is this even worth it if DOM bindings for WASM will never get a released? I’ve been following this since 2018 and it seems like we’re still at square 1 with DOM bindings. Incredibly frustrating.
tracker1 2y ago
I think it depends on what you are doing... I think there are huge opportunities for interop performance as well as just optimized process paths for certain things. I'm not that deep on the technical side, more of an avid observer. It just seems that as long as many things in WASM are slower than general performance for say Java or C#, that there is definitely room to improve things. As an example, looking at the in-the-box Garbage Collection support that's being flushed out, as an example will improve languages that rely on GC (C#, Java, Go, etc) without having to include an implementation for the runtime. Another point where there's potential for massive gains are the browser UI interop as well, and I think there's been a lot of effort to work within/around current limitations, but obviously there's room to improve.
Oreb 2y ago
> I was under the vague impression that all the "obvious" optimizations had already been done (i.e. JIT, and more recently, SIMD support) Aren’t threads still missing? That seems like a pretty major optimization, now that almost any CPU you can buy has multiple cores.
- aseipp 2y ago
  Yes, but they're very close to being standardized and have multiple existing implementations among different browser engines and also non-browser runtimes. (Of course, I don't think the threading proposal is exactly what OP had in mind for the case of general WASM perf improvements, but you are right it is in practice a big performance barrier in the bigger scheme.)
  - garaetjjte 2y ago
    Shared memory is standardized, you can run WASM threads in the browser through web workers. WASI threads standardization is in limbo because apparently component model is very important and nobody knows how threads will interact with that.
    - aseipp 2y ago
      Yes, I should have been more explicit: the raw WASM proposal only really defines how shared memory and cross-thread atomics work where it's assumed each thread runs a wasm module (with shared memory regions that are appropriately mapped.) It does not specify how the host environment actually spawns or manages threads or what hostcalls are available for that. That said I think in the browser something like emscripten can do something akin to "use web workers with shared array buffers" to back it all up so that threading APIs roughly work, but yes, WASI currently has nothing for this.
connicpu 2y ago
From my understanding, most of the WASM performance improvement expectations have been around the cost of calling browser APIs from within WASM. The performance itself is basically near native speed with a small overhead for the cost of bounds checking/wrapping the memory block. Last I checked, most WASM apps are calling DOM APIs through a javascript middleman, which obviously sucks for performance. But native importing of DOM APIs is something that I believe was being worked on and could be here soon?

deleted 2y ago

[deleted]

deleted 2y ago

[deleted]

afavour 2y ago

Yeah, I'd be surprised. I'm sure there are improvements to be made out there (e.g. maybe the sandbox could be faster) but the crazy leaps we've seen in JS performance are primarily because the complexity in the language makes for a very complex implementation with plenty of inefficiencies. By comparison WASM is already pretty close to the metal.

dgb23 2y ago

There seems to be alot of work going into WASM itself, much of it is performance related: https://github.com/WebAssembly/proposals https://github.com/WebAssembly/proposals

mjhay 2y ago
If only you could directly access the DOM or other browser APIs. I understand the GC proposal might help with this (?).
- dgb23 2y ago
  I found a discussion with some explanations to why that is and what other solutions could be looked at: https://github.com/WebAssembly/design/issues/1184 https://github.com/WebAssembly/design/issues/1184
  - mjhay 2y ago
    Thank you. That helps with my confusion a lot.
  - andsoitis 2y ago
    ”The main reason is that direct access to the DOM requires the ability to pass references to DOM/JS objects through Wasm. Consequently, when GC happens for JavaScript, the collector must be able to find and update such references on the live Wasm stack, in Wasm globals, or in other places controlled by the Wasm engine. Hence the engine effectively needs to support GC in some form. However, the new proposal for reference types that we split off from the GC proposal tries to give a more nuanced answer to that. It introduces reference types without any functionality for allocating anything within Wasm itself. In an embedding where host references are garbage-collected that still requires a Wasm implementation to understand GC. But in other embeddings it does not need to.”
- mason_mpls 2y ago
  As someone who wants WASM to free us all from JS. Is this even worth it if DOM bindings for WASM will never get a released? I’ve been following this since 2018 and it seems like we’re still at square 1 with DOM bindings. Incredibly frustrating.

tracker1 2y ago

I think it depends on what you are doing... I think there are huge opportunities for interop performance as well as just optimized process paths for certain things. I'm not that deep on the technical side, more of an avid observer. It just seems that as long as many things in WASM are slower than general performance for say Java or C#, that there is definitely room to improve things. As an example, looking at the in-the-box Garbage Collection support that's being flushed out, as an example will improve languages that rely on GC (C#, Java, Go, etc) without having to include an implementation for the runtime. Another point where there's potential for massive gains are the browser UI interop as well, and I think there's been a lot of effort to work within/around current limitations, but obviously there's room to improve.

Oreb 2y ago

> I was under the vague impression that all the "obvious" optimizations had already been done (i.e. JIT, and more recently, SIMD support) Aren’t threads still missing? That seems like a pretty major optimization, now that almost any CPU you can buy has multiple cores.

aseipp 2y ago
Yes, but they're very close to being standardized and have multiple existing implementations among different browser engines and also non-browser runtimes. (Of course, I don't think the threading proposal is exactly what OP had in mind for the case of general WASM perf improvements, but you are right it is in practice a big performance barrier in the bigger scheme.)
- garaetjjte 2y ago
  Shared memory is standardized, you can run WASM threads in the browser through web workers. WASI threads standardization is in limbo because apparently component model is very important and nobody knows how threads will interact with that.
  - aseipp 2y ago
    Yes, I should have been more explicit: the raw WASM proposal only really defines how shared memory and cross-thread atomics work where it's assumed each thread runs a wasm module (with shared memory regions that are appropriately mapped.) It does not specify how the host environment actually spawns or manages threads or what hostcalls are available for that. That said I think in the browser something like emscripten can do something akin to "use web workers with shared array buffers" to back it all up so that threading APIs roughly work, but yes, WASI currently has nothing for this.

connicpu 2y ago

From my understanding, most of the WASM performance improvement expectations have been around the cost of calling browser APIs from within WASM. The performance itself is basically near native speed with a small overhead for the cost of bounds checking/wrapping the memory block. Last I checked, most WASM apps are calling DOM APIs through a javascript middleman, which obviously sucks for performance. But native importing of DOM APIs is something that I believe was being worked on and could be here soon?