6 ms·

Comparing Rust and JavaScript

107 points by orixilus 4y ago

N-Krause 4y ago
Can someone explain what exactly I am looking at here? The about page seems to be an empty page for me.
- substation13 4y ago
  https://github.com/dmaynard/chaos-screen-saver/blob/master/README.md https://github.com/dmaynard/chaos-screen-saver/blob/master/R...
- conqueso 4y ago
  Maybe you have an ad blocker on or something? The about button links here: https://github.com/dmaynard/chaos-screen-saver/blob/master/README.md https://github.com/dmaynard/chaos-screen-saver/blob/master/R...
- ostenning 4y ago
  Compares the rendering speed of Javascript/ES-6 to WASM compiled from Rust. Result: JS/ES-6: ~4000 pixels per millisecond. WASM/Rust: ~16000 pixels per millisecond. These results are on Firefox using M1 Max
montroser 4y ago
More of a comparison between WebAssembly and JavaScript, really. That the WebAssembly was compiled from Rust is not especially meaningful here.
- Banana699 4y ago
  The language whose compiler generated the code is relevant, as it often constrains what the generated code look like in broad terms.
- maverwa 4y ago
  Not sure, it could also be viewed as a comparison of ahead-of-time compilation vs. just-in-time compilation (I guess the code paths are hot enough to be completely "jit-ed" here), and then the compiler isnt irrelevant at all. But havent looked into the details on how much difference that alone makes in this case. I think its also a testament on how fast JS has gotten.
- yatac42 4y ago
  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?
  - throwaway894345 4y ago
    Has anyone compiled v8 to WASM so we can finally run JS in the browser? ;)
    - hunterb123 4y ago
      v8 is a JIT engine, WASM would not support it. JavaScriptCore has been compiled to WASM though: https://mbbill.github.io/JSC.js/ https://mbbill.github.io/JSC.js/ People usually ask why, the answer is usually for fun or for sandboxed plugins.
      - amluto 4y ago
        I imagine that, if one were feeling extremely masochistic, one could generate WASM, JIT-style, and load it as needed. The result may not perform well.
      - throwaway894345 4y ago
        I assumed the JIT would emit WASM.
    - mrtesthah 4y ago
      please don’t give them more ideas
- usrusr 4y ago
  True, but if you where in a front-end project doing JS with some WASM parts that happened to use Rust for the WASM, you'd probably not ask yourself "JS or WASM?", you'd ask yourself "JS or Rust?" when deciding where to put some logic. And I'm not sure if we can assume that all languages that offer compilation to WASM would be roughly "rust fast": I wouldn't be surprised if we already had some examples that aren't really good matches for that tight inner loop case you might want to wasmify. Perhaps there are already some that just want to get the "runs in browser" checkbox ticked?
- hazn 4y ago
  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.
  - atwood22 4y ago
    Go is a GC language, but it doesn’t need a VM. It’s a native, statically linked binary that contains the Go runtime.
    - ipsi 4y ago
      Maybe Runtime or Runtime System is a better word than VM? Go has _something_ that manages Go routines and GC and so on.
      - deleted 4y ago
        [deleted]
      - jhgb 4y ago
        You'd need a runtime for managing green threads even if you didn't have a language with GC.
      - tialaramex 4y ago
        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/ 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.
        4y ago
- stared 4y ago
  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.
  - teucris 4y ago
    Given the title I had expected this to be a comparison between the js and rust in terms of development, not performance. I learned nothing new about rust by visiting this page. All I learned was that compiled WASM is faster than js.
    - marcosdumay 4y ago
      > All I learned was that compiled WASM is faster than js. You learned that Rust compiled into WASM is faster than JS. That won't be the case for every language. (We had an example yesterday on the front-page where it wasn't. Ironically, its title implied that it was a generic comparison with WASM.)
  - IncRnd 4y ago
    > 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.
  - deleted 4y ago
    [deleted]
qsort 4y ago
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.
- ufo 4y ago
  On my phone it's closer to 6:1. 500 jumps to 3000 with WASM
  - christophilus 4y ago
    What kind of phone? My iPhone 7 (pretty old) is around 2800 vs 6000 with WASM.
    - ufo 4y ago
      Moto g 7
- crabmusket 4y ago
  > 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/b927428988949e7efca8822697b58d721b8ade58/Attractor.js#L110-L114 https://github.com/dmaynard/attractor-iterator/blob/b9274289... [2]: https://github.com/dmaynard/attractor-iterator/blob/b927428988949e7efca8822697b58d721b8ade58/Attractor.js#L2-L3 https://github.com/dmaynard/attractor-iterator/blob/b9274289...
wdroz 4y ago
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?
- hajile 4y ago
  https://webassembly.org/roadmap/ 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.
  - jcl 4y ago
    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.
oefrha 4y ago
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 https://zaplib.com/docs/blog_post_mortem.html
- crabmusket 4y ago
  > it looks like an pretty ideal case for wasm I'm really not so sure about this (see my comment further down[1]) but I'd love someone more knowledgeable to chime in. [1]: https://news.ycombinator.com/item?id=32108144 https://news.ycombinator.com/item?id=32108144
- deleted 4y ago
  [deleted]
- azakai 4y ago
  That 2x figure is something that shows up consistently over the years, since asm.js in fact. The 10x cases are rare, like they found. Still, 2x is enough to justify using a different language in some cases. Separately, though, on very large applications wasm does have an advantage on startup times: there is no warmup period as the JIT learns the types, no sluggish first frames for the entire application or the first time you click on a feature that hits a new code path. For something like Photoshop or a game engine that can be a very big deal. But, again, this type of application is not the most common, so JS will remain the best option for most things.
- marcosdumay 4y ago
  > 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.
