Maybe you don't need Rust and WASM to speed up your JS • Hacker News Board

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

#61

Post by thefounder » Mon, Feb 19, 2018, 7:28 PM UTC

gear54rus wrote: post #43

themihai wrote: post #9

I wonder if the performance gain is worth the effort. Surely you can always squeeze more performance from JS like from any other language but what's the point if you spend hours to match the performance you get for "free" from other languages? As far as WASM is concerned I'm more excited about the possibility to run any programming language on the web than the raw performance gains. So far it is still year(s) away fr…

> hours to match the performance you get for "free" from other languages? In a sense, you pay those hours that you saved up by using an easier, more intuitive language like JS. Or you can choose not to and still have pretty good performance and blazing fast dev cycles.

I believe there are other languages easier and more intuitive than JS. The lack of DOM and GC support in WASM is the only reason JS is still ruling the web.

As far as the performance is concerned I believe profilling the internals of the VM(as the author does) is not a good fix on the long term.

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

#62

Post by mraleph » Mon, Feb 19, 2018, 7:31 PM UTC

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…

[Thank you for reading the post! I am glad you enjoyed it]

All optimizations in the post can mostly be divided into three large groups:

1) algorithmic improvements; 2) workarounds for implementation independent, but potentially language dependent issues; 3) workarounds for V8 specific issues;

You need to think about algorithms no matter which language you write in, so we don't need to talk much about the first group. In the post it is represented by sorting improvements (sorting subsequences rather than the whole array) and by discussions of caching benefits (or lack of them there-off).

The second group is represented by a monomorphisation trick: the fact that the performance suffers due to polymorphism is not really a V8 specific issue and it is not even JS specific issue. You can apply this approach across implementations and even languages. Some languages apply it in some form for you under the hood.

The last group is represented by argument adaptation stuff.

Finally an optimization I did to mappings representation (using typed array instead of an object) is an optimization that spans all three groups. It's about understanding limitations and costs of a GCed system as whole.

Now... Why did I choose the title? That's because I think group #3 represents the issue that should and would be mostly fixed over time. While groups 1 and 2 represent universal knowledge that spans across implementations and languages.

Obviously it is up to each developer and each team to choose between spending N rigorous hours profiling and reading and thinking about their JavaScript code, or to spend N hours rewriting their stuff in a language X. What I want is:

a) that everybody was fully aware that the choice even exists; b) language designers and implementors worked together on making this choice less and less obvious - which means working on language features and tools and reducing the need in group #3 optimizations.

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

#63

Post by luke_wagner » Mon, Feb 19, 2018, 7:31 PM UTC

Jasper_ wrote: post #44

jandem wrote: post #34

Earlier quoted context omitted.

I work on SpiderMonkey JS performance (and got mentioned in the article for fixing a perf bug!) and this is exactly the point I wanted to make. If you're not a VM engineer, it's much harder to write fast JS. Wasm also gives you much more predictable performance across engines, without requiring (often engine-specific) 'hacks' like function cloning.

From what I can tell, doing basic things like a property get on an object in WASM/host-bindings will require a spill to function, with no chance of specialization: https://github.com/WebAssembly/host-bindings/issues/11#issue... If you think the assembly in this article is bad, WASM/host-bindings appear to be even worse.

That comment (which I made) explains why probably the best we can expect for wasm accessing normal JS objects is the same level of speed as a modern JS engine's "tier 1"/"baseline" JIT. But the Rust code discussed in the OP wasn't accessing JS objects, it was accessing Rust memory which lives in wasm's "linear memory", so I don't see how my comment really disagrees with what jandem or dikaiosune are saying.

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

#64

Post by steveklabnik » Mon, Feb 19, 2018, 7:33 PM UTC

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 wasm, so that you get better performance as the user? I know of at least one major SPA framework that's doing this. Don't want to spill the beans too much, even though it is technically public knowledge.

That said, that's how I think wasm will impact the lives of most JS programmers: as technology that underpins the libraries they use to make them better. Unless you want to, or unless you want to write a high-performance library, I wouldn't expect wasm to really change the way most JS programmers operate. It's abut augmenting JS, not replacing it.

> if I want to animate a div to fly across the page, am I going to have to write lots of low level code to do that?

That depends entirely on the library!

> I'd love it if somebody would point me at some resources that I could burn a weekend on

They're sorta scattered all over the place right now. Such is life for early adopters. More will come as stuff matures. Don't under-estimate how much this will change as the tooling gets built out, for example.

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

#65

Post by mraleph » Mon, Feb 19, 2018, 7:36 PM UTC

solidsnack9000 wrote: post #32

