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

WasmEdge

wasmedge.org

Post reply on HN
Print view View original

21–30 of 88 posts

Re: WasmEdge

#21

Post by hutzlibu »

azakai wrote: post #8
laurencerowe wrote: post #6

Interesting to see that it has JavaScript support built in. It seems to be based on QuickJS which will work for some things but as they acknowledge quite slow. > In the end, running v8 in a cloud-native environment often requires a full stack of software tools consisting of "Linux container + guest OS + node or deno + v8", which makes it much heavier and slower than a simple WasmEdge + QuickJS container runtime. http…

Another thing that would be interesting to measure here is memory usage. QuickJS might be slower (as a minimal interpreter) but at least it should be much smaller than a full optimizing JS engine (running normally or compiled to wasm), both in terms of code size and runtime memory usage. That might matter in some cases.

"at least it should be much smaller than a full optimizing JS engine, both in terms of code size and runtime memory usage"

Why should QuickJS use less runtime memory?

Genuine question, I just recently learned of QuickJS and what I understand, it is way smaller in itself, meaning you do not need so much memory for the engine itself, but that does not say anything how efficient it is with executing js code. Or are there benchmarks that say, it is also more memory efficient with executing js?

Either way, yes, I also think meassuring memory is important.

Re: WasmEdge

#22

Post by juntao »

pjmlp wrote: post #19

This was Edge before WASM. https://www.sunspotdev.org/ https://www.parallax.com/propeller-multicore-concept/ https://en.wikipedia.org/wiki/Netduino

We are hoping to get WasmEdge running on as many IoT devices as possible …

We would love to see more containerization on the edge:

https://www.cncf.io/blog/2021/11/11/containerization-on-the-...

Re: WasmEdge

#23

Post by cmrdporcupine »

juntao wrote: post #20
cmrdporcupine wrote: post #10

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…

Disclaimer: I am a maintainer at WasmEdge. One of the benefits of running JS in Wasm (specifically the QuickJS approach) is that you can create JS APIs in Rust. That allows you to move a lot of compute intensive operations into Rust while still giving your developers a clean and nice JS API. WasmEdge does this with its JS Tensorflow API: https://wasmedge.org/book/en/write_wasm/js/tensorflow.html In fact, we are using…

Not to denigrate your work, it's good what you're working on... but I can create JS APIs in Rust with native V8 bindings, too: https://github.com/denoland/rusty_v8/blob/main/examples/proc...

After working on a couple codebases that used wasmtime and wasmer heavily, I think if I were to start from scratch I'd just use V8 as my WASM runtime.

(And the model I would follow would be to containerize the V8 runtime piece inside its own cgroup, with resource budgets and permission constraints. cgroups accounting beats the limited and inefficient accounting one gets from the various WASM runtime opcode based accounting systems.)

Re: WasmEdge

#24

Post by laurencerowe »

cmrdporcupine wrote: post #10
laurencerowe wrote: post #6

Interesting to see that it has JavaScript support built in. It seems to be based on QuickJS which will work for some things but as they acknowledge quite slow. > In the end, running v8 in a cloud-native environment often requires a full stack of software tools consisting of "Linux container + guest OS + node or deno + v8", which makes it much heavier and slower than a simple WasmEdge + QuickJS container runtime. http…

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 Firecracker is somewhat annoying since it requires support for nested virtualization (doesn't work on Mac M1 or AWS, though does on GCP and GitHub Codespaces. The M2 has hardware support so development on Mac should work eventually.)

The various WebAssembly runtimes have really put a lot of work into getting fast snapshot restore with Wasmtime 1.0 doing so in microseconds. I'd love to be able to run server rendering in such an environment.

Re: WasmEdge

#25

Post by joezydeco »

juntao wrote: post #13
cyanydeez wrote: post #3

Seems like the edge is just SaaS microservices. Change my mind.

I am a maintainer at WasmEdge. :) The name “edge” signifies that it is lightweight. We think it is a lightweight and secure alternative to Linux containers. The application use cases include containerization on edge devices, serverless functions on edge cloud, embedded functions for databases or SaaS, stream functions for data pipelines, or even smart contracts for blockchains. All of the above are “edge” use cases i…

How do I use this on a bare metal Cortex-M with no filesystem or networking?