tekkk 4y ago
Very pretty! Like the demo. Demonstrates well how WASM can overcome these processing bottlenecks.
fizzynut 4y ago
I'm curious why a lot of people get a 3x improvement. I get about 6.5-7x speed up, which suspiciously lines up with a 60hz vs 144hz framerate...
- vladvasiliu 4y ago
  This seems related to the screen size, also. On my 4k screen (which I run at 100% scaling) on Firefox on Linux I get around 2700 on ES and 7500 on WASM. But if I reduce the window size to half the screen, I get 3000 for ES and 10000 for WASM.
- nu11ptr 4y ago
  Viewing via an RDP session to a remote browser and getting about a ~5x speed up with Rust version (~900 vs 5000ish)
- wccrawford 4y ago
  I got 2k vs 12k, so about 6x. I'm running 165hz at 2560x1440.
christophilus 4y ago
On my iPhone: 2.8K vs 6K (WASM) On my Linux laptop, Firefox: 1.7K vs 3K On my Linux laptop, Brave: 1.5K vs 6K It does seem to vary quite a bit based on the pattern being drawn, though. These ratios seem to roughly hold, but there's wide variance.
tjelen 4y ago
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/src/modules/Attractor.js#L79 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.
- jsheard 4y ago
  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.
  - tjelen 4y ago
    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).
  - hajile 4y ago
    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). I'd bet it's nearly the same speed as Rust while still being a third of the size.
    - UnpossibleJim 4y ago
      https://blog.suborbital.dev/assemblyscript-vs-rust-for-your-wasm-app https://blog.suborbital.dev/assemblyscript-vs-rust-for-your-... This is a pretty good rundown of expected comparisons, but I doubt there will be any surprises here.
ricardobeat 4y ago
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/ 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.
- jackmott42 4y ago
  There can be value in "things will be fast by default" vs "things can be fast if you use a careful subset of the language". As well it is nice not to have to depend on v8 being the runtime to get good performance. One thing I appreciate about say, Rust, vs C# is that in both using iterators to do operations on collections is the standard idiomatic thing to do. However in C# there is always some overhead, and at big scale you have to question whether that overhead is ok here. Usually is fine but sometimes you have to drop back to for loops. With Rust the iterators pretty reliably get compiled down to very efficient code. So you just do the usual easy thing and get the good performance, no need to worry about it.
  - jhgb 4y ago
    > There can be value in "things will be fast by default" vs "things can be fast if you use a careful subset of the language". One could equally say that there's value in "things will be general by default" vs "things can be general if you use obscure features of a language and thirty libraries to generalize the things that aren't general yet". Yet most programs seem to be following the 80/20 rule, so the majority of code that has been ever written seems to prefer generality over raw speed. Of course one possible solution is to write the general parts and the fast parts of your program in different languages, but interoperation may be tedious.
- nicoburns 4y ago
  > V8 is so good at optimizing code, it's usually possible to reach similar performance in JS. 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.
gwbas1c 4y ago
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?
- azangru 4y ago
  > There's quite a bit of overhead in calling out from WASM to the DOM; how are you making WASM faster? If you check out the code, you will notice that wasm isn't talking to the DOM. Its purpose is to generate the image data as a Uint8Array, which is then passed to the canvas [0], same way the javascript implementation does it [0] - https://github.com/dmaynard/chaos-screen-saver/blob/93187f843386e289994777b5d6d097c6e26d7ae3/src/components/ChaosCanvas.vue#L559 https://github.com/dmaynard/chaos-screen-saver/blob/93187f84...
  - gwbas1c 4y ago
    > If you check out the code That's why you need an "about" blurb.
paulgb 4y ago
I found the source of each: JavaScript: https://github.com/dmaynard/chaos-screen-saver/blob/master/src/modules/Attractor.js https://github.com/dmaynard/chaos-screen-saver/blob/master/s... Rust: https://github.com/dmaynard/rust-wasm-attractor/blob/master/src/lib.rs https://github.com/dmaynard/rust-wasm-attractor/blob/master/...
jollybean 4y ago
I feel this is a bit of an 'algorithmic fallacy'. 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.
- substation13 4y ago
  Yeah exactly. Try representing a DOM tree without massive indirection.
usrusr 4y ago
On my phone Firefox I occasionally get a surprisingly stable "Infinity" readout. Am I seeing a timing sidechannel mitigation in the flesh or is that just my news-fed brain imagining explanations?
liminal 4y ago
Interestingly Firefox is faster for both JS and WASM. I'm seeing: 1247 px/ms Chrome JS 1681 px/ms Firefox JS 5878 px/ms Chrome WASM 6382 px/ms Firefox WASM
- raverbashing 4y ago
  Same here more or less
- papruapap 4y ago
  Apple M1 Chrome JS: 2900 WASM: 13000 Firefox JS: 5000 WASM: 16000 Safari JS: 5500 WASM: 18000
