5 ms·

The biggest missing thing in my mind is threading support. Great performance isn’t very useful if it only runs on one core.

by et1337 4y ago

moss2 4y ago
> This allows for legacy applications to be ported to a browser and directly communicate with the JS code that runs in client-side Web applications. Knowing nothing about WebAssembly, I would guess it's because JS runs on a single thread.
- hermanradtke 4y ago
  This is only true on the browser. Server-side JS has threads: https://nodejs.org/api/worker_threads.html https://nodejs.org/api/worker_threads.html
  - koonsolo 4y ago
    On the browser you have Web Workers and Service Workers, both run on separate threads :). https://web.dev/workers-overview/#:~:text=Web%20workers%20and%20service%20workers%20%23&text=Both%20run%20in%20a%20secondary,limited%20access%20to%20browser%20APIs https://web.dev/workers-overview/#:~:text=Web%20workers%20an.... https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers... https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API https://developer.mozilla.org/en-US/docs/Web/API/Service_Wor...
    - kllrnohj 4y ago
      Those are really more like separate processes. There's no ability to do a shared heap in browser JS, meaning it functionally doesn't have threads. Whether or not workers are actually implemented as threads or processes in the runtime is irrelevant. As far as the JS code itself is concerned & what you can do with it, browser JS is lacking multi-threading. There's just no way to do a shared heap, and that is the biggest defining difference between a process and a thread.
      - afavour 4y ago
        The web has SharedArrayBuffer. It’s just difficult to work with.
        kllrnohj 4y ago
        Creating a shared memory allocation between 2 processes doesn't convert them to threads. The heaps are still distinct.
        azakai 4y ago
        The JavaScript heaps are distinct, that's true, but there is a single shared wasm heap which is used from multiple threads. That is enough to implement the pthreads API. Applications like Photoshop and Google Earth use ptheads on the Web so their compiled C++ is multithreaded, very similar to how it would run natively, and with similar responsiveness and throughput speedups. Though there are some limitations too, see https://emscripten.org/docs/porting/pthreads.html https://emscripten.org/docs/porting/pthreads.html
        flohofwoe 4y ago
        The entire WASM heap is a single ArrayBuffer (or SharedArrayBuffer) object.
        koonsolo 4y ago
        Practically speaking, you just want shared memory in your threads. What would a shared heap offer that shared memory can't?
  - mike_hearn 4y ago
    That's not really threading by the definition normally used in other languages. You can't allocate JS objects or structures and read/write them from multiple threads at once. JS is an inherently thread unsafe language and likely always will be.
ridruejo 4y ago
Threading support is already implemented in some browsers and well on its way to standardization https://webassembly.org/roadmap/ https://webassembly.org/roadmap/ Should address that concern. However there is another way of looking at performance and is in the context of serverless where typically single threaded performance is inportant, as well as cold start time etc and that’s why Wasm is popular in that scenario
- paulgb 4y ago
  “Threading support” in this sense is a bit of a misnomer, it’s really support for thread-safe memory constructs. Creating threads is left up to the runtime. On the web, this is done with WebWorkers, but on the server side I don’t think there is yet a standard way to do it supported by major runtimes.
  - melony 4y ago
    No shared memory options?
    - paulgb 4y ago
      There is a SharedMemoryBuffer, but it’s a web platform thing, not available in out-of-browser runtimes like wasmtime or wasmer or wasmedge (which Docker uses).
  - kllrnohj 4y ago
    > Creating threads is left up to the runtime. On the web, this is done with WebWorkers WebWorkers don't give you multi-threading behaviors (heaps/address spaces are not shared). WebWorkers would be how you launch a new process, but there's still otherwise no way to make a thread (nor even a fork() equivalent for that matter).
    - paulgb 4y ago
      I think you could share an address space by using the same SharedArrayBuffer to back the linear memory of both? I could be wrong here, I haven’t done it, but I thought this was the reason for supporting atomics in the first place. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
blacklion 4y ago
The biggest missing thing (for production) is observability. Look at old-good JVM. It has tons of tools to analyze and understand behavior of your production system. You could have thread dumps (stack traces of all existing threads) at any moment with negligible performance impact, you could dump heap and analyze it off-site, you could have tons of metrics, about each dark corner of mutexes, GC process, about JIT, including, if you need it, generated native code! Many of these thing you could get on production, not in sand-box. If you system behaves strangely, live-locks, consume more memory than you think it should, tharsh GC, you name it, you have all tools to understand what is wrong, find bugs or mis-configurations, etc. With all these new-and-shiny WASM and not-so-shiny JS VMs you mostly in the dark now. Service become unresponsive? latency goes to the roof? Only thing you could do - restart. It is not property of WASM per se, but this infrastructure is too immature now, comparing to 25+ year old technology.
- spreiti 4y ago
  This a 1000 times. People like to hate on Java but when there are problems to diagnose on production systems it is second to none. But from my experience most people don't know these tools even exist so the only thing they do is restarting and guessing where the problem might be if it persists.
  - cogman10 4y ago
    Flight recorder is a godsend and I've not seen it's equal in any other language/ecosystem. Any JVM anywhere can answer the question "why am I running slow" with a quick run of flight recorder. Memory, CPU, socket time, GC impact, TLB, thread dumps, etc. It's all there in one file that imposes something like a 1->2% performance impact if you run it constantly. It's just so good.
