From: Robert Clapp <bob>
To: jon@sep.Stanford.EDU
Cc: arnaud@sep.Stanford.EDU, biondo@sep.Stanford.EDU, bob@sep.Stanford.EDU,
        krl@sep.Stanford.EDU, matt@sep.Stanford.EDU
Subject: Speed Issue
Date: Fri, 8 Sep 1995 11:03:39 -0700

Speed issue.

The magic number currently seems to be 5 (Java compared to C).

Sun has been obviously attempting to keep the issue fairly fuzzy.

The documentation, which states that Java's speed with its line
by line byte code interpreter is fairly fast is approximately 1/30
of the speed for programs with a number of loops (when compared to
C) better for other applications.  


There is hope though,

1) Already some initial attempts at improving the representation of the
   byte code which has reduced its rate down approx. 17

2) The factor 5 was only the first attempt at writing a translator.
   Currently java is translated to C and then compiled with standard
   gcc, my guess is that this number will come down significantly
   fairly quickly.  


I didn't run a C/Java test but if you want to see a fortran/java
test: 

1) rlogin lithos -l sep
2) cd /r4/krl/oldr4
3) /bin/time java temp
4) /bin/time a.out
5) source codes:
    temp.java
    test1.f




An old article from the mail archives (one of the few, they seem to be
sellective on what they include, limiting it to positive comments about
the speed issue).

-----------------------------------------------------------------------------


Has the bytecode gone native?

sbk@netcom.com
Thu, 6 Jul 1995 11:04:59 -0700 (PDT) 

        Messages sorted by: [ date ][ thread ][ subject ][ author ] 
        Next message: Jonathan Payne: "Re: available() always returns 0?" 
        Previous message: Oscar Bermeo: "hotjava's deamon" 

I have a couple of questions about the bytecode to native code
translator that is in the works.

- What is the status of the implementation? And is anyone working on
an x86 version?

- It seems like there are at least two ways in which the translator
can be used -- to statically convert compiled java classes into
native code, or to augment the interpreter so it can dynamically
convert a stream of java bytecodes into native code for further
execution. Is the plan for the translator coming from the java team
to do both?

Out of curiosity, I wrote a very small subset java bytecode
interpreter that dynamically and naively converts bytecode for a
method into Sparc code prior to invoking the method. For what it is
worth, here is what I did and found. The test program adds a couple
of arrays. The "main()" method of the benchmark is translated into
Sparc code and invoked. No optimization of any kind, so there is
considerable memory traffic. Each bytecode is converted into about 4-5
sparc instructions.

For instance, the bytecode corresponding to
bipush 10
is converted to (the machine code equivalent of)
mov 0xa, %l0
st %l0, [%i0 + 4]
add %i0, 4, %i0

There is no bounds checking.

Here is what I got, this is on a Sparc10 running Solaris 5.4.

C, gcc2.5.6 -O : 2.0u 0.0s 0:02 86% 0+0k 0+0io 0pf+0w
translator: 10.0u 0.0s 0:10 94% 0+0k 0+0io 0pf+0w
java interpreter: 60.0u 0.0s 1:03 94% 0+0k 0+0io 0pf+0w

It is use-once code, but if you are curious, the interpreter is at
ftp://ftp.netcom.com/pub/sb/sbk/foo.tar.gz. Don't expect to run
anything more than the benchmark :-)

The java version of the test program is:
class perf
{
public static void main(String argv[])
{
int a[], b[], c[], i, j;

a = new int[10000]; b = new int[10000]; c = new int[10000];

for (j=0; j<1000; j++)
for (i=0; i<10000; i++)
a[i] = b[i] + c[i];
}
}


From: William Symes <symes@caam.rice.edu>
To: matt@sep.stanford.edu (Matthias Schwab)
Cc: jon@sep.stanford.edu, gock@masc39.caam.rice.edu (Mark Steven Gockenbach),
        senren@masc39.caam.rice.edu (Senren Liu),
         symes@masc39.caam.rice.edu (William Symes)
Subject: Re: Java Linpack benchmark
Date: Mon, 18 Mar 1996 08:34:17 -0600 (CST)

I absolutely agree with both points. In fact I have cut a deal with a Cray 
alumnus who wants to play with Java to do exactly that - port at least part 
of HCL to Java and see how it works. The crunch parts stay in C/C++/Fortran.
We've been a bit slow getting started, but I expect to have some results
to show in June.

I am guessing that this port will take advantage of the design work in HCL 
and the similarity in syntax between C++ and Java, so not be too hard. However
the only way to tell is to try it....

> 
> 
> This is funny. Jon just mailed me the same posting 1 minute before
> you did. Thanks. 
> 
> I postulate two conditions for a Java version of CLOP-HCL:
> 
> 	o the intrinsic compute intensive part of CLOP-HCL does
> 		not need to be "object-oriented": e.g. a C-subroutine
> 		can implement a convolution operator that in turn 
> 		is invoked by a Java operator object. Contrarily,
> 		the complex object-oriented part (for example the 
> 		cooperation of solver and operator) is not compute 
> 		intensive. For that complex part we could choose
> 		the "easiest" language, maybe Java. However, the 
> 		speed of that "meta-language" would not matter much.
> 
> 	o Java's libraries for www support are still changing and
> 		some are poorly designed. However, Clop-HCL would 
> 		exclusively rely on the math library and the basic 
> 		language design. These parts seem to be stable.
> 
> Later when Java generates faster code (as some programmers promise) 
> it may be time to translate compute-intensive subroutines to Java
> and to make a future CLOP-HCL fully "networked". Until then some 
> simple, albeit slow, examples would be cute. 
> 
> Is the advantage of Java possibly being a nicer language great enough
> to rewrite existing CLOP-HCL C++ code? Maybe ... 
> 
> 	Just my 2cents in case anyone wondered ...
> 
> 	Matt
> 
> 
> Joel Schroeder writes:
>  > I thought you might be interested in this, since I've heard you
>  > talking about doing CLOP in Java.
>  > 
>  > Joel
>  > 
>  > > NA Digest   Sunday, March 17, 1996   Volume 96 : Issue 11
>  > > 
>  > > Today's Editor:
>  > > 
>  > >     Cleve Moler
>  > >     The MathWorks, Inc.
>  > >     moler@mathworks.com
>  > 
>  >    .
>  >    .
>  >    .
>  > 
>  > 
>  > > From: Jack Dongarra <dongarra@cs.utk.edu>
>  > > Date: Sat, 16 Mar 1996 12:35:51 -0500
>  > > Subject: Linpack Benchmark in Java
>  > > 
>  > > Linpack Benchmark in Java
>  > > 
>  > > The Linpack Benchmark is a numerically intensive test that has
>  > > been used for years to measure the floating point performance of
>  > > computers. It has been ported to Java and can be run as an applet.
>  > > 
>  > > If you are interested in seeing how your Java interface performs
>  > > on numerical computations pointing your java-capable
>  > > web browser at http://www.netlib.org/benchmark/linpackjava/
>  > > 
>  > > Jack Dongarra and Reed Wade
>  > > 
>  > > 
> 

