Given by Geoffrey C. Fox at Sun MicroSystems Java Day at MIT (Marriot Hotel Cambridge MA) on Sept 25 1998. Foils prepared October 2 1998
Outside Index
Summary of Material
We describe Java Grande in context of its Forum -- motivation and current status
|
There are numerical and distributed computing issues
|
Outside Index
Summary of Material
Java Day MIT September 25 1998 |
Geoffrey Fox |
Northeast Parallel Architectures Center |
Syracuse University |
111 College Place |
Syracuse NY |
gcf@npac.syr.edu |
http://www.javagrande.org |
http://www.npac.syr.edu/users/gcf/jgmitsept98 |
We describe Java Grande in context of its Forum -- motivation and current status
|
There are numerical and distributed computing issues
|
Use of Java for: |
High Performance Network Computing |
Scientific and Engineering Computation |
(Distributed) Modeling and Simulation |
Parallel and Distributed Computing |
Data Intensive Computing |
Communication and Computing Intensive Commercial and Academic Applications |
HPCC Computational Grids ........ |
Very difficult to find a "conventional name" that doesn't get misunderstood by some community! |
We have had several conferences with 50---- attendees
|
Topics of conference papers:
|
"Spun off" Java Grande forum to promote needed community standards and activities. |
Must be proactive because Grande computer market is perhaps 1% of total computing market -- not Sun's highest priority |
The Java Language has several good design features
|
Java has a very good set of libraries covering everything from commerce, multimedia, images to math functions (under development at http://math.nist.gov/javanumerics) |
Java has best available electronic and paper training and support resources |
Java is rapidly getting best integrated program development environments |
Java naturally integrated with network and universal machine supports potentially powerful "write once-run anywhere (badly)" model |
There is a large and growing trained labor force |
Can we exploit this in Grande Computing / computational science? |
So existing Grande codes are written in Fortran C and C++ with a clearly unattractive and comparatively unproductive programming environment |
These current languages and tools are sufficient but does not seem likely that can build much better environments around them
|
Five years ago, it looked as though C++ could become language of choice (perhaps with Fortran as inner core) but this appears stalled
|
So there is no competition -- Java is currently our only hope
|
It has some natural advantages due its internet base with threads and distributed computing built in |
It is a young language and we can take steps now to avoid unproductive proliferation of libraries and parallel constructs
|
It could have expressivity and object oriented advantages of C++ combined with performance levels of C and Fortran |
It can use its clear GUI advantages as an entrée into other aspects of Grande programming |
Geographically |
Distributed |
Grandecomputer |
Resources |
Gateway System |
hosting Seamless Access |
Database, Collaboration |
Visualization |
and other Services |
Geographically Distributed users |
1 |
2 |
3 |
2) (Grande JavaBean) Java in Middle |
Server Tier |
Manage |
components of |
distributed system |
Provide Commodity Services |
3) Java as parallel or sequential computing programming language |
1) Java Applet for User Interface and client data analysis |
Java Grande |
Compute Server |
Java has potential to be a better environment for "Grande application development" than any previous languages such as Fortran and C++ |
The Forum Goal is to develop community consensus and recommendations for either changes to Java or establishment of standards (frameworks) for "Grande" libraries and services |
These Language changes or frameworks are designed to realize "best ever Grande programming environment" |
First Meeting Mar 1 Palo Alto at Java 98 -- 200 Attendees set Agenda -- 30 permanent people and further meetings May 9-10, Aug 6-7 |
Public Discussion SC98 Orlando November 13 (3 hour panel) |
http://www.npac.syr.edu/projects/javaforcse |
http://www.javagrande.org |
1) Most important in the near term -- encourage Sun to make a few key changes in Java to allow it to be a complete efficient Grande Programming Language
|
2) As a community, recognize that sometimes standards are more appropriate than creativity and pool results of experiments to produce a Java Grande framework covering libraries and computer access
|
1) requires us to work with the computing mainstream -- 2) is internal to community |
Two major working groups promoting standards and community actions |
Numerics: Java as a language for mathematics led by Ron Boisvert and Roldan Pozo from NIST
|
Java Grande 98 Feb 28 98 |
Snir and collaborators (IBM) study study 64 by 64 matrix multiplication
|
On IBM RS6000 model 590
|
m=n=p=64 |
Base Code: JIT 3.8 and IBM Compiler 2.1 mflops |
Remove runtime checks 33.3 mflops
|
C: Use rectangular array -- not array of pointers -- 44 mflops |
C: Use Hardware fused multiply-add -- 64 mflops |
C: Use standard compiler optimizations (associativity) 138 mflops |
Fortran: 205 megaflops |
ESSL: 253 megaflops |
Java is particularly slow on floating point -- why?
|
Current Java rules imply that if careful (avoid indeterminate threads and use of JNI) Java not only runs everywhere but gets identical results everywhere |
Need to study Reproducibility -- Performance Trade-offs
|
Language Chip Architecture |
Modifier x86 PowerPC SPARC |
strictfp Java 1.0 (no double Java 1.0 Java 1.0 |
rounding on underflow) (no fused mac) |
default i.e. larger exponent range fused mac can Java 1.0 |
no modifier allowed be used |
associativefp many optimizations allowed on all platforms |
Current default is essentially strictfp although not always implemented precisely |
mac is fused hardware multiply-add (a*b+c) |
strictfp is a little more than 2 times slower than default on INTEL x86 for a vector dot product |
s = s + a(i)*b(i) on x86 requires that one stores and restores both a(i)*b(i) and s to memory after arithmetic. There is clever way of using exception trap to speed up. |
Indigenous type would specify most precise floating point representation allowed by hardware |
anonymous double would imply all intermediate results implemented using double precision (original C standard) |
anonymous indigenous would instruct compiler to use extended double precision on x86 chips for all computations -- whatever type of variable |
Distributed and Parallel Computing led by Dennis Gannon and Denis Caromel (INRIA, France)
|
Development of Grande Application benchmarks |
Philippsen (Karlsruhe) experiments on performance effects of sending type info; JNI calls in float serialization; better buffer use |
JacORB |
JWORB |
ORBIX |
RMI |
Variable Size Integer Arrays |
Java ORBs Transferring |
variable size Array of Structures |
(RMI slowed by serialization) |
RMI |
JacORB |
ORBIX, JWORB |
Arrays of Integers C++ about 20 times faster than Java |
RMI (Fastest Java) omniORB (C++) |
Geographically |
Distributed |
Grandecomputer |
Resources |
Gateway System |
hosting Seamless Access |
Database, Collaboration |
Visualization |
and other Services |
Geographically Distributed users |
Java Applet Clients |
Parallel or Sequential Java Grande Codes |
Java Servers |
Java wins today? |
Major Commercial Activity |
Java Grande needs to look at scaling etc. |
Only Java Grande will promote? |
Database |
Matrix Solver |
Optimization Service |
MPP |
MPP |
Parallel DB Proxy |
NEOS Control Optimization |
Origin 2000 Proxy |
NetSolve Linear Alg. Server |
IBM SP2 Proxy |
Gateway Control |
Agent-based Choice of Compute Engine |
Multidisciplinary Control (WebFlow) |
Data Analysis Server |
Client Tier |
Distributed Java Middle Tier |
Future Globus |
Globus |
Future Parallel I/O |
Java Client |
Good Old Fortran/C++ Back end |
Java Servers(JWORB) |
JWORB - Java Web Object Request Broker - multi-protocol middleware network server (HTTP + IIOP + DCE RPC + RMI transport) |
Current prototype integrates HTTP and IIOP i.e. acts as Web Server and CORBA Broker
|
Next step: add DCE RPC support to include Microsoft COM |
JWORB - NPAC's trial implementation of Pragmatic Object Web |
Note Java is Language for writing Server -- even when protocols are NOT Java |
The Web integration of Java gives it excellent "network" classes and support for message passing. |
Thus "Java plus message passing" form of parallel computing is actually somewhat easier than in Fortran or C. |
Coarse grain parallelism very natural in Java and we have illustrated this with WebFlow |
"Data Parallel" languages features are NOT in Java and have to be added extending ideas from HPF and HPC++ etc
|
Java has built in "threads" and a given Java Program can run multiple threads at a time
|
Both working groups have made substantial progress
|
We are initiating Community actions
|
Join us at SC98 November 13 |
Note European involvement has been excellent so far
|
Don't need to rewrite existing codes in Java! |
Rather use Java freely at client and "gateway" tier |
Wrap existing codes as CORBA or Java distributed objects |
Conduct suitable experiments in using Java in complete Grande applications |
Make certain your interests are represented in Java Grande Forum |
Retrain your staff in Java Web and distributed object technologies |
Put "High Performance Grande Forum compliant" Java support into your RFP's for hardware and software |
Java Calls (mainly Interfaces and not methods) to capabilities expressed in implementation neutral form |
Drivers convert these general calls to vendor specific implementation of service |
Java code can either be all on client (2-tier) or on client and middle tier (3 tier) |
e.g. JDBC (Java Database Connectivity) is a universal interface to all relational databases |
Adoption of this JDBC implies that vendor specific solutions are immediately less attractive
|
Enables development of Web Interfaces to run a given job on any computer with any data source compliant with this framework just as JDBC gives a universal interface to any relational database
|
The Computing Services Framework will allow vendors to compete on either User Front End (GUI) or back end services with the JavaCS framework providing universal linkage |
The framework is implemented at the backend as a set of drivers which map generic Java Interfaces to particular software (e.g. a compiler) on particular machines. |
Requires agreement by "suitable interested parties" on
|
Grande Resource Discovery, Allocation and Scheduling
|
We are defining methods and properties of computers and programs viewed as distributed objects
|
Compiling, Executing, Specification of features needed for execution optimization
|
Accounting -- integrate with Web commerce technology? |
Authentication, Security (especially hard in metacomputing as link several different management policies)
|
The two forms of Large Scale Computing Scale Computer for Scale Users in Proportion Power User to number of computers |
Parallel Commodity Distributed Computers Information Systems Technology <--------------- Internetics Technologies ---------------> |
Parallel Computer Distributed Computer |
HPF MPI Java HTML XML |
1% market |
99% of market driving |
student interest and (Java) technologies |