News for hackers. Stuff that matters.
Re:Maybe you don't need Rust and WASM to speed up your JS (2... by derefr on Thursday June 24, 2021 @11:25AM (#27618965)
I don’t know about the “low-level” part. I have a feeling you’d get just as much of a win from a HLL statically-typed language, like Haskell.

It’s the static-typing, not the low-level-ness, doing most of the heavy lifting in making code JITable/WPOable. You don’t need to manually inline a comparison function, if the JIT knows how to inline the larger class of thing that a comparison function happens to fall into, and if the code is amenable to that particular WPO transformation.

I would compare this to SQL: you don’t optimize a SQL query plan by dropping to some lower level where you directly do the query planner’s job for it. Instead, you just add information to the shape of your query such that it becomes amenable to the optimization the query planner knows how to do. That will almost always get you 100% of the wins it’s possible to get on the given query engine anyway, such that there’d be nothing to gain by writing a query plan yourself.

Re:Maybe you don't need Rust and WASM to speed up your JS (2... by cogman10 on Thursday June 24, 2021 @11:35AM (#27619120)
So, you'd think static typing was a major win but it actually isn't (surprisingly) for a JITed language. Most of the benefits of statically typed languages comes from memory layout optimizations. However, that sort of layout optimization is something that every fast JITed language ends up doing.

This is why, for example, javascript in Graal ends up running nearly as fast as Java in the same VM. The reason it isn't just as fast is the VM has to insert constraint checks to deopt when an assumption about the type shape is violated.

https://www.graalvm.org/javascript/

Re:Maybe you don't need Rust and WASM to speed up your JS (2... by unrealhoang on Thursday June 24, 2021 @01:42PM (#27621230)
not really, Haskell is slower than C++/Rust. You get faster performance by being mechanical sympathetic, i.e. you care about how to laid out your data in memory efficiently for the CPU to process, when and how much to allocate, which code path to fold together (inlining) to create a smallest possible set of instructions.

JIT is theoretically possible to figure out all that and transform your code into optimized form, but practically? we don't have Sufficiently Smart Compiler[1] yet. Usually, JIT is worse in restructure your data layout than figure out which part to inline.

[1] https://wiki.c2.com/?SufficientlySmartCompiler