This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: GCC and Fortran eat GCJ for lunch at number crunching


Erik Poupaert writes:
 > 
 > >>>> Sure.  We hope to get some nice type-based optimizations from the
 > >>>> tree-ssa work.
 > 
 > It looks like an effort to re-group and optimize existing backend
 > optimizations: http://gcc.gnu.org/projects/ast-optimizer.html
 > 
 > The analysis kicks off with a rather alarming statement:
 > """
 > There is no single tree representation in GCC. Each front end defines its
 > own trees. This means that we would have to duplicate all this code for each
 > front end.
 > """
 > It sounds like gcj may first need to conform to some common, further
 > unspecified, tree representation,

It's fairly well specified, and not terribly different from what we
use now.

 > before being allowed to benefit from the
 > effort; or else duplicate the effort.

It's on my list of things to do.

 > >>>> In general, Java's rules are stricter than C's, yielding fewer
 > optimization opportunities.
 > 
 > The run-time facilities of garbage collection, synchronisation, and
 > exception handling seem to be the main culprits according to the
 > aforementioned papers; and behind the requirement for stricter rules.

There's much more than that.

The lack of templates hurts because of the need to do a checking type
conversion whenever accessing an element of a collection.  Array
bounds checking, obviously.  Also, Java's I/O is nested pretty deeply
so that there are many method invocations when using streams.

 > Therefore, paying the Java performance price, often makes sense;
 > but if the cost can be reduced, so much the better.
 > 
 > If I understand this right, there will always be a residual performance
 > penalty to pay, and Java will always be a bit slower than C++.

Yes, but we can get asymptotically close by using aggressive
optimizations.  In particular, we could compile a Java program and do
global inlining; the only thing that stops us doing that at the moment
is the way that the compiler is organized internally.  tree-ssa will
be the perfect opportunity to fix that.

Andrew.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]