bearjaws 4y ago
Ah yes, all the 3d websites and 3d information I use regularly. IMO we need to start building UI frameworks that are powered by WASM, and then benchmark those as compared to JS equivalent.
- davidatbu 4y ago
  The JS Framework Benchmark[0] has got your back. The link below pre-filters to my subjective "picks" that I think give a birds-eye view of the wasm-to-js comparison for DOM manipulation: My picks: SolidJS > Vue > Sycamore-rs > Svelte > React > Yew SolidJS is a truly reactive JS framework. Sycamore-rs can be thought of as the Rust-clone of SolidJS, and Yew can be thought of as the Rust-clone of React. ">" means "is faster than". [0] https://krausest.github.io/js-framework-benchmark/current.html#eyJmcmFtZXdvcmtzIjpbImtleWVkL3JlYWN0LWhvb2tzIiwia2V5ZWQvc29saWQiLCJrZXllZC9zdmVsdGUiLCJrZXllZC9zeWNhbW9yZSIsImtleWVkL3Z1ZSIsImtleWVkL3lldy1ob29rcyIsIm5vbi1rZXllZC9hcHBydW4iLCJub24ta2V5ZWQvYXJ0Iiwibm9uLWtleWVkL2F1cmVsaWEiLCJub24ta2V5ZWQvYmRjIiwibm9uLWtleWVkL2JpbmRpbmcuc2NhbGEiLCJub24ta2V5ZWQvY2FsbGJhZy1qc3giLCJub24ta2V5ZWQvY2FsbGJhZy1qc3gtbGlzdCIsIm5vbi1rZXllZC9jcnVpIiwibm9uLWtleWVkL2N5Y2xlanMtZG9tIiwibm9uLWtleWVkL2RhdHVtIiwibm9uLWtleWVkL2RlbG9yZWFuIiwibm9uLWtleWVkL2Rvam8iLCJub24ta2V5ZWQvZG9tZGlmZiIsIm5vbi1rZXllZC9kb212bSIsIm5vbi1rZXllZC9kb29odG1sIiwibm9uLWtleWVkL2RveiIsIm5vbi1rZXllZC9lZi1qcyIsIm5vbi1rZXllZC9lbG0iLCJub24ta2V5ZWQvZW5kb3JwaGluIiwibm9uLWtleWVkL2V0Y2giLCJub24ta2V5ZWQvZmlkYW4iLCJub24ta2V5ZWQvZnJlIiwibm9uLWtleWVkL2hhbG9nZW4iLCJub24ta2V5ZWQvaGVyZXN5Iiwibm9uLWtleWVkL2h1bGxvIiwibm9uLWtleWVkL2h5ZHJvLWpzIiwibm9uLWtleWVkL2ltYmEiLCJub24ta2V5ZWQvaW5mZXJubyIsIm5vbi1rZXllZC9saWdodGVyaHRtbCIsIm5vbi1rZXllZC9saXQiLCJub24ta2V5ZWQvbGl0LWh0bWwiLCJub24ta2V5ZWQvbGl0ZXJhbGpzIiwibm9uLWtleWVkL21hcXVldHRlIiwibm9uLWtleWVkL21pa2FkbyIsIm5vbi1rZXllZC9taW1ibCIsIm5vbi1rZXllZC9taXNvIiwibm9uLWtleWVkL21vb24iLCJub24ta2V5ZWQvbmVvdyIsIm5vbi1rZXllZC9uZXZlcmxhbmQiLCJub24ta2V5ZWQvcG9seW1lciIsIm5vbi1rZXllZC9yYWN0aXZlIiwibm9uLWtleWVkL3JlYWN0Iiwibm9uLWtleWVkL3JlZG9tIiwibm9uLWtleWVkL3JlZmxleC1kb20iLCJub24ta2V5ZWQvcmlvdCIsIm5vbi1rZXllZC9zYW4iLCJub24ta2V5ZWQvc2NhcmxldHMtZnJhbWUiLCJub24ta2V5ZWQvc2VlZCIsIm5vbi1rZXllZC9zaWZyciIsIm5vbi1rZXllZC9zaW1pIiwibm9uLWtleWVkL3NsaW0tanMiLCJub24ta2V5ZWQvc2xpbmdqcyIsIm5vbi1rZXllZC9zdGR3ZWIiLCJub24ta2V5ZWQvc3RlbSIsIm5vbi1rZXllZC9zdmVsdGUiLCJub24ta2V5ZWQvdWh0bWwiLCJub24ta2V5ZWQvdWk1LXdlYmNvbXBvbmVudHMiLCJub24ta2V5ZWQvdmFuaWxsYS1kb20tZnJhbWV3b3JrIiwibm9uLWtleWVkL3ZhbmlsbGFqcyIsIm5vbi1rZXllZC92YW5pbGxhanMtMSIsIm5vbi1rZXllZC92dWUiXSwiYmVuY2htYXJrcyI6WyIwMV9ydW4xayIsIjAyX3JlcGxhY2UxayIsIjAzX3VwZGF0ZTEwdGgxa194MTYiLCIwNF9zZWxlY3QxayIsIjA1X3N3YXAxayIsIjA2X3JlbW92ZS1vbmUtMWsiLCIwN19jcmVhdGUxMGsiLCIwOF9jcmVhdGUxay1hZnRlcjFrX3gyIiwiMDlfY2xlYXIxa194OCIsIjIxX3JlYWR5LW1lbW9yeSIsIjIyX3J1bi1tZW1vcnkiLCIyM191cGRhdGU1LW1lbW9yeSIsIjI1X3J1bi1jbGVhci1tZW1vcnkiLCIyNl9ydW4tMTBrLW1lbW9yeSIsIjMxX3N0YXJ0dXAtY2kiLCIzM19zdGFydHVwLW1haW50aHJlYWRjb3N0IiwiMzRfc3RhcnR1cC10b3RhbGJ5dGVzIl0sImRpc3BsYXlNb2RlIjoxLCJjYXRlZ29yaWVzIjpbMSwyLDMsNF19 https://krausest.github.io/js-framework-benchmark/current.ht...
gudmundvatn 4y ago
When comparing js and wasm, one thing people rarely mention is that with js, you get built-in functions/runtime (without crossing the boundary and then getting language mismatch). When "reimplementing" that functionality in wasm, it will add a good amount to binary size. Just a hashmap will add a decent bit. Not to say there aren't uses, but js comes with some advantages.
user249 4y ago
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?
- masklinn 4y ago
  Because a crash or a data corruption is not great either?
- davidatbu 4y ago
  My impression here is that (1) you don't want a language that you'd have to ship a runtime with (any interpreted language, Go, Swift), (2) Rust WASM tooling/documentation is (much?) better than tooling for other languages, and (3) most people would prefer memory safety when it comes to a purely memory-safety-to-compile-time trade-off.
- marcosdumay 4y ago
  > 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.
