6 ms·

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.

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. https://wasmedge.org/book/en/write_wasm/js.html#a-note-on-v8 https://wasmedge.org/book/en/write_wasm/js.html#a-note-on-v8 Whether it's faster or not really depends on the complexity of what's being run. After reading about wasmtime 1.0's super fast 5 microsecond snapshot restore time (https://bytecodealliance.org/articles/wasmtime-1-0-fast-safe-and-production-ready https://bytecodealliance.org/articles/wasmtime-1-0-fast-safe...) I did some experiments with QuickJS and Javy which runs QuickJS in wasmtime. Rendering a moderately complex web page with React renderToString production 30kB of html on my MacBook Air M1 took: - Deno first iteration: 12-20ms - Deno subsequent iterations: 2-4ms - qjs native: 18-24ms - javy (qjs wasmtime): 40-60ms I've not tried WasmEdge but it's JS performance would presumably fall somewhere between that of qjs native and under wasmtime. Firecracker claims a ~3ms snapshot restore time on ARM so might be the best way to go currently for such workloads but there is certainly a large subset of problems for which the current performance is adequate. There has been talk of AOT compilation for SpiderMonkey.wasm (https://bytecodealliance.org/articles/making-javascript-run-fast-on-webassembly https://bytecodealliance.org/articles/making-javascript-run-...) which I hope this will some day happen since it should close the gap substantially. I recently asked on the ByteCode Alliance Zulip but there hasn't yet been any progress and it requires a substantial amount of work.

azakai 4y ago
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.
- hutzlibu 4y ago
  "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.
  - azakai 4y ago
    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.)
    - galangalalgol 4y ago
      Does the engine store compiled binaries for the next time the page is loaded?
      - azakai 4y ago
        Some (most?) do, yes, here is a V8 article on that for example: https://v8.dev/blog/wasm-code-caching https://v8.dev/blog/wasm-code-caching
        galangalalgol 4y ago
        That seems to imply julia for wasm on chrome wouldn't have the "time to first plot" issue.
cmrdporcupine 4y ago
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 processing of customer jobs -- it's energy consumption as well.) There are already multiple runtimes that can run both WebAssembly and Javascript/TypeScript. The JS runtimes themselves. V8 does a great job of running both wasm and JS. And a custom V8 (or JavaScriptCore or whatever) embedding with appropriate sandboxing can be put together without a huge amount of work. Seems like the better peg for the hole in question if people want support for JS and WASM in a hosted environment.
- juntao 4y ago
  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 https://wasmedge.org/book/en/write_wasm/js/tensorflow.html In fact, we are using Rust to support the entire Node.JS API in WasmEdge. :)
  - cmrdporcupine 4y ago
    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/process.rs#L5 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.)
intelVISA 4y ago
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.
- rdtsc 4y ago
  Not OP but I was considering using it as well. I could see it going either way. If Fabrice stays interested in the project and keeps improving it, it could be a great win. If he moves on to other things, perhaps not. I've been looking at quickjs issues and forks and see a lot of random fixes from various people and most of them don't seem to be accepted or responded to: * https://github.com/bellard/quickjs/issues/131 https://github.com/bellard/quickjs/issues/131 * https://github.com/bellard/quickjs/issues/130 https://github.com/bellard/quickjs/issues/130 * https://github.com/bellard/quickjs/issues/129 https://github.com/bellard/quickjs/issues/129 * https://github.com/bellard/quickjs/issues/123 https://github.com/bellard/quickjs/issues/123 * https://github.com/bellard/quickjs/issues/111 https://github.com/bellard/quickjs/issues/111 * https://github.com/bellard/quickjs/issues/103 https://github.com/bellard/quickjs/issues/103 * https://github.com/bellard/quickjs/issues/96 https://github.com/bellard/quickjs/issues/96 The mailing list doesn't seem to have a lot of responses either. So, it's actually hard to say. The first instinct is it's great to base a product on such a talented programmer's work, but it seems you should be proficient enough to debug and fix issues yourself to do that. No blame or slight to Fabrice, of course, I am always impressed by his work, and he certainly doesn't owe anyone any of his time.
syrusakbary 4y ago
Interesting. Have you tried to benchmark it also with Wasmer [1]? I'd be curious to see what the timings might be. [1] https://wasmer.io/ https://wasmer.io/
- jeffparsons 4y ago
  I'm impressed — I don't think I've ever seen you miss an opportunity to promote your company. I assume you have some kind of keyword alert set up? Kudos on the mad hustle!
  - kumarski 4y ago
    Syrus is a technocrat's technocrat and a big open source contributor. I watch from the sidelines in awe as the community builds wasmer and the wasm ecosystem.
