41–50 of 97 posts
If you have a few algs. you need to run under the hood, preferably with few cross domain calls, that can be expressed mostly using a small bunch of native types and not a lot of maps/string etc. then something low-level like WASM might help.
But that doesn't match most real world scenarios very well.
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.
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.
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 a custom $25 gizmo it's not a very comfortable one for general purpose programming.
To deliver a bit more, for example an allocator, you're bringing in a bunch of platform specific code, which, just like the Garbage Collector for Go, you did not write.
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…
In theory, static typing would correct the biggest performance issues in JS (use monomorphic functions, don't mutate objects, and limit arrays of just one primitive/object type).
In practice, TypeScript allows and encourages you to create types that are horrendous for performance.
I'd love to see a comparison using AssemblyScript (basically stricter TS for WASM). I'd bet it's nearly the same speed as Rust while still being a third of the size.
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.
It often is, but unless your code is purely numerical (in which case V8 is fast by default) you have write very awkward code to make JavaScript fast. On the other hand you can often transliterate JS code 1:1 into Rust and it'll be 10x faster.
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…
It was my understanding that the V8 GC frankly was rarely used, and that they generally just let memory pile up quite a lot before it's used, in the hopes that it may never have to be run during application lifetime.
Earlier quoted context omitted.
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 an interesting point. It was my understanding that the V8 GC frankly was rarely used, and that they generally just let memory pile up quite a lot before it's used, in the hopes that it may never have to be run during application lifetime.
Earlier quoted context omitted.
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 rust code is 3x as long and a lot more complex too. In theory, static typing would correct the biggest performance issues in JS (use monomorphic functions, don't mutate objects, and limit arrays of just one primitive/object type). In practice, TypeScript allows and encourages you to create types that are horrendous for performance. I'd love to see a comparison using AssemblyScript (basically stricter TS for WASM)…
This is a pretty good rundown of expected comparisons, but I doubt there will be any surprises here.
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?
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.