Live data from Hacker News

Comparing Rust and JavaScript

chaotic.netlify.app

81–90 of 97 posts

Re: Comparing Rust and JavaScript

#81
post #11

The difference in performance is about 3x and it looks like an pretty ideal case for wasm. Seems to match observations from Zaplip portmortem: > Rust is faster than JS in some cases, but those cases are rarer than we expected, and the performance gain is on the order of 2x some of the time, not 10x most of the time. https://zaplib.com/docs/blog_post_mortem.html

> pretty ideal case for wasm

It's not a bad use case for JS too. I'm sure there will be problems more biased into one of the languages than this.

Re: Comparing Rust and JavaScript

#82
post #66

Rust is a great solution to the memory safety problem, but is more difficult to use and slower to compile than some other languages. I'm wondering why I would use Rust for WebAssembly, which doesn't have memory safety issues?

> which doesn't have memory safety issues

What exactly do you mean by that? WASM is assembly, the memory management is entirely manual, and it's currently a very bad target for garbage collection.

Anyway, Rust has more advantages than memory safety.

Re: Comparing Rust and JavaScript

#83
post #17

Earlier quoted context omitted.

I wouldn't say the source language is not meaningful. If you wrote an ahead-of-time JavaScript-to-WebAssembly compiler and benchmarked the WASM generated by that, it would probably be a lot slower than the WASM generated by the Rust compiler, no?

Has anyone compiled v8 to WASM so we can finally run JS in the browser? ;)

please don’t give them more ideas

Re: Comparing Rust and JavaScript

#84
post #50
post #8

It's nice to see how much faster is wasm. This kind of problem would also be nice for parallelization. What's the state of multi-threading wasm? any advantage over javascript web workers?

https://webassembly.org/roadmap/ Atomics have universal support in modern browsers. This is primarily a single-threaded problem. Each x and y update depends directly on the previous x and y values with the x and y being used to update pixels. At most (barring changes to the algorithm), it looks like you could calculate these on one thread and update the image on another thread.

It’s true that the problem of generating the exact same image seems to be a single-threaded problem. But I suppose the general problem of rendering an approximation of a strange attractor could be parallelized by generating images from several different starting positions and combining them.

Re: Comparing Rust and JavaScript

#85
post #17

Earlier quoted context omitted.

I wouldn't say the source language is not meaningful. If you wrote an ahead-of-time JavaScript-to-WebAssembly compiler and benchmarked the WASM generated by that, it would probably be a lot slower than the WASM generated by the Rust compiler, no?

Has anyone compiled v8 to WASM so we can finally run JS in the browser? ;)

v8 is a JIT engine, WASM would not support it.

JavaScriptCore has been compiled to WASM though:

https://mbbill.github.io/JSC.js/

People usually ask why, the answer is usually for fun or for sandboxed plugins.

Re: Comparing Rust and JavaScript

#87
My conclusion from this is that Firefox seems to be much faster than Chrome-based browsers when it comes to WASM. I have noticed this trend before.

I would be more interested in a more realistic test with scenarios replacing web frameworks like React. This benchmark seems more like something you would do with shaders anyway.

Re: Comparing Rust and JavaScript

#88
post #61

More of a comparison between WebAssembly and JavaScript, really. That the WebAssembly was compiled from Rust is not especially meaningful here.

From the user-experience perspective, it matters that it is Rust. Unless you directly write WASM code, which is rarely (ever) the case. Rust is a language that compiles to WASM. Sure, there are other options to compile to WASM, but they differ by interface (programming language, library, tooling) and (likely to a lesser degree) - performance.

> From the user-experience perspective, it matters that it is Rust.

From the user-experience perspective, none of the page loads without javascript, so it is all javascript from a customer's perspective.

Re: Comparing Rust and JavaScript

#89
post #60

Earlier quoted context omitted.

Sure, but Rust can have a runtime, and presumably Rust on WASM does. If you don't have a runtime in Rust you only get core. https://doc.rust-lang.org/core/ This has obvious effects (you don't have an allocator so you can't have String) and more subtle effects (your slices don't have a sort() method! However they do have a sort_unstable() method) but while it's probably a reasonable environment for the firmware inside…

IIRC every higher level language has some runtime, even C. Question is, how trivial/substantial is it?

Like Rust, C defines what happens if you don't have its rich standard runtime, you get "free standing" C.

C's free standing mode is even thinner than Rust's core, because it doesn't supply a library of code, you just get the primitive types, the operators and the language features that don't involve any libraries. To give a very concrete example, Rust's core depends on memcmp() existing, Rust assumes your toolchain knows how to memcmp() on your target architecture inherently, but in C you could write memcmp() if you had to. You won't these days, because your C compiler invariably provides this feature, but in principle you could.

In principle C++ also defines a "free standing" mode, but it's a mess and so people don't write for C++ free standing mode in the real world. C++ in an environment where you can't have the actual standard library is likely to be specified in terms of which features from the standard library you can have and which you cannot, for each such environment. For example maybe you can have threading but no filesystem APIs, or you can have a heap allocator but no threads.

Re: Comparing Rust and JavaScript

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

Are these Peter de Jong attractors?

I'm trying to work out how my interpretation of the calculations (in JS)[1] compare with the authors code, but trying to measure performance in CodePen is ... difficult to work out. My approach was to: 1. Run the CodePen with the inspector open; 2. Start recording performance; 3. Right click on the display panel and select 'Reload Frame'; 4: Stop recording performance after the images reappear.

... But when I look at the results nothing is making sense. Clearly my approach was wrong.

[1] - https://codepen.io/kaliedarik/pen/JjRJwNa

Post reply on HN