- ridruejo 4y ago
  Completely agree. Observability and debugging are some areas where the ecosystem is quite immature or inexistent. My take is that wasm is more or less where the web was in 97-98 Lots of excitement and possibilities but also lots of technical challenges and experimentation
dathinab 4y ago
"nice" threading support is not there but you can have threaded wasm code in any evergreen browser since a more then a year as far as I'm aware Basically the trick is that you use multiple web-workers with the same WAS program and the same shared buffer. Then you also add some JS glue code to coordinate which thread is the main thread and which threads you use as thread pool (e.g. in rust/wasm with rayon you can set it up as worker pool). Now there are some drawbacks (last time when I used it, might have gotten better): - threads are started/managed from outside (so don't expect any kind of "spawn" function to work, generally spawning new threads is non-trivial and so is (properly) cleaning up old threads, through if you need a fixed worker pool it's all fine) - there where some limitations wrt. threading/synchronization which made certain usages of concurrency rather slow (through many where fine) - no "synchronized" operations mustn't be called from WASM code called by the main JS thread. This means in most situations you need to pass data to web workers and then to WASM (instead of e.g. passing it to WASM and then using in wasm a mpmc-channel to pass it to the worker pool). There are some optimizations around passing pointers as numbers to/from the web-workers but it's limited and not nice. Or at least wasn't ~a year ago. - bugs in Safari leading to strange crashed for code running in all other browsers nicely under unclear and non-debuggable circumstances (probably fixed, I hope) Anyway all in all using rust->wasm with rayon and a thread pool was already surprisingly viable ~1 year ago.

The biggest missing thing in my mind is threading support. Great performance isn’t very useful if it only runs on one core.

by et1337 4y ago

The biggest missing thing in my mind is threading support. Great performance isn’t very useful if it only runs on one core.

moss2 4y ago

> This allows for legacy applications to be ported to a browser and directly communicate with the JS code that runs in client-side Web applications. Knowing nothing about WebAssembly, I would guess it's because JS runs on a single thread.

hermanradtke 4y ago
This is only true on the browser. Server-side JS has threads: https://nodejs.org/api/worker_threads.html https://nodejs.org/api/worker_threads.html
- koonsolo 4y ago
  On the browser you have Web Workers and Service Workers, both run on separate threads :). https://web.dev/workers-overview/#:~:text=Web%20workers%20and%20service%20workers%20%23&text=Both%20run%20in%20a%20secondary,limited%20access%20to%20browser%20APIs https://web.dev/workers-overview/#:~:text=Web%20workers%20an.... https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers... https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API https://developer.mozilla.org/en-US/docs/Web/API/Service_Wor...
  - kllrnohj 4y ago
    Those are really more like separate processes. There's no ability to do a shared heap in browser JS, meaning it functionally doesn't have threads. Whether or not workers are actually implemented as threads or processes in the runtime is irrelevant. As far as the JS code itself is concerned & what you can do with it, browser JS is lacking multi-threading. There's just no way to do a shared heap, and that is the biggest defining difference between a process and a thread.
    - afavour 4y ago
      The web has SharedArrayBuffer. It’s just difficult to work with.
      - kllrnohj 4y ago
        Creating a shared memory allocation between 2 processes doesn't convert them to threads. The heaps are still distinct.
        azakai 4y ago
        The JavaScript heaps are distinct, that's true, but there is a single shared wasm heap which is used from multiple threads. That is enough to implement the pthreads API. Applications like Photoshop and Google Earth use ptheads on the Web so their compiled C++ is multithreaded, very similar to how it would run natively, and with similar responsiveness and throughput speedups. Though there are some limitations too, see https://emscripten.org/docs/porting/pthreads.html https://emscripten.org/docs/porting/pthreads.html
        flohofwoe 4y ago
        The entire WASM heap is a single ArrayBuffer (or SharedArrayBuffer) object.
        koonsolo 4y ago
        Practically speaking, you just want shared memory in your threads. What would a shared heap offer that shared memory can't?
