Live data from Hacker News

Nova: A JavaScript and WebAssembly engine written in Rust

trynova.dev

61–70 of 70 posts

Re: Nova: A JavaScript and WebAssembly engine written in Rust

#61
post #36

Earlier quoted context omitted.

Indeed, there's no guarantee that it will fit: I think it will but I don't know and want to find out. There are strong (IMO) reasons to think it will fit, though. User code can indeed do whatever but it rarely does. Programs written in JS are no less structured and predictable than ones written in C++ or Rust or any other language: they mostly operate on groups of data running iterations, loops, and algorithms over a…

I had the impression, ECS would boost performance mainly by allowing the systems to run in parallel on the entities. Isn't this kinda moot in a single threaded runtime?

ECS's main performance benefit comes from reducing cache misses.

Memory that's accessed together is stored together.

So for example, if you're calculating physics in a game, you perform all the needed physics operations on values stored contiguously in memory. Great cache locality means huge reduction in cache misses and performance benefits. If you had millions of entities and are performing each entity's set of operations (rendering, IO, AI, physics, etc) entity by entity, you might be getting a lot of cache misses.

There's an entire talk by Bob Nystrom (of crafting interpreters and game programming patterns) arguing you likely don't need to use ECS unless you have the exact problem of high cache miss rate.

Re: Nova: A JavaScript and WebAssembly engine written in Rust

#62

> Nova is a JavaScript (and eventually WebAssembly) engine written in Rust. Any particular reason against using Cranelift for WASM? https://cranelift.dev/ https://docs.rs/cranelift-wasm/latest/cranelift_wasm/

"[Nova] is currently nothing more than a fun experiment to learn and to prove the viability of such an engine"

Re: Nova: A JavaScript and WebAssembly engine written in Rust

#63
post #62

> Nova is a JavaScript (and eventually WebAssembly) engine written in Rust. Any particular reason against using Cranelift for WASM? https://cranelift.dev/ https://docs.rs/cranelift-wasm/latest/cranelift_wasm/

"[Nova] is currently nothing more than a fun experiment to learn and to prove the viability of such an engine"

Sure sure, but the ECS-style layout doesn't sound like it applies to a WASM engine like it does to JS.

Re: Nova: A JavaScript and WebAssembly engine written in Rust

#64

Earlier quoted context omitted.

Thank you! In a way I'm honestly surprised we've gotten that high, but on the other hand maybe it's not too crazy either: Kiesel engine (written in Zig) is at 75% and is pretty much the same age as Nova, and I believe has a similar sized "development team" (one person doing a lot of the work, LinusG for them and me on Nova's side, and then a smattering of other people with a bit less free time on their hands). We als…

I hope you make more progress on this! You’ve made it so far already!

I will! :)

But, an apology is also in order: the 70% number on our website is more misleading than I thought it is. Our test runner skips entirely Annex B[1] _and_ Intl tests; one could perhaps view the 70% number then as "percentage of ECMA262 specification done". The 58% value reported by test262.fyi is probably the correct value (unless we have a bug with debug prints that causes spurious failures there).

[1]: I remembered that we skip Annex B tests; those are fairly few in number and we pass 40% of them anyway, so their effect isn't large. Didn't remember the other category we skip, and absolutely didn't remember that it's a major one like Intl.

Re: Nova: A JavaScript and WebAssembly engine written in Rust

#65

Earlier quoted context omitted.

I hope you make more progress on this! You’ve made it so far already!

I will! :) But, an apology is also in order: the 70% number on our website is more misleading than I thought it is. Our test runner skips entirely Annex B[1] _and_ Intl tests; one could perhaps view the 70% number then as "percentage of ECMA262 specification done". The 58% value reported by test262.fyi is probably the correct value (unless we have a bug with debug prints that causes spurious failures there). [1]: I r…

That’s still really great progress!

Re: Nova: A JavaScript and WebAssembly engine written in Rust

#66

Earlier quoted context omitted.

That answers half my question (eg disable networking), thank you. The other part was about the overhead of adding this to an app (startup memory usage and increase in binary size) and how much work has been done on interop so that you can execute a static rust function Foo() passing in a rust singleton Bar, or accessing properties or methods on a rust singleton Baz, i.e. calling whitelisted rust code from within the…

So for executing static Rust functions we do have "full" support via the `Value::BuiltinFunction` type. We have an internal "BuiltinFunctionBuilder" type for creating these conveniently (mostly) at compile time, and we have some external helper functions for creating them at runtime. As for calling methods on a Rust singleton / struct, that is not yet really supported. We do have a `Value::EmbedderObject` type that w…

Thanks

Re: Nova: A JavaScript and WebAssembly engine written in Rust

#67

> Nova is a JavaScript (and eventually WebAssembly) engine written in Rust. Any particular reason against using Cranelift for WASM? https://cranelift.dev/ https://docs.rs/cranelift-wasm/latest/cranelift_wasm/

Hi, thanks for the question. No particular reason: it might be the one we settle on eventually. For now, Wasm hasn't been in my focus and thus hasn't received any work. When it does become a focus, it might rather be brought in as macro assembler kind of thing, based on the assumption that effectively all Wasm bytecode has been emitted by an optimising compiler and thus trying to reoptimise it is not worth it.

Maybe Cranelift might offer that out of the box? If so, it'd be a great choice. If it doesn't, or if the only lever to pull is simply a runtime "how much optimisations should we do" one then Cranelift might not be such a great choice, since we'd want to avoid bringing in big and heavy dependencies that only use a particular subset at runtime.

Re: Nova: A JavaScript and WebAssembly engine written in Rust

#68
post #62

Earlier quoted context omitted.

"[Nova] is currently nothing more than a fun experiment to learn and to prove the viability of such an engine"

Sure sure, but the ECS-style layout doesn't sound like it applies to a WASM engine like it does to JS.

Yeah, only place for ECS-style layout would probably be in the interpreter, but a Wasm interpreter might not be the thing one wants to do.

Re: Nova: A JavaScript and WebAssembly engine written in Rust

#69

Very interesting. Wondering how hard it is to embed / vendor it into other projects. In the past we relied on duktape especially because how easy it is to just copy one .c file into your project and have it integrated there. It's one of the best features of duktape that other JS engines couldn't yet beat. Do you have plans to maybe provide a collapsed version of nova that is especially easy for embedding into third p…

Embedding isn't a foremost concern currently, but it _is_ a concern. It is fairly likely that I might attempt embedding Nova (with minimal JS features) into a C++ application later this year; this work would probably result in the kind of collapsed version that you're asking for.

Re: Nova: A JavaScript and WebAssembly engine written in Rust

#70
post #6

Cache-friendly is nice, but honestly, are we at a point where that's the main bottleneck for most JS apps? Feels like every new runtime promises speed. What's the one thing Nova's gonna do that'll make everyone actually sit up and pay attention, beyond just benchmarks?

I honestly think it'll rather be memory usage, rather than performance.

Building an engine that benchmarks better than V8, SpiderMonkey, or JSC is a multi-year effort with a very high chance of failure. Maybe Nova's data-oriented heap design will give us a leg up on that, but it's still a massively challenging endeavour.

Building an engine with good benchmarks, an amazingly small memory footprint, and great cache-friendliness: that is the kind of engine I'm seeing in Nova. As you say, most JS apps are not bottlenecked by performance. Memory and complexity are the more likely bottlenecks; I believe I can improve the former fairly radically, and hopefully drive JS developers such as myself towards reducing the latter through opinionated engine design.

Post reply on HN