Re: WasmEdge

#26

Post by politelemon »

juntao wrote: post #18
politelemon wrote: post #11

I got a bit bewildered by the quick start documentation. It starts by showing how to install and uninstall, followed by running it in different execution environments, it seems to be expecting that you already know what wasmedge is. That's unexpected, as usually a quickstart shows how to write and run a simple application.

Will improve! Thanks! One of the challenges is that Wasm supports multiple languages. So, we will have to decide to start from a Rust app or a JS app or something else. Would love your suggestions.

Thanks. I think JS would be a good option since it's a common language for web developers, who are most likely to be the target audience.

Re: WasmEdge

#27

Post by azakai »

hutzlibu wrote: post #21
azakai wrote: post #8

Earlier quoted context omitted.

Another thing that would be interesting to measure here is memory usage. QuickJS might be slower (as a minimal interpreter) but at least it should be much smaller than a full optimizing JS engine (running normally or compiled to wasm), both in terms of code size and runtime memory usage. That might matter in some cases.

"at least it should be much smaller than a full optimizing JS engine, both in terms of code size and runtime memory usage" Why should QuickJS use less runtime memory? Genuine question, I just recently learned of QuickJS and what I understand, it is way smaller in itself, meaning you do not need so much memory for the engine itself, but that does not say anything how efficient it is with executing js code. Or are ther…

Optimizing VMs often use lots of memory for various reasons. Specific costs in modern optimizing VMs include the memory for the JITed code, and with multiple tiers you end up JITing each function more than once. You also need memory to save information about which functions to tier up (a call count or something more refined). Even things like polymorphic inline caches have a cost, the space for each of those PICs, and the code around them.

A simple interpreter can avoid all those. It can build a very simple and compact bytecode and just execute that.

(But, of course, the speedups in optimizing JITs are usually worth it! 10x or more.)

Re: WasmEdge

#28

Post by nerpderp82 »

frutiger wrote: post #15
nerpderp82 wrote: post #2

Given the amount of C++ in this project, I wouldn't run this in an adversarial environment. Meaning, I would not accept untrusted Wasm modules. It is about 100kloc of C/C++ including headers.

I would sincerely be curious to know how many “kloc of C/C++” you are already running in an adversarial environment and how much of a dent this project would make.

How much of a dent (non-quantitative) it would make, depends on how it is deployed. In my environment, the risk of WasmEdge outweighs its advantages.

By that argument there is no difference between 80% and 85% or 1% and 2%. One should absolutely reduce their attack surface. If the goal is to be "lightweight" as compared to containers, then WasmEdge would be running as a regular OS process and not in a jail or cgroups container. By construction, WasmEdge has a greater threat model vs rootless containers. I am huge fan of Wasm, but my appreciation for a technology doesn't outweigh the risk posed by the runtime. Its security properties are intractable.

Are you saying that end users should overlook this?

Re: WasmEdge

#29

Post by nerpderp82 »

juntao wrote: post #16
nerpderp82 wrote: post #2

Given the amount of C++ in this project, I wouldn't run this in an adversarial environment. Meaning, I would not accept untrusted Wasm modules. It is about 100kloc of C/C++ including headers.

I am a maintainer of the WasmEdge project. Yes, it is written in C++ for two reasons: 1 C++ apps can run a lot of edge hardware devices and OSes. We are running on RTOS like seL4 and CPUs like RISC-V. 2 There are already two leading Wasm runtimes written in Rust when we started. We thought runtime diversity is important from security and reliability point of view. It is indeed more challenging to run C++ programs sec…

Besides fuzzing, what other security measures does WasmEdge use? Is it able to use memory protection on platforms where it is available?

Re: WasmEdge

#30

Post by intelVISA »

laurencerowe wrote: post #6

Interesting to see that it has JavaScript support built in. It seems to be based on QuickJS which will work for some things but as they acknowledge quite slow. > In the end, running v8 in a cloud-native environment often requires a full stack of software tools consisting of "Linux container + guest OS + node or deno + v8", which makes it much heavier and slower than a simple WasmEdge + QuickJS container runtime. http…

Interesting gamble to build a whole company on top of what is effectively a wrapper for Bellard's work (qjs), wonder how it'll play out.
Post reply on HN