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

151–160 of 186 posts

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

#151

Post by ridiculous_fish »

faitswulff wrote: post #21
lmm wrote: post #3

I'm excited about compiling to WASM not for performance but for correctness. Typescript is better than nothing but it really can't compete with the safety and ease you get from a language with a really good type system.

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?

WASM gives you a linear memory block and performs only bounds checking. It provides very few higher-order abstractions.

For example, the way you allocate memory in WASM is to link in a malloc() implementation. This malloc lives in the same linear memory block, and so its internal data structures are vulnerable to being smashed, just like classical heap smashing.

One improvement is that the call stack is maintained externally, so it is not possible to stack-smash a return address. Still heap function pointers are vulnerable to a return-to-libc style attack.

Round and round we go.

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

#152

Post by fenomas »

adrianN wrote: post #145
fenomas wrote: post #133

Earlier quoted context omitted.

JS engines already do insane levels of optimization, and they do it while watching the code execute so they understand the code better than any preprocessing tool can hope to. What could a tool like you're describing do that the engines don't do themselves?

I assume that JITs don't do very expensive optimizations because they have to do a trade off between execution speed and compilation time. JITs are also fairly blind on the first execution of a piece of code. Static optimizations are not made obsolete by the existence of JITs.

Expensive optimizations like what? Can you give a before/after example of something such a tool might do?

