The innermost rendering loop in the JS seems to create and destruct an array instance for every single pixel iteration (see https://github.com/dmaynard/chaos-screen-saver/blob/master/s... ). I guess that this could be potentially optimized away by the JIT, but it will make things slower or at least less predictable.
Comparing Rust and JavaScript
21–30 of 97 posts
Re: Comparing Rust and JavaScript
#22More of a comparison between WebAssembly and JavaScript, really. That the WebAssembly was compiled from Rust is not especially meaningful here.
The fact that it was written in Rust (or any other non-VM lang) is meaningful because programs written in a Language that needs a VM (All the GC'd languages for example) need the vm to be shipped as well. Thus, making the WASM-program larger and slower.
Re: Comparing Rust and JavaScript
#23The innermost rendering loop in the JS seems to create and destruct an array instance for every single pixel iteration (see https://github.com/dmaynard/chaos-screen-saver/blob/master/s... ). I guess that this could be potentially optimized away by the JIT, but it will make things slower or at least less predictable.
It would probably have to recognize that the _usage_ of this function can be translated into a local mutation without allocating additional arrays. But from just looking at the function locally it isn't clear whether that is a safe assumption.
Re: Comparing Rust and JavaScript
#24See https://surma.dev/things/js-to-asc/
Not that relevant, but it looks pretty terrible on a hi-dpi screen, it's probably not accounting for the pixel density when creating the canvas. Looks much better on a normal screen.
Re: Comparing Rust and JavaScript
#25The innermost rendering loop in the JS seems to create and destruct an array instance for every single pixel iteration (see https://github.com/dmaynard/chaos-screen-saver/blob/master/s... ). I guess that this could be potentially optimized away by the JIT, but it will make things slower or at least less predictable.
That's kind of an underrated aspect of these comparisons - while you absolutely can work around Javascript's weird performance cliffs and avoid putting pressure on the garbage collector, you have to fight the language at every turn because so many idiomatic JS patterns are inherently slow or flood the GC. You may find idiomatic JS easier to work with than something like Rust, but Rust is much easier to work with than…
Re: Comparing Rust and JavaScript
#26Earlier quoted context omitted.
The fact that it was written in Rust (or any other non-VM lang) is meaningful because programs written in a Language that needs a VM (All the GC'd languages for example) need the vm to be shipped as well. Thus, making the WASM-program larger and slower.
Go is a GC language, but it doesn’t need a VM. It’s a native, statically linked binary that contains the Go runtime.
Re: Comparing Rust and JavaScript
#27Re: Comparing Rust and JavaScript
#28Although it's obvious that you're comparing JavaScript and WASM performance, the devil is in the details. What exactly are you comparing?
There's quite a bit of overhead in calling out from WASM to the DOM; how are you making WASM faster? How much "JavaScript" is involved in the WASM version? Are you manipulating a Canvas? Generating a bitmap?
Re: Comparing Rust and JavaScript
#29JavaScript: https://github.com/dmaynard/chaos-screen-saver/blob/master/s...
Rust: https://github.com/dmaynard/rust-wasm-attractor/blob/master/...
Re: Comparing Rust and JavaScript
#30I get that the intended meaning is "JS sux", but I can't help being impressed with how performant engines are. The "pixels per ms" count ratio is less than 3:1 on my machine, in what I imagine is a CPU-heavy task.
I'd love for someone who knows this problem a little better to chime in, but this doesn't look like that heavy a task to me. I've read through the code very briefly. The core of the attractor logic[1] seems to be a few trig functions with a lot of bookkeeping around it (e.g. measuring performance to know how many iterations will fit within each frame budget, I think?). But each iteration depends on the state of previous iterations anyway (stored in module-globals[2]) so there's a data dependency that a CPU isn't going to have a great time with.
I'd be interested to know where most of the time is being spent in this program, but I don't think it's really playing to the strengths of Rust/WASM.
[1]: https://github.com/dmaynard/attractor-iterator/blob/b9274289... [2]: https://github.com/dmaynard/attractor-iterator/blob/b9274289...