Subject: Re: Benchmarking scientific Java

From: Phil Sweany <[email-masked]>
Date: Wed, 19 Feb 1997 08:28:59 -0500

Walter Bays wrote:
>>>  >...
>>>  > Would this mailing list be an appropriate venue for me to outline what
>>>  > SPEC is doing, and to solicit comments and input?
>>>  

	I certainly hope so.  I'm very interested in that information.

And Dan Kelley responded:
>>>  I am a scientist who uses C and C++ extensively.  I am attracted to
>>>  the cleanliness of the java design.  I think java may be close to C++
>>>  in usefulness, even superior in some respects.  The main exception at
>>>  present seems to be the lack of a suite of object libraries for such

	I suspect that the lack of object libraries has to do with
	the compilation tools currently available (and not available.)
	More on that below.

>>>  things as matrix operations, mathematical operations including
>>>  optimization and differential equation solution, etc.  Such things
>>>  exist in several forms in the C, C++ and FORTRAN (yup, I said I was a
>>>  scientist!) worlds, and in the increasingly popular matlab community.
>>>  
>>>  Still, not all science applications need this box of tools, and we
>>>  might expect the tools to become available over time.  This leaves
>>>  just a single worry in my mind -- speed.  From what I've read, java is
>>>  very much slower than C++.  (Mostly the statements are quite vague --

	Yes, its slower NOW, due to compilation tools (or lack of them)
	but that will change (I hope.)

>>>  hence the need for reasonable benchmarks.)  Scientists need speed.  We
>>>  spend a lot of our time writing proposals to buy the hot box of the
>>>  year, because last year's box produces results with last year's
>>>  accuracy and scope, and these have already been published.
>>>  
>>>  I've read that java is 15 times slower than C++.  Given a doubling of

	OK, NOW its time for my "promotional" pitch.  The reason that 
	java is slow is because it's basically an interpreted language, 
	at this time.  Yes, there is a compiler that translates java to 
	java byte code which is machine independent but the byte code is 
	then interpreted to actually execute the java program.  There 
	are excellent reasons for this having largely to do with the 
	convenience of executing java as you download it from the net.  
	The translation (interpreter) time is lost in the time to 
	download and actually compiling the byte code, while it would 
	lead to faster execution, would be cumbersome for that sort of 
	use and again the speed gains would be inconsequential when 
	compared to the time to download.

	All that said I certainly anticipate that Java will be used
	in more "traditional" applications where you actually want to
	compile your code so that the executable is as fast as possible.
	That's where I come in (well I and a host of others.)  I'm
	a compiler writer (when I'm not busy teaching) and I plan to
	build a compiler for java byte code that could be easily 
	targeted to a wide variety of computer platforms.  This 
	should give you the efficiency you need.  If anything I
	think that java has some features that should make it possible
	to generate more efficient code than is possible for C and
	C++.  But time will tell.

>>>  computing power every 1.5 years, this means switching to java means
>>>  going back nearly 7 years, in terms of ability to accomplish computing
>>>  work.  Put another way, a model simulation that used to take months
>>>  would now take years.  Therefore, the year-end paper describing the
>>>  results turns into a decade-end paper ... except that it won't,
>>>  because the scientist will have lost his/her job in the meantime,
>>>  since tenure panels don't appreciate deliberate choices to slow down
>>>  productivity so dramatically.
>>>  
>>>  PS: I'm hoping that the readers of this list are science-types, not

	Well, I'm a computer science type and as we all know, any
	discipline that includes "Science" in the name, ain't one,
	but I hope I'm "allowed" to be a reader as well.  I'm "here"
	because I want to hear of science and engineering uses of
	Java, to motivate building a Java bytecode compiler.

>>>  java-types, so that they take my comments as personal experience
>>>  instead of as a trashing of a language which is clearly lovely for
>>>  many purposes.
>>>  

	Phil Sweany
	Computer Science 
	Michigan Technological University

---

From: "Dan E. Kelley" <[email-masked]>
Date: Wed, 19 Feb 1997 09:54:21 -0400

Phil's comments echo those of several other friendly folks who sent 
advice to me more privately.  Most were fellow scientists, and all are 
hopeful that java speed will increase dramatically over time, becoming 
comparable to C++ or fortran.  All of this underlines the need for good 
benchmarks, so that cautious folks like me can watch the continuing 
improvement of java and decide when to jump on the bandwagon.

Dan.

> 	Michigan Technological University

Dan E. Kelley                   internet:         mailto:[email-masked]
Oceanography Department         phone:                       (902)494-1694
Dalhousie University            fax:                         (902)494-2885
Halifax, NS, CANADA, B3H 4J1    WWW:  http://www.phys.ocean.dal.ca/~kelley

---

From: Paul Gray <[email-masked]>
Date: Wed, 19 Feb 1997 11:17:26 -0500 (EST)

> improvement of java and decide when to jump on the bandwagon.

IceT, a system for distributed computing that we've been
working on for some time here at Emory and not to be confused with the
more recent "Ice-T" package from Sun, has just released some priliminary
benchmarks.

In comparing IceT to PVM3.3 for the distributed solution of a tridiagonal,
diagonally dominant linear system using the Gauss-Jacobi method the
single-processor version written in Java performed the computation in 15.7
seconds, the C version too 5.5 seconds.  The size of the system was
250,000 diagonal elements.  The Java version was compiled with the
JDK-1.02 jit.

15.7 vs. 5.5 seemed pretty good to us for an interpreted language.

Paul Gray
[email-masked] 		
Math/Computer Science Department
Emory University, Atlanta, GA 

150 North Decatur Building
1784 N. Decatur Rd.
Atlanta, GA  30322

---

From: Bill Day <[email-masked]>
Date: Wed, 19 Feb 1997 16:52:57 -0800

>         to generate more efficient code than is possible for C and

Java to native binary compilation works quite well
where it is available (and there's the rub).

For instance, if you compile Java code on an SGI IRIX machine 
using the -trans flag in javac, you get a binary with both
bytecode and machine-specific instructions.  Such
binaries run at 1 to 1.2 times the speed of comparable
C/C++.

-b-

-- 
Bill Day                              [email-masked]
Silicon Graphics      http://reality.sgi.com/bday/