[EMAIL PROTECTED] wrote:
Matthew French wrote:
Why can a JIT not achieve 110% of native performance? (Assuming that we strip out the compile time and compare like with like.)
because it is mathmatically not possible. Its like giving 110% of your best effort. It is an expression.
I believe Matthew was asking whether it would be possible for dynamically optimized code to exceed the performance of statically compiled native code. The answer to this is yes, it is certainly possible.
The reason I say 110% is that binary code is usually compiled for the lowest common denominator. So x86 code targets a 386, and Sparc binaries target UltraSparc v8 or older processors.
I run gentoo for this very reason.
Running gentoo only partially addresses the architecture issue. It won't help you on a server where the hardware is dynamically partitioned (eg hypervisor) and so may be different from one day to the next. More importantly, it does not address either of the other motivations for dynamic optimiztion: optimizing across the boundaries created by libararies, and optimizing for dynamically changing user workloads.
The advantage a JIT has is that it knows exactly where it is being compiled, so in theory can make use of as much hardware assistance as it can.
Achieving parity with native performance would require changes to Java itself. For instance ask the boys at Intel how they
feel about Java's Math implementation being written in Java and the bytecode support thereof.
I am not sure what you mean by this. If you look here http://www.shudo.net/jit/perf/, you see that the Sun JVM can perform to within 3% of the fastest C compiler (Visual C++) on the numeric benchmarks, and moreover it outperforms any of the C compilers on a number of them (FFT, Monte Carlo).
Dynamic optmization is changing the performance game, and that this technology is moving very fast. I strongly encourage those who are interested in performance to read up some of the literature on this subject---it is a hot field (see my previous post for a few pointers).
--Steve
