6 ms·

Why is javascript slower than Java despite being both garbage collected and v8 having more engeeners than e.g openjdk?

setr 7y ago
A couple obvious reasons would be compiled vs interpreted, and static vs dynamic, both of which bear some inherit runtime performance cost.
- jashmatthews 7y ago
  Compiled vs interpreted is not a useful distinction. Until fairly recently when Ignition was introduced, V8 had no interpreter. All the JS was compiled by the first tier “full codegen” The bigger difference is that the JVM is heavily optimized for performance after a long warmup and V8 needs to produce relatively fast code early during page loading. Java being much more static certainly helps warmup time but ultimately doesn’t really affect final performance. LuaJIT can beat C in some cases once it has time to compile all traces needed.
  - The_rationalist 7y ago
    V8 needs to produce relatively fast code early during page loading So for e.g backend js programs is it possible to ask v8 to take more time to optimize?
    - saagarjha 7y ago
      Why would would you want it to take longer to optimize?
      - The_rationalist 7y ago
        To get more time to generate betten codegen so a faster program (but slower "launch time")
        saagarjha 7y ago
        Most VMs will recompile long-running hot code; I’d assume V8 does this as well.
- PeCaN 7y ago
  Modern JS engines only interpret cold functions, and static vs dynamic doesn't matter once type information has been collected. The real reason is that HotSpot has 10+ more years of work put into it than V8.
  - ufo 7y ago
    Static vs dynamic still matters if the program is doing "dynamic stuff", where "dynamic stuff" means any thing that the JIT compiler is currently not able to optimize.
    - PeCaN 7y ago
      That's fair, but that's also stuff that you just can't really do in Java in general¹, so it's not useful for a comparison. The fact is that the vast majority of JavaScript code is pretty static and there's nothing preventing it from running as fast as Java other than man-decades of compiler engineering. ― ¹ Possibly excluding reflection. It's been a long time since I used the Java reflection APIs and I have no idea if you can do things like add class fields named after arbitrary strings at runtime. Even if you could, presumably this bails out of jitted code so the situation is basically the same as in JS.
gameswithgo 7y ago
dynamic types probably the first order reason and some unfortunate language choices being the 2nd order reason.
- jashmatthews 7y ago
  Dynamic typing means you pay the cost of trace recording or profiling to collect the type info. The actual code performance should ultimately be the same. JIT can remove the overhead of dynamic dispatch and replace it with a fixed call and a guard, for example. This isn’t possible with dynamically loading C libraries.
  - deleted 7y ago
    [deleted]
  - saagarjha 7y ago
    > JIT can remove the overhead of dynamic dispatch and replace it with a fixed call and a guard, for example. Only when the guard isn’t triggered constantly. With an actual type system you can remove many of these guards altogether instead of having them everywhere and falling back to the slow case when you get something unexpected.
    - jashmatthews 7y ago
      There are actually two problems here: How to handle things being re-defined and how to handle an unexpected type after speculation. In real high performance VMs the guard for redefinition is effectively a single instruction which is a CPU can easily branch predict and handle with out of order execution: https://chrisseaton.com/truffleruby/low-overhead-polling/ https://chrisseaton.com/truffleruby/low-overhead-polling/ With unexpected types we can use LuaJIT as an example: The type speculation guard will be turned into a conditional branch to a side trace. The slow path quickly becomes another fast path.

setr 7y ago

A couple obvious reasons would be compiled vs interpreted, and static vs dynamic, both of which bear some inherit runtime performance cost.

jashmatthews 7y ago
Compiled vs interpreted is not a useful distinction. Until fairly recently when Ignition was introduced, V8 had no interpreter. All the JS was compiled by the first tier “full codegen” The bigger difference is that the JVM is heavily optimized for performance after a long warmup and V8 needs to produce relatively fast code early during page loading. Java being much more static certainly helps warmup time but ultimately doesn’t really affect final performance. LuaJIT can beat C in some cases once it has time to compile all traces needed.
- The_rationalist 7y ago
  V8 needs to produce relatively fast code early during page loading So for e.g backend js programs is it possible to ask v8 to take more time to optimize?
  - saagarjha 7y ago
    Why would would you want it to take longer to optimize?
    - The_rationalist 7y ago
      To get more time to generate betten codegen so a faster program (but slower "launch time")
      - saagarjha 7y ago
        Most VMs will recompile long-running hot code; I’d assume V8 does this as well.
PeCaN 7y ago
Modern JS engines only interpret cold functions, and static vs dynamic doesn't matter once type information has been collected. The real reason is that HotSpot has 10+ more years of work put into it than V8.
- ufo 7y ago
  Static vs dynamic still matters if the program is doing "dynamic stuff", where "dynamic stuff" means any thing that the JIT compiler is currently not able to optimize.
  - PeCaN 7y ago
    That's fair, but that's also stuff that you just can't really do in Java in general¹, so it's not useful for a comparison. The fact is that the vast majority of JavaScript code is pretty static and there's nothing preventing it from running as fast as Java other than man-decades of compiler engineering. ― ¹ Possibly excluding reflection. It's been a long time since I used the Java reflection APIs and I have no idea if you can do things like add class fields named after arbitrary strings at runtime. Even if you could, presumably this bails out of jitted code so the situation is basically the same as in JS.

gameswithgo 7y ago

dynamic types probably the first order reason and some unfortunate language choices being the 2nd order reason.

jashmatthews 7y ago
Dynamic typing means you pay the cost of trace recording or profiling to collect the type info. The actual code performance should ultimately be the same. JIT can remove the overhead of dynamic dispatch and replace it with a fixed call and a guard, for example. This isn’t possible with dynamically loading C libraries.
- deleted 7y ago
  [deleted]
- saagarjha 7y ago
  > JIT can remove the overhead of dynamic dispatch and replace it with a fixed call and a guard, for example. Only when the guard isn’t triggered constantly. With an actual type system you can remove many of these guards altogether instead of having them everywhere and falling back to the slow case when you get something unexpected.
  - jashmatthews 7y ago
    There are actually two problems here: How to handle things being re-defined and how to handle an unexpected type after speculation. In real high performance VMs the guard for redefinition is effectively a single instruction which is a CPU can easily branch predict and handle with out of order execution: https://chrisseaton.com/truffleruby/low-overhead-polling/ https://chrisseaton.com/truffleruby/low-overhead-polling/ With unexpected types we can use LuaJIT as an example: The type speculation guard will be turned into a conditional branch to a side trace. The slow path quickly becomes another fast path.