Live data from Hacker News

Comparing Rust and JavaScript

chaotic.netlify.app

21–30 of 97 posts

Re: Comparing Rust and JavaScript

#21
post #16

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.

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 the narrow and loosely defined subset of JS that you have to stick to for optimal performance. Taken to its limit you end up more or less writing asmjs by hand.

Re: Comparing Rust and JavaScript

#22
post #20

More 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.

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

#23
post #16

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.

Why do you think the JIT would be able to optimize this? And how would it go about it? I know only about a few rough things and heuristics. I wouldn't expect or assume that this would be optimized.

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

#24
These comparisons are always highly biased by the kind of work being done. V8 is so good at optimizing code, it's usually possible to reach similar performance in JS.

See 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

#25
post #21
post #16

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.

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…

That's a really good point and I think that in this sense the comparison is really made between Rust and JS rather than between WASM and JS (as others have complained).

Re: Comparing Rust and JavaScript

#26
post #20

Earlier 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.

Maybe Runtime or Runtime System is a better word than VM? Go has _something_ that manages Go routines and GC and so on.

Re: Comparing Rust and JavaScript

#27
post #26

Earlier quoted context omitted.

Go is a GC language, but it doesn’t need a VM. It’s a native, statically linked binary that contains the Go runtime.

Maybe Runtime or Runtime System is a better word than VM? Go has _something_ that manages Go routines and GC and so on.

[deleted]

Re: Comparing Rust and JavaScript

#28
I wish there was an "about" blurb. Perhaps 2-6 paragraphs explaining what's going on?

Although 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

#30
post #7

I 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.

> 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...

Post reply on HN