Re: Java performance, CRTJVAPGM vs JIT

I find it contradcitory that IBM says JIT is faster, but caches
executable code after so many iterations.

I'm not sure I'm following you here. You seem to be implying that the
JIT compiler compiles each Java method every time it sees it until the
os400.jit.mmi.threshold is surpassed whereupon it will cache the
compiled code and subsequent invocations of that method will invoke the
cached compiled code. That is not how it works. The Java methods will
be interpreted each time until the JIT threshold is reached, whereupon
they will be compiled. Because by this time the compiler has
information about how the data passing through the application, it can
produce more efficient compiled code than a static compiler could
manage.

The following extract (from
http://www.javaworld.com/jw-03-1998/jw-03-hotspot.html) relates to
Sun's HotSpot JIT, but the points it makes are valid for various other
JIT compilers (including the IBM OS/400 JIT compiler):

"The advantages of dynamic compilation
The beauty of integrating a compiler with an interpreter is that it can
do things a normal static compiler simply can't do. In particular, it
can perform optimistic compilation and take advantage of runtime
information to do robust inlining.

Optimistic compilation
Because the interpreter is always available to run the bytecodes,
HotSpot's dynamic compiler can assume that exceptions and other
hard-to-optimize cases don't happen. If they do, HotSpot can revert to
interpreting the bytecodes. For a static compiler, optimizing in a way
that handles all the unusual cases is a very difficult and
time-consuming process. By ignoring those cases, HotSpot can
rapidly produce highly optimized code for the code that is most likely
to run. That produces a lot of bang for the buck -- significant
performance improvement for a small investment in optimization time.

Runtime information
The second major advantage of dynamic compilation is the ability to
take into account information that is known only at runtime. Again, the
details are proprietary. But it's not hard to imagine, for example,
that if a method is invoked in a loop that has an upper index value of
10,000, it's an immediate candidate for optimization. If, on the other
hand, the upper loop index value is 1, the optimizer will know to
ignore that method and let it be interpreted. Because a static compiler
has no way of knowing for sure what the values might be, it can't make
such judgements.

Inlining
One of the important optimizations HotSpot performs is inlining
frequently-called methods. That means that instead of being invoked
with the overhead of a method call, the method's code is copied into
the calling routine and executed as though it had been coded there. The
smaller the method, the more sense inlining makes. A one-line method
might spend more than twice as much time entering and exiting the
routine as it does executing.
Inlining provides a tremendous boost in performance, but it has a size
penalty. If every method in a program were copied to every place it was
called from, the program would balloon to five or ten times its
original size. But HotSpot optimizes only the critical sections of a
program. The 80/20 rule says that 80 percent of a program's runtime is
spent in 20 percent of the code. By inlining as much as possible of
that 20 percent, HotSpot can achieve a significant boost in performance
with an acceptable size penalty. Here, runtime information makes a big
difference, because HotSpot knows where to find that critical 20
percent.
As with all good things, of course, there are tradeoffs. If a method is
very large, the time spent entering and exiting it is only a small
fraction of its execution time. In such a case, the space required to
duplicate the method may not compare favorably to the time saved by
inlining. So HotSpot undoubtedly has an upper limit on how large an
inlined method can be. (The exact details, however, are proprietary.)
Finally, because HotSpot does optimistic compilation, it can inline
only the normally-executing methods, instead of every possible method.
So it can ignore difficult cases that rarely occur instead of working
hard to resolve them. That way, you get the maximum performance payoff
for the minimum optimization effort. "


However, if your application doesn't call the same methods repeatedly
(maybe it just has a single Main method), then JIT won't be of any
help, and CRTJVAPGM would be the way to go.

.

Relevant Pages

  • Re: Brian Kernighan, maybe Im not worthy, maybe Im scum
    ... what experienced programmers do, ... optimization, ... Thugs" ad nauseum fits that a lot more closely than discussing compiler ... be modified outside a loop, and guessing ...
    (comp.programming)
  • Re: What Delphi users really want (other than bugfixes)
    ... > Maybe you can't directly access SIMD from .NET code but what do you make ... Still waiting for any of that "JIT-only optimization" to happen ... in the real world and have it beat an AOT compiler... ... I would be more impressed if the JIT was able to overtake ye olde ...
    (borland.public.delphi.non-technical)
  • long(!) Re: need help on CFLAGS in /etc/make.conf please
    ... For example, MPlayer sets this high on purpose, so GCC will actually ... and the K&R compiler would've known exactly the kind of optimization we wanted. ... >> A msg from Richard Coleman, taken together with the GCC 3.x Known Bugs ...
    (freebsd-questions)
  • Re: SETF and variable issues in Self Similar program.
    ... The way to get a compiler to optimize a tail-call ... call optimization turned on. ... It changes the semantics of the language in a big way. ... In Common Lisp it has to interact with condition handling, ...
    (comp.lang.lisp)
  • Re: Programming languages
    ... >> execution time, ... That's not a good candidate for optimization. ... if there is comething the compiler ... António> programmers and those can't cope with anything else than ...
    (sci.lang)
Loading