[cogman10]

> It's fast compared to other dynamically typed language implementations

true

> it's still very slow compared to basically all of the popular statically typed languages.

Not true.

The main slowdown for javascript (AFAIK) is the checks the optimizer has to put into place to ensure the assumptions it's made about the type are still valid. If, however, those assumptions are valid then javascript ends up emitting pretty much the same assembly that you'd see for and highly optimized statically typed language. In fact, there are some circumstances where it can beat a language like C++ or Rust due to the fact that it has to incorporate runtime information into optimizations.

With C++ or rust, if you add dynamic dispatch, unless you are doing PGO and whole program optimization, you are pretty much sunk with 2 memory lookups on every function call. This is the case where javascript can end up beating C++/Rust.

(All of this is talking about hot code after warmup. During the initial execution javascript will almost certainly always be slower).

Part of the proof of this was asm.js, the precursor to wasm. V8 at the time it was introduced could execute asm.js nearly as fast as what firefox could do with it's optimized asm.js compiler. That is, when you stripe out all the actions that make javascript slow, it very often ends up being just as fast as a compiled language.

What stuff ends up making it slow? Generally speaking, stuff that makes the types unpredictable (adding fields, removing fields, sending in a number and a string and expecting the VM to be able to handle both).

You can see a lot of this writeup around the discussions about why Dart was originally "optionally typed". Basically, the entire selling point to make dart fast was simply to remove the abilities to dynamically change types like you have in javascript. With that, the VM authors at the time were capable of making a VM that's every bit as fast as what Java has.

[fsdjkflsjfsoij]

> That is, when you stripe out all the actions that make javascript slow, it very often ends up being just as fast as a compiled language.

ok...

> In fact, there are some circumstances where it can beat a language like C++ or Rust due to the fact that it has to incorporate runtime information into optimizations.

People used to make the same claim about Java and in every single example I've ever seen the Java/Javascript is extremely optimized, performance isn't consistent across VM versions, and the C++/Rust is extremely naive (usually allocating unnecessarily and not using arenas in hot paths that are allocation heavy).

[cogman10]

None of these tests really show JS winning, but they are showing that it's within spitting distance of C++ in multiple tests [1]

And, you can look at the code yourself, most of the examples read pretty much exactly the same as their C++ counterparts.

Mind you, this is also a test that looks at execution start to finish and doesn't give warmup time (which will always favor statically compiled languages).

> performance isn't consistent across VM versions

That's true for C++ compilers, so why would you expect performance to remain constant with a JIT compiler?

[1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

[PH95VuimJjqBqy]

absolutely spot on, there was a time when Hotspot was going to bring Java to the promised land.

It never happened.

[gpderetta]

> With C++ or rust, if you add dynamic dispatch, unless you are doing PGO and whole program optimization, you are pretty much sunk with 2 memory lookups on every function call. This is the case where javascript can end up beating C++/Rust.

GCC at least is capable of speculative devirtualization by using local heuristics, without PGO. And of course it is capable of devirtualizing in many cases when the knowledge actual type can be constant-propagated.

Also note that the vast majority of calls are not dynamic in C++ (as opposed to most dynamic languages), so devirtualization is significantly less impactful.

[cogman10]

Fair point, AFAIK C++ templates are pretty heavily used to avoid a dynamic dispatch. Couple that with the fact that polymorphic OO has fallen out of favor generally and I could see this mattering a lot less now-a-days.