hello?

[dan]

Shane McDonald wrote:

>
>   I don't know if anyone has looked at HPCJ, the high-performance compiler
> for Java from IBM's AlphaWorks.  I've only used it on NT briefly, but in the
> one benchmark test I ran on it, which does a bunch of mathematical
> manipulations to an array of floats, I found the executable I produced
> actually ran slower (118 seconds as opposed to 96 seconds) as when the
> program was run with the JIT in JDK 1.1.6.
>
>   Now, I don't know anything about HPCJ, and this result makes absolutely no
> sense to me, but what kind of performance should we expect from GCJ as
> compared to JDK 1.1.6 with a JIT?  I'm trying to convince the great unwashed
> here to move to Java, but they keep harping on performance.
>
> Shane McDonald

This list seems to provide more questions than answers.  I'm not an expert on
the topic, but I play one at work.  As far as the less than stellar performance
of HPCJ, I believe that IBM has spent little or no effort in the optimization
stage of their compiler.  Their main goal, to date, has simply been to get it
working.  As such, aside from the delays at start-up time for the compilation
stage of the JIT, the JIT should be equivalent in performance to HPCJ.

For my work, HPCJ is useless.  It doesn't support Swing.  Pretty much every
program I write depends upon Swing.  I think that Tower/J is in the same boat,
if my memory serves me correct.  I imagine that GCJ will be in the same boat, as
well, at least until development really picks up for it.

The main benefit that GCJ has that the others don't have is that GCJ is
leveraging its optimization and assembler stages from the EGCS development
effort.  The nice thing here is that all of the optimization stages are already
working (sorry, IBM, HPCJ has a long way to go here).  Likewise, since EGCS runs
on just about every platform under the sun (no TM, no pun intended), porting GCJ
to other platforms should be relatively painless.  Of course, jdk1.2 has tons of
new native code that needs to be ported (a lot of the java2d stuff relies on
native calls, and must be ported on a per-platform basis), so I would figure
there will be similar lag times between support for new versions of jdk as in
the Blackdown ports for Linux (the Linux release lag the NT and Solaris releases
by a few months).  Oh well, that's the price we pay for trying to be on the
bleeding edge.

One question I have about GCJ concerns how it handles dynamic class loading.
Will GCJ attempt to compile the dynamically loaded class, kind of like a JIT,
except that the compiled class will be stored persistantly after its first run?
Or will the executable of GCJ have a full JVM built into it as well?  It seems
like the former would be harder to get to run seemlessly, but would result in
the best performance (both speed-wise and memory-wise).  For that matter, how
will GCJ handle security issues?  Through GCJ's support for dynamic class
loading, it seems like GCJ should be able to handle applets.  Is this the case?
It would be really cool if GCJ acted like a JIT for .class files, storing the
compiled code persistantly for future runs.  In that case, you'd have all the
benefits of a JIT, combined with the benefits of a compiler.  This is
particularly true if GCJ is eventually made into a plug-in, kind of like Sun has
done with the Java Plug-In / Activator project (for IE, they wrap the JVM in an
Active-X control--so long as IE supports Active-X, the Java Plug-In will also be
supported!  very clever...).

-dan
dankirkpatrick@iname.com
dan.kirkpatrick@int.com