deleted 4y ago
[deleted]
davidatbu 4y ago
The JS Framework Benchmark compares benchmarks (both WASM and JS) in the more usual setting of DOM manipulations. The link below pre-filters to my subjective "picks" that I think give a birds-eye view of the wasm-to-js comparison for DOM manipulation: My picks, ranked descending by performance: SolidJS > Vue > Sycamore-rs > Svelte > React > Yew SolidJS is a truly reactive JS framework. Sycamore-rs can be taught of as the Rust-clone of SolidJS, and Yew can be taught of as the Rust-clone of React. [0] https://krausest.github.io/js-framework-benchmark/current.html#eyJmcmFtZXdvcmtzIjpbImtleWVkL3JlYWN0LWhvb2tzIiwia2V5ZWQvc29saWQiLCJrZXllZC9zdmVsdGUiLCJrZXllZC9zeWNhbW9yZSIsImtleWVkL3Z1ZSIsImtleWVkL3lldy1ob29rcyIsIm5vbi1rZXllZC9hcHBydW4iLCJub24ta2V5ZWQvYXJ0Iiwibm9uLWtleWVkL2F1cmVsaWEiLCJub24ta2V5ZWQvYmRjIiwibm9uLWtleWVkL2JpbmRpbmcuc2NhbGEiLCJub24ta2V5ZWQvY2FsbGJhZy1qc3giLCJub24ta2V5ZWQvY2FsbGJhZy1qc3gtbGlzdCIsIm5vbi1rZXllZC9jcnVpIiwibm9uLWtleWVkL2N5Y2xlanMtZG9tIiwibm9uLWtleWVkL2RhdHVtIiwibm9uLWtleWVkL2RlbG9yZWFuIiwibm9uLWtleWVkL2Rvam8iLCJub24ta2V5ZWQvZG9tZGlmZiIsIm5vbi1rZXllZC9kb212bSIsIm5vbi1rZXllZC9kb29odG1sIiwibm9uLWtleWVkL2RveiIsIm5vbi1rZXllZC9lZi1qcyIsIm5vbi1rZXllZC9lbG0iLCJub24ta2V5ZWQvZW5kb3JwaGluIiwibm9uLWtleWVkL2V0Y2giLCJub24ta2V5ZWQvZmlkYW4iLCJub24ta2V5ZWQvZnJlIiwibm9uLWtleWVkL2hhbG9nZW4iLCJub24ta2V5ZWQvaGVyZXN5Iiwibm9uLWtleWVkL2h1bGxvIiwibm9uLWtleWVkL2h5ZHJvLWpzIiwibm9uLWtleWVkL2ltYmEiLCJub24ta2V5ZWQvaW5mZXJubyIsIm5vbi1rZXllZC9saWdodGVyaHRtbCIsIm5vbi1rZXllZC9saXQiLCJub24ta2V5ZWQvbGl0LWh0bWwiLCJub24ta2V5ZWQvbGl0ZXJhbGpzIiwibm9uLWtleWVkL21hcXVldHRlIiwibm9uLWtleWVkL21pa2FkbyIsIm5vbi1rZXllZC9taW1ibCIsIm5vbi1rZXllZC9taXNvIiwibm9uLWtleWVkL21vb24iLCJub24ta2V5ZWQvbmVvdyIsIm5vbi1rZXllZC9uZXZlcmxhbmQiLCJub24ta2V5ZWQvcG9seW1lciIsIm5vbi1rZXllZC9yYWN0aXZlIiwibm9uLWtleWVkL3JlYWN0Iiwibm9uLWtleWVkL3JlZG9tIiwibm9uLWtleWVkL3JlZmxleC1kb20iLCJub24ta2V5ZWQvcmlvdCIsIm5vbi1rZXllZC9zYW4iLCJub24ta2V5ZWQvc2NhcmxldHMtZnJhbWUiLCJub24ta2V5ZWQvc2VlZCIsIm5vbi1rZXllZC9zaWZyciIsIm5vbi1rZXllZC9zaW1pIiwibm9uLWtleWVkL3NsaW0tanMiLCJub24ta2V5ZWQvc2xpbmdqcyIsIm5vbi1rZXllZC9zdGR3ZWIiLCJub24ta2V5ZWQvc3RlbSIsIm5vbi1rZXllZC9zdmVsdGUiLCJub24ta2V5ZWQvdWh0bWwiLCJub24ta2V5ZWQvdWk1LXdlYmNvbXBvbmVudHMiLCJub24ta2V5ZWQvdmFuaWxsYS1kb20tZnJhbWV3b3JrIiwibm9uLWtleWVkL3ZhbmlsbGFqcyIsIm5vbi1rZXllZC92YW5pbGxhanMtMSIsIm5vbi1rZXllZC92dWUiXSwiYmVuY2htYXJrcyI6WyIwMV9ydW4xayIsIjAyX3JlcGxhY2UxayIsIjAzX3VwZGF0ZTEwdGgxa194MTYiLCIwNF9zZWxlY3QxayIsIjA1X3N3YXAxayIsIjA2X3JlbW92ZS1vbmUtMWsiLCIwN19jcmVhdGUxMGsiLCIwOF9jcmVhdGUxay1hZnRlcjFrX3gyIiwiMDlfY2xlYXIxa194OCIsIjIxX3JlYWR5LW1lbW9yeSIsIjIyX3J1bi1tZW1vcnkiLCIyM191cGRhdGU1LW1lbW9yeSIsIjI1X3J1bi1jbGVhci1tZW1vcnkiLCIyNl9ydW4tMTBrLW1lbW9yeSIsIjMxX3N0YXJ0dXAtY2kiLCIzM19zdGFydHVwLW1haW50aHJlYWRjb3N0IiwiMzRfc3RhcnR1cC10b3RhbGJ5dGVzIl0sImRpc3BsYXlNb2RlIjoxLCJjYXRlZ29yaWVzIjpbMSwyLDMsNF19 https://krausest.github.io/js-framework-benchmark/current.ht...
AtNightWeCode 4y ago
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.
deleted 4y ago
[deleted]