- laurencerowe 4y ago
  How is snapshot restore performance in wasmer?
  - syrusakbary 4y ago
    I guess you are referring to wizer [1]? (it's the closest to snapshot restore in the WebAssembly world). In case you are referring to that, the wizer strategy is valid for any Wasm runtime (and it will be fast once the Wasm module is snapshotted by wizer). If you refer towards Wasm module loading times (once a module is already been precompiled), Wasmer is already one of the fastest ones. https://github.com/bytecodealliance/wizer https://github.com/bytecodealliance/wizer

azakai 4y ago

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.

hutzlibu 4y ago
"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.
- azakai 4y ago
  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.)
  - galangalalgol 4y ago
    Does the engine store compiled binaries for the next time the page is loaded?
    - azakai 4y ago
      Some (most?) do, yes, here is a V8 article on that for example: https://v8.dev/blog/wasm-code-caching https://v8.dev/blog/wasm-code-caching
      - galangalalgol 4y ago
        That seems to imply julia for wasm on chrome wouldn't have the "time to first plot" issue.

cmrdporcupine 4y ago

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 processing of customer jobs -- it's energy consumption as well.) There are already multiple runtimes that can run both WebAssembly and Javascript/TypeScript. The JS runtimes themselves. V8 does a great job of running both wasm and JS. And a custom V8 (or JavaScriptCore or whatever) embedding with appropriate sandboxing can be put together without a huge amount of work. Seems like the better peg for the hole in question if people want support for JS and WASM in a hosted environment.

juntao 4y ago
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 https://wasmedge.org/book/en/write_wasm/js/tensorflow.html In fact, we are using Rust to support the entire Node.JS API in WasmEdge. :)
- cmrdporcupine 4y ago
  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/process.rs#L5 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.)

intelVISA 4y ago

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.

rdtsc 4y ago
Not OP but I was considering using it as well. I could see it going either way. If Fabrice stays interested in the project and keeps improving it, it could be a great win. If he moves on to other things, perhaps not. I've been looking at quickjs issues and forks and see a lot of random fixes from various people and most of them don't seem to be accepted or responded to: * https://github.com/bellard/quickjs/issues/131 https://github.com/bellard/quickjs/issues/131 * https://github.com/bellard/quickjs/issues/130 https://github.com/bellard/quickjs/issues/130 * https://github.com/bellard/quickjs/issues/129 https://github.com/bellard/quickjs/issues/129 * https://github.com/bellard/quickjs/issues/123 https://github.com/bellard/quickjs/issues/123 * https://github.com/bellard/quickjs/issues/111 https://github.com/bellard/quickjs/issues/111 * https://github.com/bellard/quickjs/issues/103 https://github.com/bellard/quickjs/issues/103 * https://github.com/bellard/quickjs/issues/96 https://github.com/bellard/quickjs/issues/96 The mailing list doesn't seem to have a lot of responses either. So, it's actually hard to say. The first instinct is it's great to base a product on such a talented programmer's work, but it seems you should be proficient enough to debug and fix issues yourself to do that. No blame or slight to Fabrice, of course, I am always impressed by his work, and he certainly doesn't owe anyone any of his time.

syrusakbary 4y ago

Interesting. Have you tried to benchmark it also with Wasmer [1]? I'd be curious to see what the timings might be. [1] https://wasmer.io/ https://wasmer.io/

jeffparsons 4y ago
I'm impressed — I don't think I've ever seen you miss an opportunity to promote your company. I assume you have some kind of keyword alert set up? Kudos on the mad hustle!
- kumarski 4y ago
  Syrus is a technocrat's technocrat and a big open source contributor. I watch from the sidelines in awe as the community builds wasmer and the wasm ecosystem.
laurencerowe 4y ago
How is snapshot restore performance in wasmer?
- syrusakbary 4y ago
  I guess you are referring to wizer [1]? (it's the closest to snapshot restore in the WebAssembly world). In case you are referring to that, the wizer strategy is valid for any Wasm runtime (and it will be fast once the Wasm module is snapshotted by wizer). If you refer towards Wasm module loading times (once a module is already been precompiled), Wasmer is already one of the fastest ones. https://github.com/bytecodealliance/wizer https://github.com/bytecodealliance/wizer