Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Maybe you don't need Rust and WASM to speed up your JS

mrale.ph

Post reply on HN
Print view View original

81–90 of 186 posts

Re: Maybe you don't need Rust and WASM to speed up your JS

#81

Post by austincheney »

madflame991 wrote: post #18
austincheney wrote: post #11

I thought all the benchmarks indicated that WASM is still slower than JS. That being said the only performance improvements offered by WASM is if it doesn't for garbage collection for consistence execution. WASM isn't about performance. It is about writing applications in any language and importing those applications into an island in a web page.

> WASM isn't about performance. It is about writing applications in any language and importing those applications into an island in a web page. You don't really need wasm for that, do you? Anything compiles to JS nowadays and you'd actually get easier access to the DOM and GC and support for source maps (are those working for wasm yet?)

Flash has always been better for media and games than JavaScript. WASM fills that niche.

Re: Maybe you don't need Rust and WASM to speed up your JS

#82

Post by spicyj »

steveklabnik wrote: post #64
patientplatypus wrote: post #60

So... I'm a (junior/so-so) react dev. I like the language, I probably could get better at it but I've gotten to the point where I like the sound of my own music. That said, my question is the following. There seems to be a lot of resources on the web of the type "Hey Rust and WASM is a thing! You can make webpages with it". Ok, fine. However, I don't see a lot of the things that are in libraries like Vue and React th…

> "Hey Rust and WASM is a thing! You can make webpages with it". Ok, fine. It is very early days. More to come... > However, I don't see a lot of the things that are in libraries like Vue and React Yes. There's not too many of these yet; there are some though. For example, https://github.com/DenisKolodin/yew There's also the inverse: can we re-write parts of libraries like Vue or React in something that compiles to w…

> Can we re-write parts of libraries like Vue or React in something that compiles to wasm, so that you get better performance as the user?

For React, we would love to do this although it's not clear what parts of React would benefit from being moved to wasm right now.

Re: Maybe you don't need Rust and WASM to speed up your JS

#83

Post by b0rsuk »

aschampion wrote: post #35
anp wrote: post #25

I think this is an interesting exploration because I really enjoyed the description of profiling and improving performance, but I came away feeling exactly the opposite of the title. I think it's really cool that JS optimization can provide so many wins, but this article makes it seem fairly fickle and if they're not familiar with VM internals I would not expect most developers to complete this journey. Using wasm+ru…