107 points by orixilus 4y ago

N-Krause 4y ago

Can someone explain what exactly I am looking at here? The about page seems to be an empty page for me.

substation13 4y ago
https://github.com/dmaynard/chaos-screen-saver/blob/master/README.md https://github.com/dmaynard/chaos-screen-saver/blob/master/R...
conqueso 4y ago
Maybe you have an ad blocker on or something? The about button links here: https://github.com/dmaynard/chaos-screen-saver/blob/master/README.md https://github.com/dmaynard/chaos-screen-saver/blob/master/R...
ostenning 4y ago
Compares the rendering speed of Javascript/ES-6 to WASM compiled from Rust. Result: JS/ES-6: ~4000 pixels per millisecond. WASM/Rust: ~16000 pixels per millisecond. These results are on Firefox using M1 Max

montroser 4y ago

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

Banana699 4y ago
The language whose compiler generated the code is relevant, as it often constrains what the generated code look like in broad terms.
maverwa 4y ago
Not sure, it could also be viewed as a comparison of ahead-of-time compilation vs. just-in-time compilation (I guess the code paths are hot enough to be completely "jit-ed" here), and then the compiler isnt irrelevant at all. But havent looked into the details on how much difference that alone makes in this case. I think its also a testament on how fast JS has gotten.
yatac42 4y ago
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?
- throwaway894345 4y ago
  Has anyone compiled v8 to WASM so we can finally run JS in the browser? ;)
  - hunterb123 4y ago
    v8 is a JIT engine, WASM would not support it. JavaScriptCore has been compiled to WASM though: https://mbbill.github.io/JSC.js/ https://mbbill.github.io/JSC.js/ People usually ask why, the answer is usually for fun or for sandboxed plugins.
    - amluto 4y ago
      I imagine that, if one were feeling extremely masochistic, one could generate WASM, JIT-style, and load it as needed. The result may not perform well.
    - throwaway894345 4y ago
      I assumed the JIT would emit WASM.
  - mrtesthah 4y ago
    please don’t give them more ideas
usrusr 4y ago
True, but if you where in a front-end project doing JS with some WASM parts that happened to use Rust for the WASM, you'd probably not ask yourself "JS or WASM?", you'd ask yourself "JS or Rust?" when deciding where to put some logic. And I'm not sure if we can assume that all languages that offer compilation to WASM would be roughly "rust fast": I wouldn't be surprised if we already had some examples that aren't really good matches for that tight inner loop case you might want to wasmify. Perhaps there are already some that just want to get the "runs in browser" checkbox ticked?
hazn 4y ago
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.
- atwood22 4y ago
  Go is a GC language, but it doesn’t need a VM. It’s a native, statically linked binary that contains the Go runtime.
  - ipsi 4y ago
    Maybe Runtime or Runtime System is a better word than VM? Go has _something_ that manages Go routines and GC and so on.
    - deleted 4y ago
      [deleted]
    - jhgb 4y ago
      You'd need a runtime for managing green threads even if you didn't have a language with GC.
    - tialaramex 4y ago
      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/ 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.
      - 4y ago
stared 4y ago
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.
- teucris 4y ago
  Given the title I had expected this to be a comparison between the js and rust in terms of development, not performance. I learned nothing new about rust by visiting this page. All I learned was that compiled WASM is faster than js.
  - marcosdumay 4y ago
    > All I learned was that compiled WASM is faster than js. You learned that Rust compiled into WASM is faster than JS. That won't be the case for every language. (We had an example yesterday on the front-page where it wasn't. Ironically, its title implied that it was a generic comparison with WASM.)
- IncRnd 4y ago
  > 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.
- deleted 4y ago
  [deleted]

qsort 4y ago

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.

ufo 4y ago
On my phone it's closer to 6:1. 500 jumps to 3000 with WASM
- christophilus 4y ago
  What kind of phone? My iPhone 7 (pretty old) is around 2800 vs 6000 with WASM.
  - ufo 4y ago
    Moto g 7
crabmusket 4y ago
> 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/b927428988949e7efca8822697b58d721b8ade58/Attractor.js#L110-L114 https://github.com/dmaynard/attractor-iterator/blob/b9274289... [2]: https://github.com/dmaynard/attractor-iterator/blob/b927428988949e7efca8822697b58d721b8ade58/Attractor.js#L2-L3 https://github.com/dmaynard/attractor-iterator/blob/b9274289...

wdroz 4y ago

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?

hajile 4y ago
https://webassembly.org/roadmap/ 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.
- jcl 4y ago
  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.

oefrha 4y ago

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 https://zaplib.com/docs/blog_post_mortem.html

crabmusket 4y ago
> it looks like an pretty ideal case for wasm I'm really not so sure about this (see my comment further down[1]) but I'd love someone more knowledgeable to chime in. [1]: https://news.ycombinator.com/item?id=32108144 https://news.ycombinator.com/item?id=32108144
deleted 4y ago
[deleted]
azakai 4y ago
That 2x figure is something that shows up consistently over the years, since asm.js in fact. The 10x cases are rare, like they found. Still, 2x is enough to justify using a different language in some cases. Separately, though, on very large applications wasm does have an advantage on startup times: there is no warmup period as the JIT learns the types, no sluggish first frames for the entire application or the first time you click on a feature that hits a new code path. For something like Photoshop or a game engine that can be a very big deal. But, again, this type of application is not the most common, so JS will remain the best option for most things.
marcosdumay 4y ago
> 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.

tekkk 4y ago

Very pretty! Like the demo. Demonstrates well how WASM can overcome these processing bottlenecks.

fizzynut 4y ago

