From: Niklas Gustafsson <niklasg@asymetrix.com>
Subject: Re: When can we expect a faster Java?
Newsgroups: comp.lang.java.api,comp.lang.java,comp.lang.java.tech
Date: Fri, 21 Feb 1997 17:35:17 -0800
Organization: Asymetrix Corp.

nouser@nohost.nodomain wrote:
> 
> In article <5ebfjt$iti@mtinsc05.worldnet.att.net> RichardGBaldwin@worldnet.att.net (Richard Baldwin) writes:
> 
>    There is a product named Supercede that can produce a Win95 executable from
>    Java source code.  They make a lot of impressive claims about speed, but I
>    haven't tried it.
> 
>    http://www.supercede.com/
> 
> I did some simple numerical benchmarks, and SuperCede with bounds
> checks runs at around 1/3 the speed of optimized C without bounds
> checks.  That's a big improvement over JDK, and it's almost to the
> point where you can use Java for most applications.  I hope (but
> haven't verified yet) that SuperCede also eliminates some of the
> really simplistic and inefficient implementations of string
> manipulations in JDK.
> 

Thomas was kind enough to share his benchmark with us, both C and Java
code, and we, too observed the 3x performance difference. However,
the Java program had a subtle problem which prevented our optimizer
from being effective. It was structured like this:


	void test()
	{
	    try {
		// Body of the test.
	    }
	    catch (Throwable t) {
		...
	    }
	}

	void foo()
	{
	    test();
	}


The very subtle problem with this, is that the time-critical code
was nested inside a try-catch block. For every single implementation
of exception handling that I have experience with, be it Ada, C, C++,
or Java, exception scopes are a very good way to cripple optimizers.

So, by making a mechanical edit to the program:


	void test()
	{
	    // Body of the test.
	}

	void foo()
	{
	    try {
    	        test();
	    }
	    catch (Throwable t) {
		...
	    }
	}

I was able to get it to match the performance of the C version
of Thomas' benchmark, *without turning off bounds checking*. In
other words, I did not allow the optimizer to do anything unsafe.

This posting of mine wouldn't be necessary were it not for the
opportunity to point out the very non-obvious implication of having
try blocks around in your code.
 
There is nothing in the language that keeps one from making a
mistake like this, in fact as the definition stands, it's not even
a mistake, and I doubt that it affects the performance of Java code
under the JDK, but any compiler's global optimizer will have problems
with source code like this. It's just something to be mindful about
when programming for a high-performance system like SuperCede, that's all.

I'm sure that as more systems that treat Java as a regular compiled 
language are available, this coding style issue is going to be more
and more critical.


Niklas Gustafsson
Asymetrix Corp.