exe vesus class ... !

[Tom Tromey]

>>>>> "Mohammad" == Mohammad O'mara <momara@iti-idsc.gov.eg> writes:

Mohammad> According to my knowledge , I know that the ( .exe ) file is
Mohammad> much faster than the CLASS file being interpreted by a
Mohammad> virtual machine , for the same source code ... "
Mohammad> Ahead-of-Time Compilation versus Interpretation " but this
Mohammad> wasn't the case when I did that using gcj !

Ahead-of-time compilation isn't always faster.  Much depends on the
application and also the interpreter you are using.  For instance some
JITs can beat the performance of gcj-compiled code, at least at
present.

Mohammad> and if I'm interested in generating ( exe ) files ,how can I
Mohammad> make my ( exe ) faster ?, if I can , given that I used ( -O3
Mohammad> ) switch and it didn't jump me to the level of 4 times
Mohammad> faster ( exe ) file to be competing with JVM results ..

We haven't done much performance tuning of gcj.  Some has been done
(I'm particularly thinking of Hans Boehm's work on thin locks, which
does not appear in gcj 3.0 -- but will appear in 3.1).

So one way to proceed would be to find out where the slowdown occurs,
and then address that.  This might require fixing problems in the
compiler, or perhaps the runtime (for instance if your application
uses a class in libgcj which has poor performance).

This is probably an unsatisfying answer.  Most of our energy has gone
into writing class libraries, and improving the basic functionality of
the compiler.  Performance, weirdly, hasn't been a very high priority.

Mohammad> and finally , has the RTL got to do anything with optimizing
Mohammad> the code even more than what ( -O3 ) does ?

RTL is an internal detail of the compiler implementation.  It is
pretty much irrelevant to this conversation.

Tom