I'm curious why a lot of people get a 3x improvement. I get about 6.5-7x speed up, which suspiciously lines up with a 60hz vs 144hz framerate...

vladvasiliu 4y ago
This seems related to the screen size, also. On my 4k screen (which I run at 100% scaling) on Firefox on Linux I get around 2700 on ES and 7500 on WASM. But if I reduce the window size to half the screen, I get 3000 for ES and 10000 for WASM.
nu11ptr 4y ago
Viewing via an RDP session to a remote browser and getting about a ~5x speed up with Rust version (~900 vs 5000ish)
wccrawford 4y ago
I got 2k vs 12k, so about 6x. I'm running 165hz at 2560x1440.

christophilus 4y ago

On my iPhone: 2.8K vs 6K (WASM) On my Linux laptop, Firefox: 1.7K vs 3K On my Linux laptop, Brave: 1.5K vs 6K It does seem to vary quite a bit based on the pattern being drawn, though. These ratios seem to roughly hold, but there's wide variance.

tjelen 4y ago

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/src/modules/Attractor.js#L79 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.

jsheard 4y ago
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.
- tjelen 4y ago
  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).
- hajile 4y ago
  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). I'd bet it's nearly the same speed as Rust while still being a third of the size.
  - UnpossibleJim 4y ago
    https://blog.suborbital.dev/assemblyscript-vs-rust-for-your-wasm-app https://blog.suborbital.dev/assemblyscript-vs-rust-for-your-... This is a pretty good rundown of expected comparisons, but I doubt there will be any surprises here.

ricardobeat 4y ago

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

jackmott42 4y ago
There can be value in "things will be fast by default" vs "things can be fast if you use a careful subset of the language". As well it is nice not to have to depend on v8 being the runtime to get good performance. One thing I appreciate about say, Rust, vs C# is that in both using iterators to do operations on collections is the standard idiomatic thing to do. However in C# there is always some overhead, and at big scale you have to question whether that overhead is ok here. Usually is fine but sometimes you have to drop back to for loops. With Rust the iterators pretty reliably get compiled down to very efficient code. So you just do the usual easy thing and get the good performance, no need to worry about it.
- jhgb 4y ago
  > There can be value in "things will be fast by default" vs "things can be fast if you use a careful subset of the language". One could equally say that there's value in "things will be general by default" vs "things can be general if you use obscure features of a language and thirty libraries to generalize the things that aren't general yet". Yet most programs seem to be following the 80/20 rule, so the majority of code that has been ever written seems to prefer generality over raw speed. Of course one possible solution is to write the general parts and the fast parts of your program in different languages, but interoperation may be tedious.
nicoburns 4y ago
> V8 is so good at optimizing code, it's usually possible to reach similar performance in JS. 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.

gwbas1c 4y ago

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?

azangru 4y ago
> There's quite a bit of overhead in calling out from WASM to the DOM; how are you making WASM faster? If you check out the code, you will notice that wasm isn't talking to the DOM. Its purpose is to generate the image data as a Uint8Array, which is then passed to the canvas [0], same way the javascript implementation does it [0] - https://github.com/dmaynard/chaos-screen-saver/blob/93187f843386e289994777b5d6d097c6e26d7ae3/src/components/ChaosCanvas.vue#L559 https://github.com/dmaynard/chaos-screen-saver/blob/93187f84...
- gwbas1c 4y ago
  > If you check out the code That's why you need an "about" blurb.

paulgb 4y ago

I found the source of each: JavaScript: https://github.com/dmaynard/chaos-screen-saver/blob/master/src/modules/Attractor.js https://github.com/dmaynard/chaos-screen-saver/blob/master/s... Rust: https://github.com/dmaynard/rust-wasm-attractor/blob/master/src/lib.rs https://github.com/dmaynard/rust-wasm-attractor/blob/master/...

jollybean 4y ago

I feel this is a bit of an 'algorithmic fallacy'. 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.

substation13 4y ago
Yeah exactly. Try representing a DOM tree without massive indirection.

usrusr 4y ago

On my phone Firefox I occasionally get a surprisingly stable "Infinity" readout. Am I seeing a timing sidechannel mitigation in the flesh or is that just my news-fed brain imagining explanations?

liminal 4y ago

Interestingly Firefox is faster for both JS and WASM. I'm seeing: 1247 px/ms Chrome JS 1681 px/ms Firefox JS 5878 px/ms Chrome WASM 6382 px/ms Firefox WASM

raverbashing 4y ago
Same here more or less
papruapap 4y ago
Apple M1 Chrome JS: 2900 WASM: 13000 Firefox JS: 5000 WASM: 16000 Safari JS: 5500 WASM: 18000

bearjaws 4y ago

Ah yes, all the 3d websites and 3d information I use regularly. IMO we need to start building UI frameworks that are powered by WASM, and then benchmark those as compared to JS equivalent.

