19 ms·

"Java isn't perfect but it's the defacto language for anything that doesn't need to be compiled" Java is a compiled language.

dangravell 10y ago
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
    - 10y ago
sdfsdufihwfuhdf 10y ago
I tend to group languages into machine-code, VM, and interpreted. This tend to lead to similar tradeoffs within the group...with the exceptions of Golang. in my mind: interpreted = why would you ever use a language like this? VM = fast, safe, but going to use a lot of memory machine code = fastest, low level HW access, usually unsafe
- Tuna-Fish 10y ago
  Also Swift and Objective-C. For some reason people think they are fast because they are compiled. Yes, they are fast so long as you only write C in them. Actually using their features is typically way slower than Java.
- deleted 10y ago
  [deleted]
- hota_mazi 10y ago
  > I tend to group languages into machine-code, VM, and interpreted. This distinction doesn't make much sense in 2017: most languages are blends of all these things with technologies like VM's, JIT, Ahead-of-time compilation, etc...
  - sdfsdufihwfuhdf 10y ago
    Underneath they're still divisible. AoT is always native machine code. JIT/VM/Bytecode is VM, basically machine code on demand. Then there's interpreted code which has worked the same way for forever

dangravell 10y ago

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
  - 10y ago

sdfsdufihwfuhdf 10y ago

I tend to group languages into machine-code, VM, and interpreted. This tend to lead to similar tradeoffs within the group...with the exceptions of Golang. in my mind: interpreted = why would you ever use a language like this? VM = fast, safe, but going to use a lot of memory machine code = fastest, low level HW access, usually unsafe

Tuna-Fish 10y ago
Also Swift and Objective-C. For some reason people think they are fast because they are compiled. Yes, they are fast so long as you only write C in them. Actually using their features is typically way slower than Java.
deleted 10y ago
[deleted]
hota_mazi 10y ago
> I tend to group languages into machine-code, VM, and interpreted. This distinction doesn't make much sense in 2017: most languages are blends of all these things with technologies like VM's, JIT, Ahead-of-time compilation, etc...
- sdfsdufihwfuhdf 10y ago
  Underneath they're still divisible. AoT is always native machine code. JIT/VM/Bytecode is VM, basically machine code on demand. Then there's interpreted code which has worked the same way for forever