RE: Java and CPU

Joe Pluta wrote:

>If I'm wrong, please show me some numbers!

It is particularly hard to compare Java and RPG at a load-add-store
level.  I don't have good stuff on my own.  However, I know a lot
about basic compiler technology and I base my claims on RPG
versus Java based on what I know about compilation in general
and also some specific work I've done with Java versus C.

I do have some code that is largely procedural that enables me
to track the basic codegen of Java versus C.  Its main defect is that
it minimizes the O-O procedure call penalty and the garbage collection
penalty, but for the load-add-store part, proper, it is a good predictor.

And, I certainly see many applications where these penalties are
minimized.  In JIT, for instance, the polymorphism penalty can actually
be less than in direct execution, because it can sometimes pretend
methods are final based on the dynamic situation of what classes
have actually been loaded.  It can then "inline" the code (ie treat
the next method call as an old-style assembler code macro and
make a extra, local copy of the code, elimiating the call overhead).

So, the "big penalty" for O-O can sometimes be
minimized, just as it can in C++ with inlining (inlining came in in a
big way with C++, though C sometimes does it, too).  The
JIT has to work harder than a compiler at it, but this part continues
to improve and conventional compilers are correspondingly
more mature and improve at a slower rate.  Direct execution can
play most of these games and has the leisure to optimize things
that even a two pass JIT won't do.

I have seen the ordinary load-add-store difference steadily
narrow in any event.   Unfortuantely, I can't publish
numbers, except in a general  way, due to licensing
restrictions from the benchmark vendor
from whom I obtained the code.

At COMMON, I put up some underlabelled charts when I talk
about this, but in the end, it unfortunately boils down to "trust me"
because I can't get specific or even point you at the source I use.

It's a lawyer thing.

In principle, however, if you knew where to look, you could prove
this for yourself without a great deal of work.

I have generally found, in my work with customers
that most performance problems do not relate to Java proper,
but rather to something relating to how OS/400 is invoked or how
the Java class library or third party application library is invoked.
Fix that and no one seems to care much about the codegen.



Larry W. Loen  -   Senior Java and AS/400 Performance Analyst
                          Dept HP4, Rochester MN


+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---