Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WebAssembly: Docker Without Containers

wasmlabs.dev

Post reply on HN
Print view View original

141–150 of 313 posts

Re: WebAssembly: Docker Without Containers

#141

Post by kllrnohj »

solomatov wrote: post #136

Does anyone has any links to recent benchmarks which show how large is the gap between WASM and native code? In theory WASM looks really great, but the last time I looked at it, the gap was big enough to be a concern.

The gap to native code will, most likely, always be there. Information is lost during the translation to WASM that an optimizer could have leveraged on the target architecture, not to mention WASM itself is adding overhead to satisfy the portability & security goals it is targeting.

Similarly WASM will always lag behind the state of the art for native code (eg, new SIMD or other accelerated instructions). That's the price of portability after all.

Re: WebAssembly: Docker Without Containers

#142

Post by runlaszlorun »

tony-allan wrote: post #2

If WASM+WASI existed in 2008, we wouldn't have needed to create Docker. That's how important it is. WebAssembly on the server is the future of computing. - Solomon Hykes (co-founder of Docker) https://twitter.com/solomonstre/status/1111004913222324225

I’m not anti-WASM but this quote is way overrused. It’s like the Godwin’s law of WASM…

Re: WebAssembly: Docker Without Containers

#143

Post by bzzzt »

pjmlp wrote: post #75
bzzzt wrote: post #74

Earlier quoted context omitted.

Dealing with the XML spaghetti from most Java EE containers isn't much better though.

- Schema validation - IDE code completion - Can be machine generated/updated via the GUI management administration and graphical tooling on IDEs Good luck doing that with YAML.

I'm perfectly capable of writing correct code by hand (be it XML or YAML), my problem is with the contents of the configuration files. Especially for the legacy Java EE servers there's loads of boilerplate stuff that has to be there for some reason but you don't have any idea why. Until something breaks and somewhere a magic setting has to be 'fixed'...

Re: WebAssembly: Docker Without Containers

#144

Post by kllrnohj »

koonsolo wrote: post #140
hermanradtke wrote: post #126

Earlier quoted context omitted.

This is only true on the browser. Server-side JS has threads: https://nodejs.org/api/worker_threads.html

On the browser you have Web Workers and Service Workers, both run on separate threads :). https://web.dev/workers-overview/#:~:text=Web%20workers%20an... . https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers... https://developer.mozilla.org/en-US/docs/Web/API/Service_Wor...

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.

Re: WebAssembly: Docker Without Containers

#145

Post by afavour »

kllrnohj wrote: post #144
koonsolo wrote: post #140

Earlier quoted context omitted.

On the browser you have Web Workers and Service Workers, both run on separate threads :). https://web.dev/workers-overview/#:~:text=Web%20workers%20an... . https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers... https://developer.mozilla.org/en-US/docs/Web/API/Service_Wor...

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 bigges…

The web has SharedArrayBuffer. It’s just difficult to work with.

Re: WebAssembly: Docker Without Containers

#146

Post by melony »

paulgb wrote: post #133
ridruejo wrote: post #129

Earlier quoted context omitted.

Threading support is already implemented in some browsers and well on its way to standardization 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

“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.

No shared memory options?

Re: WebAssembly: Docker Without Containers

#147

Post by kllrnohj »

afavour wrote: post #145
kllrnohj wrote: post #144

Earlier quoted context omitted.

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 bigges…

The web has SharedArrayBuffer. It’s just difficult to work with.

Creating a shared memory allocation between 2 processes doesn't convert them to threads. The heaps are still distinct.

Re: WebAssembly: Docker Without Containers

#148

Post by kllrnohj »

paulgb wrote: post #133
ridruejo wrote: post #129

Earlier quoted context omitted.

Threading support is already implemented in some browsers and well on its way to standardization 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

“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.

> 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).

Re: WebAssembly: Docker Without Containers

#150

Post by solomatov »

kllrnohj wrote: post #141
solomatov wrote: post #136

Does anyone has any links to recent benchmarks which show how large is the gap between WASM and native code? In theory WASM looks really great, but the last time I looked at it, the gap was big enough to be a concern.

The gap to native code will, most likely, always be there. Information is lost during the translation to WASM that an optimizer could have leveraged on the target architecture, not to mention WASM itself is adding overhead to satisfy the portability & security goals it is targeting. Similarly WASM will always lag behind the state of the art for native code (eg, new SIMD or other accelerated instructions). That's the…

But how large is this gap? I.e. 10%, 50%, 100% or 1000%. Size of this gap affects trade offs of using WASM vs native code a lot.
Post reply on HN