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

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.

> 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...

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

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

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.

> 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.

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.

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.

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

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.

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.htm...

[2] https://www.microsoft.com/en-us/research/publication/spur-a-...

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/

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