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

71–80 of 186 posts

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

#71

Post by megaman22 »

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 would never categorize JS as easy or intuitive. Maybe in comparison to C++ or Assembly, but it's maddening coming to it from modern statically-typed languages that are better designed and have better tooling.

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

#72

Post by zbentley »

mraleph wrote: post #62
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.…

> Some languages apply it in some form for you under the hood.

I suspect some respondents will say, or believe, that this falls under the category of "you have to know the VM/runtime intimately to get good performance".

I don't think that's true. If you know the general problems with polymorphic call sites, you can (in JS and many other languages) check to see if the runtime is applying optimizations of this kind by being explicit. If it helps, you can get a free optimization by setting explicit arity/dispatch just because you happened to know about the issues surrounding polymorphic dispatch. That's a case of fundamental knowledge speeding up/improving your progress; not a case of "you need to know the VM guts like the back of your hand to make code fast".

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

#74

Post by zbentley »

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…

Writing an O(N^2) algorithm that processes lots of data in wasm is not going to speed it up more than writing an O(log N) algorithm in pure JS; the knowledge of how to identify problems like that will serve you better in many more cases than the selection of a "fast" runtime.

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

#75

Post by steveklabnik »

mraleph wrote: post #68
steveklabnik wrote: post #38

Earlier quoted context omitted.

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.

Sounds good!

I enjoyed the article :)

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

#76

Post by eastWestMath »

ehsanu1 wrote: post #27
faitswulff wrote: post #21

Earlier quoted context omitted.

One thing I've been confused with about transpiled languages is how does correctness transfer? How do types or lifetimes etc. transfer to WASM, for instance? Or does it just depend on the correctness to be verified in the pre-compilation/transpilation stages?

Correctness is typically checked long before code generation happens. This does mean the code generation backend must be trusted, whether the target be x86 or wasm. Just as you have to trust CPUs to not expose processes' memory to each other (oops).

Typed assembly is a thing - it’s mainly to ensure the compiler itself is correct, but it does give stronger guarantees. I think Frank Pfenning at CMU has written a language that’s dependently typed all the way down - so it’s IR and assembly are both dependently typed.

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

#77

Post by robocat »

nocman wrote: post #49
aschampion wrote: post #37

Earlier quoted context omitted.

Since November WASM is enabled by default in the major browsers now: https://caniuse.com/#feat=wasm

I guess if you don't include IE11 as one of the "major browsers". I wish that was the case. Yes, I know it is only receiving security updates -- but it will supposedly get those until Windows 10 is no longer supported (if I'm reading things right). Unfortunately, that doesn't stop a bunch of people from using it. It still has a considerable amount more marketshare than Edge does (if netmarketshare.com is to be believ…

40% of desktop users use IE11 for our browser based app. 1% use an older version of IE, and 1% use Edge. Our clients are businesses, mostly in Australia and New Zealand.

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

#78

Post by mraleph »

hitekker wrote: post #54

Irrelevant and maybe a bit small-minded, but the font of the article is too squished to be pleasantly readable.

Not irrelevant. Question for you, is this more legible:

https://twitter.com/mraleph/status/965686742614462466

I can update CSS if that helps.

UPD. Updated CSS to use non monospace fonts for the body.

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

#79

Post by bluetwo »

Animats wrote: post #4

Source maps are a debug tool. Why does the performance matter? (And if you're shipping so much JavaScript to your site users that you need to "minify", maybe you're doing it wrong.)

> if you're shipping so much JavaScript to your site users that you need to "minify", maybe you're doing it wrong.

100% agree.

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

#80

Post by mraleph »

jokoon wrote: post #55

For me the purpose of wasm would not be just performance, but to let me avoid javascript entirely. Javascript is already very fast, but compiling to javascript feels awkward.

I don't think you can avoid JavaScript even with WASM - and WASM in it's current form is, for some languages, a worse compilation target than JavaScript.
Post reply on HN