Live data from Hacker News

WasmEdge

wasmedge.org

71–80 of 88 posts

Re: WasmEdge

#71

Earlier quoted context omitted.

While I appreciate your comparison pages for highlighting the strengths of wasmer, they really do avoid talking about any of the metrics where wasmer isnt top performer. IMHO this doesnt really give me the information I need to make a decision. For example, the wasmedge website claims it is the fastest runtime but I notice that your comparison page doesnt mention runtime performance at all. It would be nice to know h…

> For example, the wasmedge website claims it is the fastest runtime but I notice that your comparison page doesnt mention runtime performance at all. It would be nice to know how much slower is wasmer in that respect. The places where there are no differences between runtimes are not showcased in the shared page intentionally. Runtime performance it's not hidden because Wasmer is slower, it's hidden because there sh…

Thanks Syrus - I think this is exactly why you should expand on the comparisons. A lot of users without your experience of the internals will be looking to these comparisons for information - being able to explain things like this would go a great way to clearing up misconceptions.

Re: WasmEdge

#73
post #44
post #43

Why use a WASM VM when there are more mature VMs out there like .net/CLR? What's the benefit?

I can think of a few: * Lightweight (no GC, under 2MB) * Designed to be a secure sandbox (not just a language runtime) * Modular (add host functions as needed — eg support for Tensorflow) * Multiple languages (esp compiled languages like Rust) * Works with container tools (Docker, k8s etc)

Lightweight (no GC, under 2MB) => Which is why all GC based languages are forced to bring their own GC when targeting WASM.

Designed to be a secure sandbox (not just a language runtime) => JVM and CLR also were designed as such. It didn't work out as well as planned, when black hat hackers started researching how to game the sandbox. Still open for WASM.

Modular (add host functions as needed — eg support for Tensorflow) => JVM and CLR have dynamic code loading capabilities. WASM still hasn't standardized dynamic linking

=> Multiple languages (esp compiled languages like Rust) => Just like CLR, hence why it is Common Language Runtime, C and C++ were part of version 1.0 release.

Works with container tools (Docker, k8s etc) => Just like JVM and CLR do.

Re: WasmEdge

#74

Earlier quoted context omitted.

I remain mystified about the value of running JS inside a wasm VM. I see why people want to go there, because they want one tool to rule them all, but I don't get the actual value add. WASM hasn't been built for this. Not yet. You'll be running the garbage collector, compiler, bytecode interpreter fully in an emulated environment. There's bound to be overhead. For no reason. (And remember overhead isn't just slow pro…

My interest comes from wanting to see more performant options for per-request isolation in JavaScript applications. There have been bugs on popular web services returning information for the wrong user caused by inadvertently using global or module level variables. Isolates are one option but I believe startup time for isolates with a snapshot is actually slower than Firecracker's snapshot restore. Developing with Fi…

You could take a look at GraalJS. It supports its own form of isolates and they can be created very fast, because an isolate setup is basically mmapping the pre-calculated heap into another area of memory and starting up another thread. I never measured it but it shouldn't be particularly slow. It also means you can mix languages.

Re: WasmEdge

#75
post #50

WASI development is very slow. Bytecodealliance is kinda all the big names but it seems not a lot of investment to hire more people working on the spec (I know at some point more people won't work, but right now there are only a few)

I work on Wasi at Fastly, as part of the Bytecode Alliance. WASI development has indeed been quite slow. Most of our efforts for the past 2 years have been developing and implementing the Component Model proposal. Right now we are working on porting WASI to the component model, which has been pushing all of the new wit tooling more than it has WASI itself. I can’t really say that adding more people would have sped up…

"the first credible open (as in, not owned by Oracle or MS) standard for a real cross language VM"

It's great that you're developing WASI but I don't see how it's any more open than the JVM or .NET CLR. Obviously from a licensing perspective it's not any different, anyone can go implement the JVM or CLR specs. In the past the JVM and Java even had a rather complicated community process designed to disempower Sun, some aspects of which remain today.

It sounds like WASM/WASI is something similar but with Fastly being the dominant company instead of Oracle/MS. I went to the bytecodealliance github repo and picked a random repository with "wasi" in the name and looked at the last commit. It was by someone who works at Fastly. Technical specs always have some firm or another pushing more than others at any given point, that's not what determines if they're open or not.

Also, both the JVM and CLR have had support for mutually distrusting components from the start, so that's not really new either. That support didn't get widespread use because sandboxing even at the process level for individual apps is still rather rare, and sandboxing at the sub-component level proved too hard to get right with the CLR/JVM approach. It's probably better to argue that what you're doing with WASI is better in some concrete technical sense rather than arguing it's new.

Re: WasmEdge

#76
> Compared with Linux containers, WebAssembly runtimes achieve higher performance with lower resource consumption.

I keep seeing this kind of statement, but is it actually true? Are there any good benchmarks around this?

Re: WasmEdge

#77

How does this compare to wasmtime, wasmer, etc? Why would I choose one over the other?

WasmEdge contributor here.

Performance benchmarking is complicated. We have published peer reviewed studies that show WasmEdge is the fastest in some cases. Would love to see how it performs on your workloads.

Re: WasmEdge

#78

How does this compare to wasmtime, wasmer, etc? Why would I choose one over the other?

WasmEdge contributor here. Performance benchmarking is complicated. We have published peer reviewed studies that show WasmEdge is the fastest in some cases. Would love to see how it performs on your workloads.

Where can I find these studies? The only one I can see mentioned on the website is using runtimes over 2 years old and doesnt include either wasmtime or wasmer (which are, AFAIK, the other major runtimes at present).

Re: WasmEdge

#79
post #76

> Compared with Linux containers, WebAssembly runtimes achieve higher performance with lower resource consumption. I keep seeing this kind of statement, but is it actually true? Are there any good benchmarks around this?

WasmEdge contributor here. We had some last year.

Paper: A Lightweight Design for High-performance Serverless Computing, published on IEEE Software, Jan 2021. https://arxiv.org/abs/2010.07115

Article: Performance Analysis for Arm vs. x86 CPUs in the Cloud, published on infoQ.com, Jan 2021. https://www.infoq.com/articles/arm-vs-x86-cloud-performance/

Source code of test cases: https://github.com/second-state/wasm32-wasi-benchmark

See if these helps. (Kinda old so will be needing more updated ones)

Re: WasmEdge

#80

Earlier quoted context omitted.

WasmEdge contributor here. Performance benchmarking is complicated. We have published peer reviewed studies that show WasmEdge is the fastest in some cases. Would love to see how it performs on your workloads.

Where can I find these studies? The only one I can see mentioned on the website is using runtimes over 2 years old and doesnt include either wasmtime or wasmer (which are, AFAIK, the other major runtimes at present).

We did benchmarks last year but not recently (Will update if there are new ones).

Paper: A Lightweight Design for High-performance Serverless Computing, published on IEEE Software, Jan 2021. https://arxiv.org/abs/2010.07115

Article: Performance Analysis for Arm vs. x86 CPUs in the Cloud, published on infoQ.com, Jan 2021. https://www.infoq.com/articles/arm-vs-x86-cloud-performance/

Source code of test cases: https://github.com/second-state/wasm32-wasi-benchmark

Post reply on HN