This is a great article and goes to show that statements like "X language is fast" are a little blurry when you put the language in the hands of a skilled developer, who can go beyond the standard idioms and surface level understanding of a language to use it like it's another language. At the end of the article, the author wisely chooses to move some objects out of the control of the GC: We are allocating hundreds o…

I should mention in the post that source-map version that relies on WASM actually requires you to manually manage lifetime of SourceMapConsumer object[1], which my change does not actually require because the memory object is encapsulated within SourceMapConsumer itself.

I do agree that the way I manage mappings is hardly ergonomic. As mentioned in the post I would prefer to use Typed Objects to access the packed array of mappings, but alas that proposal is stalled.

[1] https://github.com/mozilla/source-map#sourcemapconsumerproto...

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

#66

Post by kevingadd » Mon, Feb 19, 2018, 7:36 PM UTC

vvanders wrote: post #36

solidsnack9000 wrote: post #32

This is a great article and goes to show that statements like "X language is fast" are a little blurry when you put the language in the hands of a skilled developer, who can go beyond the standard idioms and surface level understanding of a language to use it like it's another language. At the end of the article, the author wisely chooses to move some objects out of the control of the GC: We are allocating hundreds o…

Yeah, this is also where value types are really awesome and you can get the same results from(assuming no strings). Sadly other than C# most of the mainstream GC'd languages don't include them yet as a feature.

There was even a firm proposal for user-defined value types in JS, but asm.js (and now wasm) took all the air out of the room - though I'm not sure it would have ever gotten implemented in all the browsers anyway, since only perf-sensitive developers care about it.

EDIT: I noticed it's actually mentioned in a footnote in the article - the Typed Objects API was really nice, I had a chance to use it for a prototype.

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

#67

Post by mraleph » Mon, Feb 19, 2018, 7:39 PM UTC

jandem wrote: post #40

solidsnack9000 wrote: post #32

This is a great article and goes to show that statements like "X language is fast" are a little blurry when you put the language in the hands of a skilled developer, who can go beyond the standard idioms and surface level understanding of a language to use it like it's another language. At the end of the article, the author wisely chooses to move some objects out of the control of the GC: We are allocating hundreds o…

> The author is able to achieve a speed-up of ~4x which is close to the 5.89x achieved by the Rust implementation. This is not a fair comparison because the author made algorithmic improvements that would also improve the wasm version if applied to the Rust code. Source: https://twitter.com/mraleph/status/965616993310265344

FWIW, quick look at Rust code actually reveals that that implementation is also different algorithmically from what I was optimizing, e.g. it only sorts generatedMappings array.

In reality it means that performance of my code should not be that far from what WASM is showing because sorting of originalMappings (which I do eagerly and WASM version does lazily) is one third to one half of the overall runtime.

I will try to measure and update the post tomorrow or Wednesday.

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

#68

Post by mraleph » Mon, Feb 19, 2018, 7:42 PM UTC

steveklabnik wrote: post #38

bitdivision wrote: post #31

I can't see any numbers comparing the rust implementation and the optimised javascript. Did I miss them in the article?

A comment upthread did the math: > The author is able to achieve a speed-up of ~4x which is close to the 5.89x achieved by the Rust implementation.

The math is not that obvious because Rust implementation does not match 1-1 what baseline JS version was doing (e.g. it sorts only generatedMappings and not originalMappings).

I will do measurements later to compare and update the post.

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

#69

Post by hinkley » Mon, Feb 19, 2018, 7:46 PM UTC

jandem wrote: post #40

solidsnack9000 wrote: post #32

This is a great article and goes to show that statements like "X language is fast" are a little blurry when you put the language in the hands of a skilled developer, who can go beyond the standard idioms and surface level understanding of a language to use it like it's another language. At the end of the article, the author wisely chooses to move some objects out of the control of the GC: We are allocating hundreds o…

> The author is able to achieve a speed-up of ~4x which is close to the 5.89x achieved by the Rust implementation. This is not a fair comparison because the author made algorithmic improvements that would also improve the wasm version if applied to the Rust code. Source: https://twitter.com/mraleph/status/965616993310265344

If Mark Twain were alive today, the saying would be "Lies, Damned Lies, Statistics, and Benchmarks"

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

#70

Post by jjnoakes » Mon, Feb 19, 2018, 7:47 PM UTC

steveklabnik wrote: post #38

bitdivision wrote: post #31

I can't see any numbers comparing the rust implementation and the optimised javascript. Did I miss them in the article?

A comment upthread did the math: > The author is able to achieve a speed-up of ~4x which is close to the 5.89x achieved by the Rust implementation.

With the caveat that it's apples-to-oranges (algorithmic changes to the JavaScript version (~4x) are not in the Rust version (~5.9x)).