Hacker News Reader

Comment by cogman10 | Hacker News Reader

Javascript JITs are really good, you (likely) aren't going to see major performance improvements by dropping into WASM.

That said, one major benefit of WASM that Javascript jits will have a hard time competing with is GC pressure. So long as your WASM lib focuses on stack allocations, it'll be real tough for a Javascript native algorithm doing the same thing to compete (particularly if there's a bunch of object/state management).

For a hot math loop doing floating point calcs (mandelbrot calc), however, I've seen javascript end up with identical performance compared to WASM. It's really pretty nuts.

View on HN

>aren't going to see major performance improvements by dropping into WASM

I think that might also change as they add proposal and roadmap items like "direct access to the DOM"[1] to WASM.

Proposals: https://github.com/WebAssembly/proposals

Roadmap: https://webassembly.org/roadmap/

[1] https://github.com/WebAssembly/interface-types/blob/master/p...

Edit: Overall, the proposals seem to be pushing WASM closer to being a general purpose VM (VM as in JVM, not KVM).

> Javascript JITs are really good, you (likely) aren't going to see major performance improvements by dropping into WASM.

A javascript JIT is never going to be able to compete with codegen from a low-level statically typed language running through an optimizing compiler. I mean, this very article contains the perfect example: by manually inlining the comparison function they got huge performance gains from a sorting function. That is child’s play for GCC or LLVM (it’s the whole point of std::sort in C++).

There are certainly nasty edges to javascript programming and I'm not trying to say that it will always be near the same performance as a WASM implementation or a statically compiled binary.

What I'm saying is that you'll find more often than not that it gets close enough to not matter. You'll see javascript at or below 2->3x the runtime of a C++ or Rust statically compiled implementation in most cases. That is pretty close as far as languages go. Java is right in the same range (maybe a little lower).

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.

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/

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

Isn't Java's JIT is better than static optimizations of C++ because of runtime data is also very important for optimizations? Also inlining of comparison functions usually already done in V8...

Depends. Java's JIT can handle cases of dynamic dispatch better than C++ because of runtime information. However, C++ has the advantage of time. It can do more heavy optimizations because the time budget to do such opts is much longer than what the JIT has available to it. C++ compilers can be much more aggressive about things like inlining.

That said, yes, the runtime information provides really valuable information. That's why PGO is a thing for C++.

"Javascript JITs are really good, you (likely) aren't going to see major performance improvements by dropping into WASM."

If that were true, nobody would be working on WASM because there would be no point.

"For a hot math loop doing floating point calcs (mandelbrot calc), however, I've seen javascript end up with identical performance compared to WASM. It's really pretty nuts. "

That's easy mode for a JIT. If it can't do that it's not even worth being called a JIT. That's not a criticism or a snark, it's a description of the problem space.

The problem is people then assume that "tight loops of numeric computation" performance can be translated to "general purpose computing performance", and it can't. I have not seen performance numbers that suggest that Javascript on general computation is at anything like C speed or anything similar. I see performance being more rule-of-thumb'd at 10x slower than C or comparable compiled languages. Now, that's pretty good for a dynamic scripting language, which with a naive-but-optimized interpreter tends to clock in at around 40-50x slower than C. The competition from the other JITs for dynamic scripting languages mostly haven't done as well (with the constant exception of LuaJIT). But JIT performance across the board, including Javascript, seems to have plateaued at much, much less than "same as compiled" performance and I see no reason to believe that's going to change.

> If that were true, nobody would be working on WASM because there would be no point.

Wasm has much more potential than just optimization. It opens up capabilities like:

* Using other languages besides Javascript, or languages that just compile to JS

* Passing programs around vs passing data around

* Providing a VM isolate abstraction that's embedable in your existing language/ runtime

|* Using other languages besides Javascript, or languages that just compile to JS|

This might be the most under appreciated comment I have seen all day. While Typescript did some wrangling to bring a bit a bit of "normalcy" to Javascript, the consistency that C++/Rust bring from a coding language point is (for me) enough to have gottem me interested in the use of WASM. Maybe I'm just lazy or have a strong dislike of the headache I get from learning JS compared to switching over to other languages.

If WASM wasn't faster than Javascript, nobody would care. They would just compile things to the "as fast as C" Javascript, and it would have been done years ago.

We need to redo all this work for WASM precisely because there is no such thing in general as "as fast as C Javascript". Javascript itself is not a suitable target for all those things. A 10x performance haircut off the top, in addition to what it costs to get to even performance that good (JITs tend to eat RAM like candy to get their performance increases on dynamic languages), just wasn't an acceptable base for the things you're talking about.

I'm using wasm and I'm not even targeting the web. JS is irrelevant to me.

WASM however is quite high level, restricted bytecode and stack based. The baseline performance gain over JS is maybe 30% to 10x. Not the 50-100x you‘d expect.

It’s also new. Maybe there is potential here for WASM to get faster.

WASM couldn't be a 50-100x improvement over (optimized) JS because that would make it something like 10x faster than C. C isn't necessarily the absolute upper limit, it does have a couple of systemic flaws in terms of going absolutely the fastest (aliasing issues), but there certainly isn't that much room for improvement in it.

WASM will probably get faster, but I don't necessarily expect Rust-generated WASM or other static language-generated WASM to get that much faster. I think most of it will come from JIT'ing stuff that will mostly affect dynamic language-generated WASM. That said I do think Javascript's JIT is going to be fairly close to the limit of what you can see in WASM either, because it is implausible that you could "just" compile the JS to WASM then use the WASM optimizer to do better than the Javascript JIT. The Javascript JIT has everything the WASM optimizer would have, and more, since there would inevitably be loss in the translation.

> Javascript JITs are really good, you (likely) aren't going to see major performance improvements by dropping into WASM.

The original essay shows exactly that, the one here shows pretty epic optimisations (and needs for an excellent knowledge of the platform) to get to "naive" WASM performances.

For math calculations amenable to SIMD, browser vendors have already designed in a huge advantage for WebAssembly: plans for SIMD support in JS was dropped, and kept for WebAssembly. At the start it gives up to a 4x advantage to WebAssembly with the basic 128-bit SIMD, but possibly 16x later if/when WebAssembly gets support for vector widths corresponding to today's hardware.

(anyone know why they started with narrow SIMD? surely it's easier to emulate 512-bit simd with 128-bit simd instructions than try to compile 128-bit simd to take advantage of 512-bit simd?)

https://blog.feather.systems/jekyll/update/2021/06/21/WasmPe...

We did that! Yea chrome basically keeps right up, of course not accounting for SIMD

"Javascript JITs are really good, you (likely) aren't going to see major performance improvements by dropping into WASM."

WASM may not significantly outperform the JIT of one particular browser on a given scenario but you are more likely to get homogeneous performance across different browsers.

Reply on news.ycombinator.com