Re: Java Benchmarks - AS/400 Kicks - A#$

[Blair Wyman <wyman@xxxxxxxxxxxx>]

Excerpts from midrange-l: 6-Jun'00 Re: Java Benchmarks - AS/40.. "Leif
Svalgaard"@leif.or (1242*) 

> It is entirely plausible that the AS/400 edge (which is real - I'm not 
> denying that !) is due to better I/O performance rather than better 
> Java performance. Again, my point is that since the two are 
> entwined one must be careful to say what is due to what. 

I/O can certainly be a bottleneck, and the robustness of the AS/400 I/O
processor infrastructure could certainly be a factor in our numbers, but
I'd suggest that the true "edge" the AS/400 appears to be exhibiting in
Java is somehow "deeper." 

Without going into detail (and operating at the risk of letting my
excitement skew my perspective  ;-) writing Java for the AS/400 isn't so
much like writing an "application" as it is "adding to the system." 
Java's lack of a traditional 'pointer' type allows the AS/400 JVM to
craft Java-to-Java calls that do not even stack a user auto frame! 
...parameters are passed, and return values returned, in registers! 
"Featherweight" locking allows low-contention synchronization to be
nearly free!  I overheard a respected colleague comment that, "Java is
the only application language that can run at the speed of SLIC." 
...and I believe it!   

<whew> 

Excerpts from midrange-l: 6-Jun'00 Re: Java Benchmarks - AS/40.. "Leif
Svalgaard"@leif.or (671*) 

> in addition, using operating system threads to support concurrent connections 
> is not a good idea in the first place. See 
> http://imatix.com/html/smt/index.htm 
> for a discussion of why not. 

I didn't read the entire article, but if you're basing your assertion on
the contents of the "Why Use Multithreading?" section, then IMO it's an
"apples and oranges" comparison.  

The problem with large-scale concurrency cited in the paper presumes
that the concurrency is implemented using a fork() system call, and I
have no beef with their conclusions -- fork() is a heavyweight tool. 
Implementing Java threads with fork() would be like knitting with
telephone poles.  Technically, though, fork() doesn't even involve
"threads," per se -- it's a process-level system call that makes a
nearly-complete copy of the current process, with all the fundamental
folderol that entails. 

Now, the AS/400 doesn't even have a fork() system call (we couldn't make
the mistake cited in this article if we wanted to ;-), so instead Java
threads on the AS/400 system are simply special instances of so-called
"native" threads (based on the POSIX "pthread" model).  AS/400 native
threads (as the Volano and SPECjbb numbers clearly imply) are very
"lightweight" processing entities which scale very well with the number
of processors on the machine, and they satisfy the goals of maximizing
interdependent concurrency quite nicely. 

Anyway, just my two cents' worth...  I can tell you that the AS/400 is
going to be making some waves with Volano numbers like that -- first box
in 6 figures -- so keep your ears to the ground. 

-blair 

  ___   _           Blair Wyman                  IBM Rochester 
 ( /_)  /  _  ' _   (507)253-2891            blairw@us.ibm.com 
__/__)_/_<_/_/_/_'  Opinions expressed may not be those of IBM 

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---