Re: native code performance

Marco Trudel wrote:
> Marco Canini wrote:

>> I've been experimenting with using gcj native binary compilation for
>> the following problem.
>> I'm seeking to integrate the weka machine learning toolkit in a C++
>> program. Weka is 100% java code.
>> I've learned about CNI and it sounds quite an appealing solution for
>> the integration part. However, before writing the C++ code, I tried to
>> see what the performance are when the java code is compiled to a
>> native binary.
>> Basically what I did was the following:
>> I compiled the weka source code using gcj (ecj) to a .jar (bytecode).
>> I wrote a simple program that actually uses the toolkit to run a
>> classifier.
>> I compiled this program into a class.
>> I linked everything into a native binary with the -findirect-dispatch
>> option.
>>
>> As I'm new to gcj I might have done something wrong during this
>> process, but it seems alright given my understanding of the gcj manual.
>> Although I actually don't know where I should have enabled the
>> optimizations (-O2)
>>
>> Now comes the unattended result.
>> I ran the native binary and it took 13.4s to execute a classification
>> test.
>> When using sun's java, the program (in this case the .class) executes
>> in 3.2s!
>> I had expected a native binary to outperform the VM.
>>
>> So here my question is very simple: is this result realistic or i'm
>> just missing the magic to speed the native binary up?
>
> There has just been a similar question on the list about bad
> performance. Once he used optimization (-On), I think he was happy.
> So try with optimization. Just add for instance -O2 to all gcj calls if
> you don't know where it's needed...

It depends on the JVM. Sun's server jit can have spectacular performance
on some code bases, way exceeding anything you can do with an ahead-of-
time compiler. This happens if, for example, the jit notices that an
inline call can be devirtualized. Sometime people don't realize that
today's jits are doing a lot of aggressive optimizations, sometimes just
as much as an ahead-of-time compiler.

Andrew.