EduardoS (no.delete@this.spam.com) on November 19, 2012 8:23 am wrote:
> Wilco (Wilco.Dijkstra.delete@this.ntlworld.com) on November 19, 2012 7:59 am wrote:
> > As a compiler expert I'm sceptical that virtual machines can ever deliver close to native performance. The
> > key issue with JIT compilation is that you just do not have the resources of a native compiler. It doesn't
> > help that many intermediate bytecodes are completely unoptimized, making the problem far worse (what is the
> > point of Java compilers emitting x * 0 in byte codes?!?).
> > What you actually want to do is to perform as much
> > work as possible in the static compiler and end up with
> > a highly optimized intermediate code that just needs
> > to be converted into the final target assembly with a quick
> > peephole pass. For example you want to do register
> > allocation to a virtual 16-register target (so it maps trivially to Thumb-2, ARM64 and x64).
>
> Yep, JITs will hardly outperform time consuming compilers, but what prevents a virtual machine
> from using a background compiling service to store native images like .Net ngen does?

That certainly helps, but you're still doing it multiple times on targets which may not have a lot of resources. What is more efficient - every phone compiling every bit of software you download, or just run a highly optimized binary which was compiled once with optimal settings on fast hardware?

So with JIT compilation you get the double whammy of having to waste energy on compilation as well as waste energy due to this compilation not being optimal.

> > The other issue is C++ vs managed languages. GC, exceptions and other features have a lot of overhead
> > (even when unused), so you're never going to be anywhere near as fast as a well written C++ program.
>
> First, C++ also have exceptions, they does not reduce performance but
> also remove the exception handling code from the critical path.

Exceptions most definitely reduce performance, even for code that doesn't use it. And that is true for C++ too, but to a lesser extent. At ARM we put a lot of effort into compiling C++ with exceptions almost as efficiently as without, so it is possible to get close. But in some languages it gets really difficult as just about any operation can cause an exception, blocking most optimizations.

> Second, today, in the real world, where cache locality becomes more important than micro-optimizations
> GC actually improves performance in some cases over simple memory management, sure, one can
> implement a more complex memory management in C++, one can even implement GC in C++, it can
> be done in assembly as well, but it is so complex that nobody does.

Cache locality is certainly important, but GC doesn't solve that - in reality it actually makes it worse. And that is before we consider the actual overhead of the collection itself, often having to stop all threads for long periods. Then there is the optimization overhead and extra tables causing code bloat.

> So only left is the overhead of other features wich you didn't even listed.

For example arithmetic with overflow, array bounds checks, null pointer checks, assuming any pointer access may cause an exception, multithreading support etc etc.

> And you completly forgot to mention the uncomparable effort already spent to make C++ compilers.

It's not like languages like Java or C# are new. It is significantly harder to write a good compiler for them, and even then you can never get close to C++ performance. Many optimizations have to be disabled or turned extremely conservative as an exception or GC may occur at any time.

Obviously you could argue all the overhead is worth it as some of the features allow programmers to write code faster. Whether that is a good or a bad thing is a different discussion altogether...

Wilco