Having micro-optimized and maintained JS code over years and dozens of browser versions, I cannot echo this enough. Tuning JS both the in face of fickleness of VM quirks and data/context is a losing proposition for all but the most speed- and core-functionality-critical code. The point of rust+wasm benchmarks is that one can write reasonable, maintainable, functionality-focused code (not to mention all the rust-speci…

I'm afraid it's easier to get started as a Javascript developer than a Rust developer. What if it's easier to learn JS optimization quirks than to become an average Rust developer ?

Re: Maybe you don't need Rust and WASM to speed up your JS

#84

Post by hateduser2 »

b0rsuk wrote: post #83
aschampion wrote: post #35

Earlier quoted context omitted.

Having micro-optimized and maintained JS code over years and dozens of browser versions, I cannot echo this enough. Tuning JS both the in face of fickleness of VM quirks and data/context is a losing proposition for all but the most speed- and core-functionality-critical code. The point of rust+wasm benchmarks is that one can write reasonable, maintainable, functionality-focused code (not to mention all the rust-speci…

I'm afraid it's easier to get started as a Javascript developer than a Rust developer. What if it's easier to learn JS optimization quirks than to become an average Rust developer ?

It seems less reliable to learn is optimization quirks, since you’re depending on an (infrequently changing?) implementation detail. Also writing those things sounds muh messier and less maintainable. All heuristic points I’m making.

Re: Maybe you don't need Rust and WASM to speed up your JS

#85

Post by ef4 »

The problem with this kind of deep dive optimization is the cost of maintaining it in a long-lived project as the underlying javascript engines keep changing. What was optimal for one version of V8 can actually be detrimental in another version, or in another browser.

It's precisely the unpredictability of JIT-driven optimizations that makes WASM so appealing. You can do all your optimizing once at build time and get consistent performance every time it runs.

It's not that plain Javascript can't be as fast -- it's that plain Javascript has high variance, and maintaining engine-internals-aware optimization in a big team with a long-lived app is impractical.

Re: Maybe you don't need Rust and WASM to speed up your JS

#86

Post by steveklabnik »

spicyj wrote: post #82
steveklabnik wrote: post #64

Earlier quoted context omitted.

> "Hey Rust and WASM is a thing! You can make webpages with it". Ok, fine. It is very early days. More to come... > However, I don't see a lot of the things that are in libraries like Vue and React Yes. There's not too many of these yet; there are some though. For example, https://github.com/DenisKolodin/yew There's also the inverse: can we re-write parts of libraries like Vue or React in something that compiles to w…

> Can we re-write parts of libraries like Vue or React in something that compiles to wasm, so that you get better performance as the user? For React, we would love to do this although it's not clear what parts of React would benefit from being moved to wasm right now.

Yeah, that's what I've been hearing through the grapevine. We'll see! I'd love to see it.

Re: Maybe you don't need Rust and WASM to speed up your JS

#87

Post by eslaught »

> Is it better to quick-sort one array with 100K elements or quick-sort 3333 30-element subarrays?

> A bit of mathematics can guide us (100000log100000 is 3 times larger than 3333×30log30)

You have to be careful doing this kind of analysis. Big-O is explicitly about what happens for large values of N. It is traditional to leave off smaller factors, because they don't matter at the limit of N going to infinity. There is implicitly a constant coefficient on each component, and that might matter more at small N.

So e.g. I've seen cases that were O(N^2 + N), and which of course you'd traditionally write as O(N^2), but where the O(N) factor mattered more at small values of N because of constant factors. Depending on whether you cared more about small or large values of N, would guide whether you'd actually want to go after the O(N^2) factor or not. If you just blindly went for the larger factor, you could waste a lot of time and not actually accomplish anything.

Re: Maybe you don't need Rust and WASM to speed up your JS

#88

Post by devit »

wereHamster wrote: post #50
devit wrote: post #28

Earlier quoted context omitted.

It's not: the TypeScript type system is unsound (accepts code that violates it), and there are no runtime checks, so it doesn't actually guarantee anything: a TypeScript variable may in fact contain any value regardless of its declared type. I'd say the best type systems are found in Rust (naturally models zero-cost abstractions but doesn't have dependent types) and Idris and Coq (have dependent types but don't natur…

> a TypeScript variable may in fact contain any value regardless of its declared type. That's true in pretty much all languages. Even in Haskell you can use `unsafeCoerce`. In Rust you have 'unsafe' blocks. And any language which has a FFI you can implement the type-safety-violating functions in the foreign language (often C).

Yeah but in Rust and Haskell it's isolated to clearly marked code (except for some minor bugs in Rust that will be fixed - see https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is... ).

Instead TypeScript has a bunch of serious unfixed design flaws that make the problem pervasive, plus they refuse to fix them (see https://github.com/Microsoft/TypeScript/issues/9825 ).

Re: Maybe you don't need Rust and WASM to speed up your JS

#89

Post by kbenson »

b0rsuk wrote: post #83
aschampion wrote: post #35

Earlier quoted context omitted.

Having micro-optimized and maintained JS code over years and dozens of browser versions, I cannot echo this enough. Tuning JS both the in face of fickleness of VM quirks and data/context is a losing proposition for all but the most speed- and core-functionality-critical code. The point of rust+wasm benchmarks is that one can write reasonable, maintainable, functionality-focused code (not to mention all the rust-speci…

I'm afraid it's easier to get started as a Javascript developer than a Rust developer. What if it's easier to learn JS optimization quirks than to become an average Rust developer ?

It's a cost/benefit type of situation. Learning to optimize JavaScript might cost less, but the benefit is fairly narrow, and may lesson over time (or you may need to pay more in attention and time to keep up with JavaScript VM changes). Rust (or C++) to WASM costs more (if you don't already know the language), but the benefit should stay static and useful over time, and there are many other benefits as well (such as having a fast low-level language to fall back on for other needs.

This isn't unique to this situation either. If you're writing Python and your choice is to either deep dive into various hacks to maximize performance of your pure python or learn Rust/C/C++ and call out using an FFI mechanism, if you have the time to space, I think it's almost always better to learn the new language. There are many benefits to learning new languages beyond just the different performance characteristics, so if you can afford to take that path, I think it's usually a good choice to do so.

Re: Maybe you don't need Rust and WASM to speed up your JS

#90

Post by seeekr »

ef4 wrote: post #85

The problem with this kind of deep dive optimization is the cost of maintaining it in a long-lived project as the underlying javascript engines keep changing. What was optimal for one version of V8 can actually be detrimental in another version, or in another browser. It's precisely the unpredictability of JIT-driven optimizations that makes WASM so appealing. You can do all your optimizing once at build time and get…

It seems to me there is no reason we shouldn't be able to create an "optimizing babel" that could be doing performance optimizations based on the target JS engine and version, as a build step. I don't think we need to go to a completely different source language and a compilation to WASM in order to get permission to create such an optimization tool.

Such a tool would give you the benefits you're praising about the WASM compilation workflow: Separately maintained, engine-specific optimizations that can be applied at build-time and don't mess up the maintainability of your source code.

Post reply on HN