- mike_hearn 4y ago
  That's not really threading by the definition normally used in other languages. You can't allocate JS objects or structures and read/write them from multiple threads at once. JS is an inherently thread unsafe language and likely always will be.

ridruejo 4y ago

Threading support is already implemented in some browsers and well on its way to standardization https://webassembly.org/roadmap/ https://webassembly.org/roadmap/ Should address that concern. However there is another way of looking at performance and is in the context of serverless where typically single threaded performance is inportant, as well as cold start time etc and that’s why Wasm is popular in that scenario

paulgb 4y ago
“Threading support” in this sense is a bit of a misnomer, it’s really support for thread-safe memory constructs. Creating threads is left up to the runtime. On the web, this is done with WebWorkers, but on the server side I don’t think there is yet a standard way to do it supported by major runtimes.
- melony 4y ago
  No shared memory options?
  - paulgb 4y ago
    There is a SharedMemoryBuffer, but it’s a web platform thing, not available in out-of-browser runtimes like wasmtime or wasmer or wasmedge (which Docker uses).
- kllrnohj 4y ago
  > Creating threads is left up to the runtime. On the web, this is done with WebWorkers WebWorkers don't give you multi-threading behaviors (heaps/address spaces are not shared). WebWorkers would be how you launch a new process, but there's still otherwise no way to make a thread (nor even a fork() equivalent for that matter).
  - paulgb 4y ago
    I think you could share an address space by using the same SharedArrayBuffer to back the linear memory of both? I could be wrong here, I haven’t done it, but I thought this was the reason for supporting atomics in the first place. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

blacklion 4y ago

The biggest missing thing (for production) is observability. Look at old-good JVM. It has tons of tools to analyze and understand behavior of your production system. You could have thread dumps (stack traces of all existing threads) at any moment with negligible performance impact, you could dump heap and analyze it off-site, you could have tons of metrics, about each dark corner of mutexes, GC process, about JIT, including, if you need it, generated native code! Many of these thing you could get on production, not in sand-box. If you system behaves strangely, live-locks, consume more memory than you think it should, tharsh GC, you name it, you have all tools to understand what is wrong, find bugs or mis-configurations, etc. With all these new-and-shiny WASM and not-so-shiny JS VMs you mostly in the dark now. Service become unresponsive? latency goes to the roof? Only thing you could do - restart. It is not property of WASM per se, but this infrastructure is too immature now, comparing to 25+ year old technology.

spreiti 4y ago
This a 1000 times. People like to hate on Java but when there are problems to diagnose on production systems it is second to none. But from my experience most people don't know these tools even exist so the only thing they do is restarting and guessing where the problem might be if it persists.
- cogman10 4y ago
  Flight recorder is a godsend and I've not seen it's equal in any other language/ecosystem. Any JVM anywhere can answer the question "why am I running slow" with a quick run of flight recorder. Memory, CPU, socket time, GC impact, TLB, thread dumps, etc. It's all there in one file that imposes something like a 1->2% performance impact if you run it constantly. It's just so good.
ridruejo 4y ago
Completely agree. Observability and debugging are some areas where the ecosystem is quite immature or inexistent. My take is that wasm is more or less where the web was in 97-98 Lots of excitement and possibilities but also lots of technical challenges and experimentation

dathinab 4y ago

"nice" threading support is not there but you can have threaded wasm code in any evergreen browser since a more then a year as far as I'm aware Basically the trick is that you use multiple web-workers with the same WAS program and the same shared buffer. Then you also add some JS glue code to coordinate which thread is the main thread and which threads you use as thread pool (e.g. in rust/wasm with rayon you can set it up as worker pool). Now there are some drawbacks (last time when I used it, might have gotten better): - threads are started/managed from outside (so don't expect any kind of "spawn" function to work, generally spawning new threads is non-trivial and so is (properly) cleaning up old threads, through if you need a fixed worker pool it's all fine) - there where some limitations wrt. threading/synchronization which made certain usages of concurrency rather slow (through many where fine) - no "synchronized" operations mustn't be called from WASM code called by the main JS thread. This means in most situations you need to pass data to web workers and then to WASM (instead of e.g. passing it to WASM and then using in wasm a mpmc-channel to pass it to the worker pool). There are some optimizations around passing pointers as numbers to/from the web-workers but it's limited and not nice. Or at least wasn't ~a year ago. - bugs in Safari leading to strange crashed for code running in all other browsers nicely under unclear and non-debuggable circumstances (probably fixed, I hope) Anyway all in all using rust->wasm with rayon and a thread pool was already surprisingly viable ~1 year ago.