comparison between native gcj and bytecode (fwd)

From: Keunwoo Lee (klee@cs.washington.edu)
Date: Sun Jan 05 2003 - 11:27:30 PST

  • Next message: Sorin Lerner: "Cecil administrative stuff"

    I was using the SableCC parsing toolkit for a while, and I'm still on
    their mailing list. Someone sent this along. Interesting stuff.

    ~k

    ---------- Forwarded message ----------
    Date: Sun, 5 Jan 2003 12:41:42 +0100
    From: Erik Poupaert <erik.poupaert@chello.be>
    To: Prof. Laurie HENDREN <hendren@cs.mcgill.ca>
    Cc: sablecc-list@sable.mcgill.ca
    Subject: comparison between native gcj and bytecode

    >>>> How is the speed performance of your executable vs. running the
    classfiles on a modern VM?

    There's a new and rather controversial comparison specifically comparing
    number crunching capabilities between several C++ compilers, several JDK
    versions, and gcj, the GNU native java compiler.

    http://www.coyotegulch.com/reviews/almabench.html

    The conclusions include:
    * the JDK has become significantly slower from version 1.3 to 1.4 (!!!) (and
    bigger!!!)
    * IBM's implementation beats Sun again.
    * The fastest number cruncher is still Fortran, with C++ barely catching up.
    * By supplying the same optimizations to the GCC backend, the performance of
    natively compiled Java already comes close to gcc/C++.

    Even though the Java run-time facilities of garbage collection,
    synchronisation, and exception handling reduce opportunities for
    optimization and introduce stricter rules, several new aggressive efforts
    should bring gcj's performance asymptotically close to gcc/C++:

    * completing AST unification and optimization for all gcc front ends through
    the tree-ssa project (http://gcc.gnu.org/projects/ast-optimizer.html)
    * advanced escape analysis
    * opportunities for global inlining

    Further, the introduction of templates in 1.5. will remove the need to do
    type checking whenever accessing an element of a collection, bringing gcj
    yet closer to C++ performance.

    There are reasons to believe that gcj already beats the JDK with regards to
    performance. And the future outlook is that ahead of time compilation still
    has very good potential left for optimization, while just in time
    compilation may very well already have hit its limits.

    _______________________________________________
    Cecil mailing list
    Cecil@cs.washington.edu
    http://mailman.cs.washington.edu/mailman/listinfo/cecil

    This archive was generated by hypermail 2.1.5 : Sun Jan 05 2003 - 11:27:35 PST