Comment by noelwelsh | Hacker News Reader

Comment by noelwelsh | Hacker News Reader

Parent Full thread

The benchmarks I have seen show Hotspot is ahead of V8. E.g. https://stefan-marr.de/papers/oopsla-larose-et-al-ast-vs-byt...

What makes this very complicated is that 1) language design plays a big part in performance and 2) CPUs change as well and this anecdotally seems to have more impact on interpreter than compiler performance.

With regards to 1), consider optimizing Javascript. It doesn't have machine integers, so you have to do a bunch of analysis to figure when something is being used as an integer and then you can make that code fast. There are many other cases. Python is even worse in this regard. In comparison AOT compiled languages are usually designed to be fast, so they make tradeoffs that favour performance at the cost of some level of abstraction / expressivity. The JVM is somewhere in the middle, and so is its performance.

With regards to 2) this paper is an example, as is https://inria.hal.science/hal-01100647/file/InterpIBr-hal.pd...

> you have to do a bunch of analysis to figure when something is being used as an integer and then you can make that code fast

It doesn't get much attention now that WASM exists, but asm.js essentially solves this, so a more head-to-head comparison ought to be possible. (V8 has optimisations specific to asm.js.)

https://en.wikipedia.org/wiki/Asm.js

asm.js solves this in the specific case where somebody has compiled their C/C++ code to target asm.js. It doesn't solve it for arbitrary JS code.

asm.js is more like a weird frontend to wasm than a dialect of JS.

No, if you just use the standard JavaScript cast to integer incantation, |0, v8 will optimize it. asm.js is valid JavaScript.

Sure, but that was essentially my point. If we're trying to compare HotSpot and V8 for similar input code, Java and asm.js seem closer than Java and full-blown JavaScript with its dynamic typing.

With all respect that sounds like excuse-making. I mean, yeah, Javascript and JVM and .NET are slower runtimes than C or Rust[1]. Nonetheless that's the world we live in, and if you have a performance-sensitive problem to solve you pick up rustc or g++ and not a managed runtime. If that's wrong, someone's got to actually show that it's wrong.

[1] Maybe Go or Swift would be more apples-to-apples. But even then are there clear benchmarks showing Kotlin or C# beating similar AoT code? If anything the general sense of the community is that Go is faster than Java.

Excuses for what? I'm not the elected representative for JIT compiled languages, sworn to defend them. There are technical reasons they tend to be slower. I was sketching some of them.

I think the above comments are because JIT gets so much positive press, someone wandering in from outside could be mistaken for thinking that JIT isn't coming 2nd in a two-man race with AOT.

I've been around long enough to hear that Java and JIT are gonna overtake C++ any day now.

The title on this article doesn't help.

When things are performance-sensitive, you want things to be tunable and predictable. Good luck playing with the JIT if you rely that for performance...

Good luck with AOT as well, unless you hardcode the target hardware, like game consoles.

https://devblogs.microsoft.com/oldnewthing/20060731-15/?p=30...

https://blog.codinghorror.com/on-managed-code-performance-ag...

And that was 2005. Modern .NET is much, much faster.

> If anything the general sense of the community is that Go is faster than Java.

Faster where?

Reply on news.ycombinator.com