4 ms·

Compiled to bytecode, I'm guessing the GP meant compiled to native.

Cyclone_ 10y ago
Possibly, just wanted to make sure there's no confusion.
danbruc 10y ago
Java is complied to native code, this is just delayed until execution. There are drawbacks like slower start-up performance due to the required JIT compilation but there are also advantages like being able to optimize for the exact machine you are executing on or even recompiling at run-time after profiling the running application and determining useful optimizations based on the actual work load. A really important aspect of using an intermediate language like Java, .NET but also LLVM does is that it reduces the amount of required code. If you have M languages each targeting N different platforms, then you need M * N traditional compilers. If you first compile to a common intermediate language and then from there to the targeted platform, then you only need M + N compilers.
- adwn 10y ago
  > advantages like being able to optimize for the exact machine you are executing on or even recompiling at run-time after profiling the running application and determining useful optimizations based on the actual work load Do you have examples (incl. measurements) for optimizations actually performed by a Java JIT compiler, which an ahead-of-time compiler can't perform due to a lack of runtime info? It is my understanding that those analyses and transformations which eke out the last few percentage points are so expensive that they're infeasible to do at runtime.
  - danbruc 10y ago
    HotSpot does some optimizations based on runtime information [1] but no numbers given here. For .NET Microsoft build SPUR [2] and the paper has a performance evaluation section although I just skimmed the paper and am not sure it contains the relevant comparisons. [1] http://www.oracle.com/technetwork/java/whitepaper-135217.html#hotspot http://www.oracle.com/technetwork/java/whitepaper-135217.htm... [2] https://www.microsoft.com/en-us/research/publication/spur-a-trace-based-jit-compiler-for-cil/ https://www.microsoft.com/en-us/research/publication/spur-a-...
  - rch 10y ago
    IIRC Java Numerics was a dead end precisely because the required optimizations went against the 'write once, run anywhere' ideal. I have heard of specialized Java runtimes that can do interesting things to approximate BLAS/Atlas, but never seen them first hand. I wanted to cite "Improving Java Performance Using Dynamic Method Migration", Lattanzi 2004, but the site hosting the paper isn't loading at the moment. -- http://math.nist.gov/javanumerics/ http://math.nist.gov/javanumerics/
  - spullara 10y ago
    Inlining of hot, small methods. Call site specialization (for virtual calls, reflective calls and invokedynamic calls). There are others but I'm not an expert on hotspot.
  - sdfsdufihwfuhdf 10y ago
    There are many. One really useful one is that final variables will be pulled out along with their dead code branches. Say I have a library which allows different "sizes" of a list. The fastest way to sort that list depends on the number of max entries. With JIT you can set the size when you create the object, and if JVM knows that value can't change it will pull out all the branches for different sizes and run only the one for selected size. There's no way to know which sizes will be selected at compile time if the lists can be dynamically created, so a static compiler can never pull out all the checks the list size. This is a simple example but the JIT is very smart and makes a big speed difference in practice. It's the main reason Java is faster than C in some benchmarks
  - mike_hearn 10y ago
    The JVMs profile-guided optimisations are generally a 10-20% win for Java and more for Scala, I believe. They aren't that expensive to do. When you get into languages like Ruby or Python it just goes off the charts, you are getting orders of magnitude better performance from profile-guided JIT compilers. As an example of what they can do, take de-virtualisation. Virtual method calls are expensive. Java method calls are virtual by default. The JVM profiles method calls and analyses the class hierarchy to discover which ones can be de-virtualised. That's a big win. C# requires programmers to manually specify which methods are virtual because .NET doesn't use profile-guided JIT compilation. In some cases (admittedly I've only seen artificial examples) this optimisation is so powerful you can write Java programs that completely trash C++ programs, e.g. a program that uses a command line switch to pick a subclass of a virtual base class and then runs method calls on that object in a tight loop. Java will devirtualise the call based on the observation that only one target is ever used, then inline it, then do loop opts on the inlined version.
    - ygra 10y ago
      I'd say C# makes methods not virtual by default because it's a saner default. When writing a class you shouldn't make everything virtual, that should be a conscious decision to actually design a class for extensibility.