davidatbu 4y ago
The JS Framework Benchmark[0] has got your back. The link below pre-filters to my subjective "picks" that I think give a birds-eye view of the wasm-to-js comparison for DOM manipulation: My picks: SolidJS > Vue > Sycamore-rs > Svelte > React > Yew SolidJS is a truly reactive JS framework. Sycamore-rs can be thought of as the Rust-clone of SolidJS, and Yew can be thought of as the Rust-clone of React. ">" means "is faster than". [0] https://krausest.github.io/js-framework-benchmark/current.html#eyJmcmFtZXdvcmtzIjpbImtleWVkL3JlYWN0LWhvb2tzIiwia2V5ZWQvc29saWQiLCJrZXllZC9zdmVsdGUiLCJrZXllZC9zeWNhbW9yZSIsImtleWVkL3Z1ZSIsImtleWVkL3lldy1ob29rcyIsIm5vbi1rZXllZC9hcHBydW4iLCJub24ta2V5ZWQvYXJ0Iiwibm9uLWtleWVkL2F1cmVsaWEiLCJub24ta2V5ZWQvYmRjIiwibm9uLWtleWVkL2JpbmRpbmcuc2NhbGEiLCJub24ta2V5ZWQvY2FsbGJhZy1qc3giLCJub24ta2V5ZWQvY2FsbGJhZy1qc3gtbGlzdCIsIm5vbi1rZXllZC9jcnVpIiwibm9uLWtleWVkL2N5Y2xlanMtZG9tIiwibm9uLWtleWVkL2RhdHVtIiwibm9uLWtleWVkL2RlbG9yZWFuIiwibm9uLWtleWVkL2Rvam8iLCJub24ta2V5ZWQvZG9tZGlmZiIsIm5vbi1rZXllZC9kb212bSIsIm5vbi1rZXllZC9kb29odG1sIiwibm9uLWtleWVkL2RveiIsIm5vbi1rZXllZC9lZi1qcyIsIm5vbi1rZXllZC9lbG0iLCJub24ta2V5ZWQvZW5kb3JwaGluIiwibm9uLWtleWVkL2V0Y2giLCJub24ta2V5ZWQvZmlkYW4iLCJub24ta2V5ZWQvZnJlIiwibm9uLWtleWVkL2hhbG9nZW4iLCJub24ta2V5ZWQvaGVyZXN5Iiwibm9uLWtleWVkL2h1bGxvIiwibm9uLWtleWVkL2h5ZHJvLWpzIiwibm9uLWtleWVkL2ltYmEiLCJub24ta2V5ZWQvaW5mZXJubyIsIm5vbi1rZXllZC9saWdodGVyaHRtbCIsIm5vbi1rZXllZC9saXQiLCJub24ta2V5ZWQvbGl0LWh0bWwiLCJub24ta2V5ZWQvbGl0ZXJhbGpzIiwibm9uLWtleWVkL21hcXVldHRlIiwibm9uLWtleWVkL21pa2FkbyIsIm5vbi1rZXllZC9taW1ibCIsIm5vbi1rZXllZC9taXNvIiwibm9uLWtleWVkL21vb24iLCJub24ta2V5ZWQvbmVvdyIsIm5vbi1rZXllZC9uZXZlcmxhbmQiLCJub24ta2V5ZWQvcG9seW1lciIsIm5vbi1rZXllZC9yYWN0aXZlIiwibm9uLWtleWVkL3JlYWN0Iiwibm9uLWtleWVkL3JlZG9tIiwibm9uLWtleWVkL3JlZmxleC1kb20iLCJub24ta2V5ZWQvcmlvdCIsIm5vbi1rZXllZC9zYW4iLCJub24ta2V5ZWQvc2NhcmxldHMtZnJhbWUiLCJub24ta2V5ZWQvc2VlZCIsIm5vbi1rZXllZC9zaWZyciIsIm5vbi1rZXllZC9zaW1pIiwibm9uLWtleWVkL3NsaW0tanMiLCJub24ta2V5ZWQvc2xpbmdqcyIsIm5vbi1rZXllZC9zdGR3ZWIiLCJub24ta2V5ZWQvc3RlbSIsIm5vbi1rZXllZC9zdmVsdGUiLCJub24ta2V5ZWQvdWh0bWwiLCJub24ta2V5ZWQvdWk1LXdlYmNvbXBvbmVudHMiLCJub24ta2V5ZWQvdmFuaWxsYS1kb20tZnJhbWV3b3JrIiwibm9uLWtleWVkL3ZhbmlsbGFqcyIsIm5vbi1rZXllZC92YW5pbGxhanMtMSIsIm5vbi1rZXllZC92dWUiXSwiYmVuY2htYXJrcyI6WyIwMV9ydW4xayIsIjAyX3JlcGxhY2UxayIsIjAzX3VwZGF0ZTEwdGgxa194MTYiLCIwNF9zZWxlY3QxayIsIjA1X3N3YXAxayIsIjA2X3JlbW92ZS1vbmUtMWsiLCIwN19jcmVhdGUxMGsiLCIwOF9jcmVhdGUxay1hZnRlcjFrX3gyIiwiMDlfY2xlYXIxa194OCIsIjIxX3JlYWR5LW1lbW9yeSIsIjIyX3J1bi1tZW1vcnkiLCIyM191cGRhdGU1LW1lbW9yeSIsIjI1X3J1bi1jbGVhci1tZW1vcnkiLCIyNl9ydW4tMTBrLW1lbW9yeSIsIjMxX3N0YXJ0dXAtY2kiLCIzM19zdGFydHVwLW1haW50aHJlYWRjb3N0IiwiMzRfc3RhcnR1cC10b3RhbGJ5dGVzIl0sImRpc3BsYXlNb2RlIjoxLCJjYXRlZ29yaWVzIjpbMSwyLDMsNF19 https://krausest.github.io/js-framework-benchmark/current.ht...

gudmundvatn 4y ago

When comparing js and wasm, one thing people rarely mention is that with js, you get built-in functions/runtime (without crossing the boundary and then getting language mismatch). When "reimplementing" that functionality in wasm, it will add a good amount to binary size. Just a hashmap will add a decent bit. Not to say there aren't uses, but js comes with some advantages.

user249 4y ago

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?

masklinn 4y ago
Because a crash or a data corruption is not great either?
davidatbu 4y ago
My impression here is that (1) you don't want a language that you'd have to ship a runtime with (any interpreted language, Go, Swift), (2) Rust WASM tooling/documentation is (much?) better than tooling for other languages, and (3) most people would prefer memory safety when it comes to a purely memory-safety-to-compile-time trade-off.
marcosdumay 4y ago
> 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.

deleted 4y ago

[deleted]

davidatbu 4y ago