(Note: I'm glossing over the case where one is using bleeding-edge syntax that a JS engine doesn't yet know how to optimize. In that case preprocessing out the new syntax is of course very useful, but I don't think this is the kind of optimization the GP comment was talking about.)

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

#153

Post by sametmax »

kjksf wrote: post #94
sametmax wrote: post #59

Earlier quoted context omitted.

Dart came way, way later. And it was a new language, while they could have just used an existing one. They could have implemented lua, ruby, Python, anything with a good track record. With the millions spent on V8 with those geniuses working on it, can you imagine how fast one of those language would have become ? The tooling it would have had ?

Actually, Google tried to make Python faster, with Unladden Swallow project. They failed miserably. And several other projects failed miserably at the same thing as well. Either way, speed was not the main reason they created Dart. Dart was designed for writing large web apps. Dart's top design constraints was good interop with JavaScript meaning transpilation of Dart to decent JavaScript and consumption of existing…

Pypy is proof that you can speed up Python considerably. And it's written in Python. Imagine what could be achieve if one would write something like that in, say, Rust ?

My guess is that they didn't invest anywhere near the resources on unladden shallow (which was probably a side project) than they invested on chrome vm (which was a core project).

Actually, I spend quite a lot of time on the Python mailling list, and here you can see they regularly find things to improve, perf wise. They just have terribly low resources.

I've rarely seen a project as popular as Python, used by so many rich huge corporation, which such little resources actually. It's heart breaking.

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

#154

Post by seeekr »

fenomas wrote: post #133
seeekr wrote: post #90

Earlier quoted context omitted.

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 W…

JS engines already do insane levels of optimization, and they do it while watching the code execute so they understand the code better than any preprocessing tool can hope to. What could a tool like you're describing do that the engines don't do themselves?

The author has proven exactly this point: By going through a number of engine-specific / implementation-specific code transformations they have achieved a significant performance boost for hot code, which, for whatever reason, the JS engines themselves failed to attain with the optimization repertoire they already have.

Also, remember that JS engines are not all-powerful and all-knowing in their optimization techniques, it's still just a limited number of individually imperfect humans working on them, just like the rest of us. So naturally there are going to be opportunities for other humans to utilize and help complete the picture and increase the overall value and effectiveness.

Maybe in this case there is room specifically for a JS-syntax-level tool that also has more freedom in terms of execution time and related concerns, because it can execute at build-time, potentially pull in or bundle much more information about optimizations with it (imagine using (potentially expensive) ML model to search for probable performance wins, actually do micro- or macro-benchmarks during the build step), be maintained outside of the implementation of a JS engine and thus have the additional benefits of a potential broader contributor base and a faster and more focused release cycle, etc. Or this may not be a good idea after all. I cannot tell. All I know is that if we actually do see that there are and will continue to be optimization gaps in the JS engines themselves, then there is a way to fill them, and likely without having to switch to basically entirely different (frontend) technology stacks.

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

#155

Post by seeekr »

fenomas wrote: post #152
adrianN wrote: post #145

Earlier quoted context omitted.

I assume that JITs don't do very expensive optimizations because they have to do a trade off between execution speed and compilation time. JITs are also fairly blind on the first execution of a piece of code. Static optimizations are not made obsolete by the existence of JITs.

Expensive optimizations like what? Can you give a before/after example of something such a tool might do? (Note: I'm glossing over the case where one is using bleeding-edge syntax that a JS engine doesn't yet know how to optimize. In that case preprocessing out the new syntax is of course very useful, but I don't think this is the kind of optimization the GP comment was talking about.)

JIT engines usually don't do static analysis. I'm not sure if that is because the cost for that is that much higher, but a hint towards why could be that the engine simply does not know which parts of the (potentially huge amounts of) code that was loaded is actually going to be needed during execution, so analysing all of it is likely to bring more harm than gain.

As an example for something that static analysis could have caught, take the example from the article about the "Argument Adaptation"[0]. Here the author uses profiling to learn that by matching the exact argument count for calling a function, instead of relying on the JS engine to "fix that", the performance can be improved by 14% for this particular piece of code. Static analysis could have easily caught and fixed that, essentially performing a small code refactoring automatically just like the author here did manually.

[0] http://mrale.ph/blog/2018/02/03/maybe-you-dont-need-rust-to-...

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

#156

Post by carlmr »

kbenson wrote: post #146
b0rsuk wrote: post #144

Earlier quoted context omitted.

I agree with this, but I think most people don't, until it's demonstrated Rust kicks ass. Javascript is all the age right now. People might think "I'll get a Javascript job now, and I will learn to optimize later. Javascript is highly optimized anyway." Then it's just inertia. They already know Javascript. Besides, Javascript may have a reputation for being messy, but not for being a hard language to pick up. Yes it…

Sure, and that's why I was careful to couch the argument as just some other language that includes C and C++ as options (and truthfully includes others, but few have quite the same compatibility story). At this point if you don't know C++ or Rust, which one will give you the most benefit from learning it is a very open question. I think Rust has advantages over C++ in correctness and safety, but C++ currently offers…

>but C++ currently offers better paths for understanding and utilizing existing code or getting a job using it

I wouldn't say this is entirely wrong, but proper cross-platform package and test management with Cargo is a reason alone that utilizing existing code is waaay easier in Rust. C++ has more existing code though, so they might hit your niche needs better.

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

#157

Post by pjmlp »

kbenson wrote: post #146
b0rsuk wrote: post #144

Earlier quoted context omitted.

I agree with this, but I think most people don't, until it's demonstrated Rust kicks ass. Javascript is all the age right now. People might think "I'll get a Javascript job now, and I will learn to optimize later. Javascript is highly optimized anyway." Then it's just inertia. They already know Javascript. Besides, Javascript may have a reputation for being messy, but not for being a hard language to pick up. Yes it…

Sure, and that's why I was careful to couch the argument as just some other language that includes C and C++ as options (and truthfully includes others, but few have quite the same compatibility story). At this point if you don't know C++ or Rust, which one will give you the most benefit from learning it is a very open question. I think Rust has advantages over C++ in correctness and safety, but C++ currently offers…

Currently C++ still wins over Rust, regarding UI and mobile development, specially in what concerns out-of-box experience.

C++ had the advantage of being immediately adopted by the OS vendors for GUI development, although nowadays, with exception of Windows, its role has changed into just addressing the GPU.

So maybe one day we will get something like shaders, CoreGraphics, DirectX, SurfaceFlinger in Rust, but it will still need a couple of years.

Webrender is already something into this direction.

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

#158

Post by pjmlp »

carlmr wrote: post #156
kbenson wrote: post #146

Earlier quoted context omitted.

Sure, and that's why I was careful to couch the argument as just some other language that includes C and C++ as options (and truthfully includes others, but few have quite the same compatibility story). At this point if you don't know C++ or Rust, which one will give you the most benefit from learning it is a very open question. I think Rust has advantages over C++ in correctness and safety, but C++ currently offers…

>but C++ currently offers better paths for understanding and utilizing existing code or getting a job using it I wouldn't say this is entirely wrong, but proper cross-platform package and test management with Cargo is a reason alone that utilizing existing code is waaay easier in Rust. C++ has more existing code though, so they might hit your niche needs better.

Here something like conan might finally win the hearts of C++ devs, but it is still pretty much in the beginning.

In what concerns Windows development, NuGET and vcpkg are already a big improvement.

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

#159

Post by thefounder »

ShinTakuya wrote: post #106
thefounder wrote: post #61

Earlier quoted context omitted.

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.

I agree regarding JS not being the easiest or most intuitive language, but I don't see JS going away any time soon and I don't think that's a bad thing. The last 5 years or so have seen JS transform from one of the most frustrating languages to one of the better ones. I think Typescript is where the future of web dev lies. Typescript for your main logic and WASM for optimising the parts that need it.

Yeah, JS is better now but I bet we could do even better starting with a clean slate. Web dev shouldn't be tied to a single programming language. How would you like using PHP and its derivates(i.e. Hack) for everything web APIs/back-end? I could tell you that it made great progress since PHP 4.

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

#160

Post by pjmlp »

greenhouse_gas wrote: post #39

The problem with these tricks is that they're dependant on V8 internals, which means that there's no guarantee that it will be fast on Firefox (or edge, or even Safari). So now if google changes the back end, websites will slow down, which means that Google has to ossify implementation details, furthering this sort of black magic into CS lore forever. This, honestly, is what I hate with modern dev. A few days back th…

Same applies to other languages with multiple implementations.

You might have some high performance C code only tested in gcc on GNU/Linux, and then get some nasty surprises when testing on HP-UX with aC, for example.

Back in the day, DDJ and The C/C++ User's Journal used to run articles comparing the quality of all most well known compilers.

Post reply on HN