Possibly, just wanted to make sure there's no confusion.

Java is complied to native code, this is just delayed until execution. There are drawbacks like slower start-up performance due to the required JIT compilation but there are also advantages like being able to optimize for the exact machine you are executing on or even recompiling at run-time after profiling the running application and determining useful optimizations based on the actual work load. A really important aspect of using an intermediate language like Java, .NET but also LLVM does is that it reduces the amount of required code. If you have M languages each targeting N different platforms, then you need M * N traditional compilers. If you first compile to a common intermediate language and then from there to the targeted platform, then you only need M + N compilers.

adwn 10y ago
> advantages like being able to optimize for the exact machine you are executing on or even recompiling at run-time after profiling the running application and determining useful optimizations based on the actual work load Do you have examples (incl. measurements) for optimizations actually performed by a Java JIT compiler, which an ahead-of-time compiler can't perform due to a lack of runtime info? It is my understanding that those analyses and transformations which eke out the last few percentage points are so expensive that they're infeasible to do at runtime.
- danbruc 10y ago
  HotSpot does some optimizations based on runtime information [1] but no numbers given here. For .NET Microsoft build SPUR [2] and the paper has a performance evaluation section although I just skimmed the paper and am not sure it contains the relevant comparisons. [1] http://www.oracle.com/technetwork/java/whitepaper-135217.html#hotspot http://www.oracle.com/technetwork/java/whitepaper-135217.htm... [2] https://www.microsoft.com/en-us/research/publication/spur-a-trace-based-jit-compiler-for-cil/ https://www.microsoft.com/en-us/research/publication/spur-a-...
- rch 10y ago
  IIRC Java Numerics was a dead end precisely because the required optimizations went against the 'write once, run anywhere' ideal. I have heard of specialized Java runtimes that can do interesting things to approximate BLAS/Atlas, but never seen them first hand. I wanted to cite "Improving Java Performance Using Dynamic Method Migration", Lattanzi 2004, but the site hosting the paper isn't loading at the moment. -- http://math.nist.gov/javanumerics/ http://math.nist.gov/javanumerics/
- spullara 10y ago
  Inlining of hot, small methods. Call site specialization (for virtual calls, reflective calls and invokedynamic calls). There are others but I'm not an expert on hotspot.
- sdfsdufihwfuhdf 10y ago
  There are many. One really useful one is that final variables will be pulled out along with their dead code branches. Say I have a library which allows different "sizes" of a list. The fastest way to sort that list depends on the number of max entries. With JIT you can set the size when you create the object, and if JVM knows that value can't change it will pull out all the branches for different sizes and run only the one for selected size. There's no way to know which sizes will be selected at compile time if the lists can be dynamically created, so a static compiler can never pull out all the checks the list size. This is a simple example but the JIT is very smart and makes a big speed difference in practice. It's the main reason Java is faster than C in some benchmarks
- mike_hearn 10y ago
  The JVMs profile-guided optimisations are generally a 10-20% win for Java and more for Scala, I believe. They aren't that expensive to do. When you get into languages like Ruby or Python it just goes off the charts, you are getting orders of magnitude better performance from profile-guided JIT compilers. As an example of what they can do, take de-virtualisation. Virtual method calls are expensive. Java method calls are virtual by default. The JVM profiles method calls and analyses the class hierarchy to discover which ones can be de-virtualised. That's a big win. C# requires programmers to manually specify which methods are virtual because .NET doesn't use profile-guided JIT compilation. In some cases (admittedly I've only seen artificial examples) this optimisation is so powerful you can write Java programs that completely trash C++ programs, e.g. a program that uses a command line switch to pick a subclass of a virtual base class and then runs method calls on that object in a tight loop. Java will devirtualise the call based on the observation that only one target is ever used, then inline it, then do loop opts on the inlined version.
  - ygra 10y ago
    I'd say C# makes methods not virtual by default because it's a saner default. When writing a class you shouldn't make everything virtual, that should be a conscious decision to actually design a class for extensibility.