The JS Framework Benchmark compares benchmarks (both WASM and JS) in the more usual setting of DOM manipulations. The link below pre-filters to my subjective "picks" that I think give a birds-eye view of the wasm-to-js comparison for DOM manipulation: My picks, ranked descending by performance: SolidJS > Vue > Sycamore-rs > Svelte > React > Yew SolidJS is a truly reactive JS framework. Sycamore-rs can be taught of as the Rust-clone of SolidJS, and Yew can be taught of as the Rust-clone of React. [0] https://krausest.github.io/js-framework-benchmark/current.html#eyJmcmFtZXdvcmtzIjpbImtleWVkL3JlYWN0LWhvb2tzIiwia2V5ZWQvc29saWQiLCJrZXllZC9zdmVsdGUiLCJrZXllZC9zeWNhbW9yZSIsImtleWVkL3Z1ZSIsImtleWVkL3lldy1ob29rcyIsIm5vbi1rZXllZC9hcHBydW4iLCJub24ta2V5ZWQvYXJ0Iiwibm9uLWtleWVkL2F1cmVsaWEiLCJub24ta2V5ZWQvYmRjIiwibm9uLWtleWVkL2JpbmRpbmcuc2NhbGEiLCJub24ta2V5ZWQvY2FsbGJhZy1qc3giLCJub24ta2V5ZWQvY2FsbGJhZy1qc3gtbGlzdCIsIm5vbi1rZXllZC9jcnVpIiwibm9uLWtleWVkL2N5Y2xlanMtZG9tIiwibm9uLWtleWVkL2RhdHVtIiwibm9uLWtleWVkL2RlbG9yZWFuIiwibm9uLWtleWVkL2Rvam8iLCJub24ta2V5ZWQvZG9tZGlmZiIsIm5vbi1rZXllZC9kb212bSIsIm5vbi1rZXllZC9kb29odG1sIiwibm9uLWtleWVkL2RveiIsIm5vbi1rZXllZC9lZi1qcyIsIm5vbi1rZXllZC9lbG0iLCJub24ta2V5ZWQvZW5kb3JwaGluIiwibm9uLWtleWVkL2V0Y2giLCJub24ta2V5ZWQvZmlkYW4iLCJub24ta2V5ZWQvZnJlIiwibm9uLWtleWVkL2hhbG9nZW4iLCJub24ta2V5ZWQvaGVyZXN5Iiwibm9uLWtleWVkL2h1bGxvIiwibm9uLWtleWVkL2h5ZHJvLWpzIiwibm9uLWtleWVkL2ltYmEiLCJub24ta2V5ZWQvaW5mZXJubyIsIm5vbi1rZXllZC9saWdodGVyaHRtbCIsIm5vbi1rZXllZC9saXQiLCJub24ta2V5ZWQvbGl0LWh0bWwiLCJub24ta2V5ZWQvbGl0ZXJhbGpzIiwibm9uLWtleWVkL21hcXVldHRlIiwibm9uLWtleWVkL21pa2FkbyIsIm5vbi1rZXllZC9taW1ibCIsIm5vbi1rZXllZC9taXNvIiwibm9uLWtleWVkL21vb24iLCJub24ta2V5ZWQvbmVvdyIsIm5vbi1rZXllZC9uZXZlcmxhbmQiLCJub24ta2V5ZWQvcG9seW1lciIsIm5vbi1rZXllZC9yYWN0aXZlIiwibm9uLWtleWVkL3JlYWN0Iiwibm9uLWtleWVkL3JlZG9tIiwibm9uLWtleWVkL3JlZmxleC1kb20iLCJub24ta2V5ZWQvcmlvdCIsIm5vbi1rZXllZC9zYW4iLCJub24ta2V5ZWQvc2NhcmxldHMtZnJhbWUiLCJub24ta2V5ZWQvc2VlZCIsIm5vbi1rZXllZC9zaWZyciIsIm5vbi1rZXllZC9zaW1pIiwibm9uLWtleWVkL3NsaW0tanMiLCJub24ta2V5ZWQvc2xpbmdqcyIsIm5vbi1rZXllZC9zdGR3ZWIiLCJub24ta2V5ZWQvc3RlbSIsIm5vbi1rZXllZC9zdmVsdGUiLCJub24ta2V5ZWQvdWh0bWwiLCJub24ta2V5ZWQvdWk1LXdlYmNvbXBvbmVudHMiLCJub24ta2V5ZWQvdmFuaWxsYS1kb20tZnJhbWV3b3JrIiwibm9uLWtleWVkL3ZhbmlsbGFqcyIsIm5vbi1rZXllZC92YW5pbGxhanMtMSIsIm5vbi1rZXllZC92dWUiXSwiYmVuY2htYXJrcyI6WyIwMV9ydW4xayIsIjAyX3JlcGxhY2UxayIsIjAzX3VwZGF0ZTEwdGgxa194MTYiLCIwNF9zZWxlY3QxayIsIjA1X3N3YXAxayIsIjA2X3JlbW92ZS1vbmUtMWsiLCIwN19jcmVhdGUxMGsiLCIwOF9jcmVhdGUxay1hZnRlcjFrX3gyIiwiMDlfY2xlYXIxa194OCIsIjIxX3JlYWR5LW1lbW9yeSIsIjIyX3J1bi1tZW1vcnkiLCIyM191cGRhdGU1LW1lbW9yeSIsIjI1X3J1bi1jbGVhci1tZW1vcnkiLCIyNl9ydW4tMTBrLW1lbW9yeSIsIjMxX3N0YXJ0dXAtY2kiLCIzM19zdGFydHVwLW1haW50aHJlYWRjb3N0IiwiMzRfc3RhcnR1cC10b3RhbGJ5dGVzIl0sImRpc3BsYXlNb2RlIjoxLCJjYXRlZ29yaWVzIjpbMSwyLDMsNF19 https://krausest.github.io/js-framework-benchmark/current.ht...

AtNightWeCode 4y ago

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.

deleted 4y ago

[deleted]