HPCC and Java -- A Preliminary Report by The Parallel Compiler Runtime Consortium
(PCRC)
Find this at: http://www.npac.syr.edu/users/gcf/hpjava.html
Latest Draft is:http://www.npac.syr.edu/users/gcf/hpjava3.html
- Northeast Parallel Architectures Center at Syracuse University: Geoffrey Fox,Bryan Carpenter, Wojtek Furmanski, Don Leskiw, Xiaoming Li
- Cooperating Systems: Marina Chen, James Cowie
- Harvard University: Thomas Cheatham, Amr Fahmy
- Indiana University: Dennis Gannon, Rajeev Raje
- Rice University: Ken Kennedy, Chuck Koelbel, John Mellor-Crummey
- University of Maryland: Joel Saltz, Alan Sussman
- University of Rochester: Wei Li, Michael Scott
- University of Texas: Austin: Jim Browne
General Approach:
- ASAP -- people to put on reflector sent to me: reflector is pcrc-java@npac.syr.edu
- February 22 All Initial Material to reflector to be set up by Syracuse
- February 25 Draft 2 deep outline with full writing Assignments
- February 29 2 deep outline with assignments agreed
- Mid April -- all assignments complete -- editing etc. starts
- Draft must be ready for public but friendly reading by CRPC meeting in Mid May
- Based on the manifesto we will call a meeting to decide what areas PCRC
will focus on
Four areas are available in this document as listed below -- Click to find
details!
These are plans made at the Arpa PI meeting february 15 1996
- 1. What are Suitable Models for Parallel Computing and Java
- speculations from Browne
- comments fom Indiana
- 2. Motivating Applications for HPCCJava
- distributed simulation etc.
- Syracuse and Maryland initial words
- 3. Lessons from and Relations to HPF/HPC++
- Indiana
- See also Maryland section 7.4.3
- 4. Language Enhancements(Annotations) and Classes to support HPCC and Java
- Marina Chen, Jim Cowie initial words
- Indiana Comment.
-
- 5. Architecture (Shared, Distributed Shared, and Distributed) Issues for
HPCCJava
- Rochester will supply initial words
- Indiana Comment
- 6. Compilers and Java -- Both conventional and HPCC and on client(interpreter)
and Server(javac)
- Rice will give initial words
- Indiana comment
- 7. High Level Runtime Issues
-
- 7.1 Dynamic Communication and Distributed Nameservers
- Browne speculations
- 7.2 Parallel and Conventional CORBA Interface to Java
- Gannon Initial words
- 7.3 Task Parallelism and Java for both Integration(Coarse grain) and fine
grain examples
- Fortran-M CC++, "channel" classes in Java (see Indiana remark)
- Relation to MetaChaos and PCRC Interoperability
- Maryland will give initial words -- see sections 7.4.2umd and 7.4.3umd
-
- 7.4 HPCC and Compute-Webs (Use of World Wide Web MetaComputer)
- HPCC applications as "applets" -- Indiana comment
- Maryland Initial words
- Boston/CSC/Syracuse may add
- 7.5 HPCC Java and implications for security
- Brokers as interfaces to Java native HPCC related classes
- Gannon initial words: see the CORBA discussion in Section 7.2
- 8 Low Level Runtime Issues
-
- 8.1 The Current PCRC Runtime (Regular and Irregular) Implementation in Java
- Full (portable) Java version
- What is smallest set of PCRC routines that are needed
- to be done in native mode (i.e. current C)
- Syracuse will provide initial words
- 8.2 Distributed Memory Versions of Java Runtime and use of HPCC thread packages
on SMP or distributed memory to support Java
- Rochester and Gannon will get initial words here
- Gannon(27feb96): I just ran across some interesting stuff on the EspressoGrider project http://wwwipd.ira.uka.de/%7Eespresso/Project/ that looks at some interesting
extensions to java with a concern about performance, compilers and parallelism.
suggst. you all check it out. (one of the people involved Martin Ordersky
will be here friday to talk about this work. I will let you know what i
learn.
- Note: http://www.communities.com/ - Electric Communities HomePage
- and http://www.communities.com/index/e.html - The E Programming Language
- Summary Presented by Fox at Arpa Meeting:
- Features of the Java language and runtime
- Secure, architecture neutral, Object Oriented but simpler than C++
- runtime modules dynamically downloadable with applet mechanism and portable
opcodes (from PC, Mac, to Workstation)
- Can build on existing work on HPF HPC++ -- especially latter
- Two basic types of opportunities:
- Build a modest performance totally portable runtime in Java
- Use current PCRC runtime as native classes for a (data-parallel) Java
- What is minimum set of PCRC routines which MUST be native(C)?
- Applet mechanism naturally incorporates task parallelism -- need to add
"channel" class (as in Fortran-M, CC++) to augment "thread" and "socket"
classes
- Need to implement Java runtime in Nexus or similar distributed thread package
-- again native Java would be portable but lowish performance
- Java can be used both on Server and Client side as expect soon good Java
based clients and servers
- See the E language http://www.communities.com/e/index.html
- or my class notes in general or specifically Java foils http://www.npac.syr.edu/users/gcf/cps616java96 (where foils 115,116 discuss HPJava for class) or
- http://www.npac.syr.edu/users/gcf/cps616tech96
- 1. What are Suitable Models for Parallel Computing and Java
-
- 2. Motivating Applications for HPCCJava
-
- 3. Lessons from and Relations to HPF/HPC++
- See also Maryland section 7.4.3
- 4. Language Enhancements(Annotations) and Classes to support HPCC and Java
-
- 5. Architecture (Shared, Distributed Shared, and Distributed) Issues for
HPCCJava
-
- 6. Compilers and Java -- Both conventional and HPCC and on client(interpreter)
and Server(javac)
-
- 7. High Level Runtime Issues
-
- 7.1 Dynamic Communication and Distributed Nameservers
- 7.2 Parallel and Conventional CORBA Interface to Java
-
- 7.3 Task Parallelism and Java for both Integration(Coarse grain) and fine
grain examples
- Fortran-M CC++, "channel" classes in Java
- Relation to MetaChaos and PCRC Interoperability
- Maryland will give initial words -- see sections 7.4.2umd and 7.4.3umd
- 7.4 HPCC and Compute-Webs (Use of World Wide Web MetaComputer)
- This is currently a collection of exemplar systems/ideas:
- 7.5 HPCC Java and implications for security
- Brokers as interfaces to Java native HPCC related classes
- Gannon initial words: see the CORBA discussion in Section 7.2
- 8 Low Level Runtime Issues
- 8.1 The Current PCRC Runtime (Regular and Irregular) Implementation in Java
- 8.2 Distributed Memory Versions of Java Runtime and use of HPCC thread packages
on SMP or distributed memory to support Java
-
Texas Contribution (28 feb 96):
Syracuse Contribution (23 feb 96):
2.0 Motivating Applications for HPJava: Meta-Challenges
2.1Syr) Introduction: First some preliminary remarks. We classify all (interesting) HPCC applications
as belonging primarily to one of two domains: Grand Challenges or National
Challenges -- the "HPCC-Challenges". Recognize that today's technology is
blurring the distinctions between parallel and distributed processing, e.g.,
the use of ATM-LANs by networks of workstations/PCs. The "traditional" high-performance
applications require finely tuned and optimized implementations of runtime
support (intrinsics and communications) on their host processors. The current
designer of runtime systems seeks to provide the application programmer
with easier access the high performance potential of a given machine(s)/
architecture. Beyond speed, however, National Challenges can pose additional
requirements such as trust or privacy, i.e., security, and here a runtime
system designer must also consider metrics like "response time" or "transactions
per second".
2.2Syr) Meta-Challenges: We define a new class of applications called "Meta-Challenges". These are
loosely coupled sets of physically distributed instances of Grand or National
Challenges. A DoD example of a Meta-Challenge is Distributed Interactive
Simulation (DIS). DIS involves the modeling of forces (tanks, aircraft,
satellites), environments, rules of engagement and tactics, etc. Simulation
control and monitoring for red, blue, and white players are provided. A
simulation may need to grow with the addition of "green", "yellow", or neutral
forces, and have to scale form peace-time/peace-keeping through low-intensity-conflict
(LIC), to massive conflict. Requirements for considering chemical, biological,
or nuclear (CBN) environments are needed, for example, modeling operations
in a nuclear environment (OPINE).
2.3Syr) An Example Meta-Challenge: DIS: Java offers a means to enhance the existing DIS multi-user protocol. A
new DIS protocol, Advanced Distributed Simulation (ADS), is an attempt to
introduce scalability. ADS breaks apart the DIS into an active-reactive
part and an interactive-communicating part. Java is consistent with such
an evolutionary approach. Java applets could update models on-the-fly, as
with dynamic weather, battle damage, or threat-responsive counter-countermeasure
techniques. One of the greatest challenges to the DIS designer is finding
ways to interconnect independently built simulations having disparate modeling
granularity (i.e., the ALS protocol, Aggregate Level Simulation), and then
increase the number of models and improve fidelity, but with no-greater
demand on network bandwidth. Weapon system design has also been evolving
from integrating interoperable subsystems to influence management among
ubiquitous supersystems. (An example of the latter would be Information
Warfare (IW). Another is counter-OSINT --open source intelligence). BM/C3
is undergoing changes in definition: BM/C4 (computing), C3I with intelligence,
and IS&R for surveillance and reconnaissance. Also, a fifth-C, C5I is sometimes
added for emphasizing the collaboration among humans of any C3I system.
(The relationship between an Air Traffic Controller, the ATC surveillance,
tracking, processing and display system, and a pilot is another example).
From a user's (Commander's) perspective, Java is extremely attractive for
simulating (or even building) these systems since its roots are in the distributed,
interactive, object-oriented, collaborative user domain. It is rapidly becoming
the language of choice for programming the user-interface of on-line commercial
multimedia systems.
2.4Syr) Java for DIS: Java is intended to be machine independent and offers to challenge the need
for hegemony among systems. For example, the ideal computing architecture
for simulating military battle management including command and control
is multiple instances of "loosely coupled sets of tightly coupled processors."
Such always poses a severe configuration management problem: multiple hardware,
operating system, and programming languages. Interoperability among systems
of systems and the interfacing between "stovepipe" systems is related challenge.
Java could provide an approach for "wrapping" existing or planned systems
with a functionality layer for interoperability while ameliorating the bandwidth
problem by intelligently transmitting only those parts of a message (applet)
that are immediately needed by an application (user).
Maryland Contribution(22 feb 96):
2.5umd) Remote sensing data fusion: There are many applications that are likely to require the generation of
data products derived from multiple sensor databases. Such databases could
include both static databases (such as databases that archive LANDSAT/AVHRR
images) and databases that are periodically updated (like weather map servers).
A client would direct (High Performance) Java programs to run on the database
servers. These HPJ programs would make use of the servers computational
and data resources to carry out partial processing of data products. Portions
of data processing that required the integration of data from several databases
would be carried out on the client or via a HPJ program running on another
computationally capable machine.
2.6umd) Interventional Epidemiology/ Medical crisis management: We are considering scenarios involving medical emergencies associated with
armed combat, terrorist actions, inadvertent releases of toxic chemicals,
or major industrial plant explosions. In such scenarios, the goal is to
rapidly acquire and analyze medical data as the crisis unfolds in order
to determine how best to allocate scarce medical resources. This scenario
involves the discovery and integration of multiple sources of data that
might be in different geographical locations. We would For instance, one
may need to determine the best diagnosis and treatment for patients exposed
to combinations of chemicals whose effects have not been well characterized.
This class of scenarios is motivated by the recent ARPA-sponsored National
Research Council workshop on crisis management.
This involves discovering and Exploiting Clinical Patterns in Patient Populations.
These scenarios involve study of health records to determine risk factors
associated with morbidity and mortality for specific subpopulations (e.g.
various substrata of armed forces personnel serving in a particular region).
In such scenarios, the goal is to provide high quality, lower cost care
by exploring diverse clinical data sources for patterns and correlations
and by ensuring that significant data for individual patients is not overlooked.
For instance, a system of this type could rapidly track the spread of serious
infectious diseases such as Hepatitis B or HIV. It could also be used to
identify specific soldiers whose demographic profile or past medical history
might place them at particularly high risk of contracting the disease.
The systems software required for these medical scenarios should be very
similar to the requirements motivated by the sensor data fusion scenario.
See also Maryland section 7.4.3
Indiana Contributions 24 feb
- 3.1ind) Comparison with HPF: On the HPF side it is possible to create a class of distributed objects
that are similar to the HPF distributed array. Because it can be defined
as a class, there would be no need to create a special extension of the
array data type or an annotation to support distribution. this is what is
done in HPC++. In our opinion, the HPF model of data parallelism may not
be the most interesting thing to do with Java. If you want HPF features,
then use HPF.
- 3.2ind) Comparison with HPC++: Because Java is derived from a simple model of C++, some of the HPC++ ideas
could move to java. For example, annotations for parallel loops. Other ideas,
like the HPC++ parallel STL could only move to Java if
- 1) There was a template mechanism added to Java. this may not be a bad idea.
- 2) Because java has no pointers another mechanism must be found to replace
the STL concept of a parallel iterator. This might be a smart array index
object in Java.
- 3.3ind) Operator Overloading: Also java does not provide an overloaded operator mechanism, so building
a parallel array class is not as easy as in HPC++ (or even Fortran 90.)
Cooperating Systems Contribution (29 feb 96)
Language extensions to Java can be broadly put into two categories, each
with its own pros and cons.
- 4.1csc) Extensions via class libraries. Use Java's OO features to add new functionality in the form of redistributable
Java classes.
- Pros: Most significantly, no need to distribute a new Java compiler or preprocessor,
and no need to modify the "standard" process for compiling and linking Java
code. Because Java is class-extensible by design, library-based approaches
shorten the development time for Java extensions.
- Cons: Java lacks operator overloading (but history may ultimately view this as
a gain for readability) and templates. As a result, library-based approaches
may result in inherently cluttered code (no sugared syntax for the obvious
data-parallel constructs). Lack of templates may make it hard to define
collective classes with polymorphic base types, but the fact that all Java
objects derive from Object may still make possible polymorphic approaches
with reasonable overhead. Library-based extensions may defer some program
analysis to runtime which could have been performed once at compile time.
- 4.2csc) Extensions to the Java language. Three categories:
- (a) syntactic sugar for obvious dataparallel constructs,
- (b) annotations to flag concurrency and suggest distribution strategies,
and
- (c) deep language additions to extend Java's support for explicitly managed
concurrency.
- These three alternatives generally mirror the history of proposed C++ language
extensions.
- Pros: Language extensions give designers more freedom to set "optimal syntax"
for new parallel constructs, and enable some optimizations for the implementation
of those constructs.
- Cons: Obviously, the need to distribute a HPJava compiler, and the obligation
to make that compiler (and hopefully its associated debugger) track the
rapid evolution of the Java language and the Java virtual machine. It may
not be too difficult to come up with a prototype. But on the Web, people
expect more than research prototypes. Users will demand assurances (whether
reasonable or not) that the additional HPJava compilation process will be
at the same level of production-quality as the underlying Java compiler,
and that the new HPJava features will not degrade Java's security or restrict
the portability of their code.
- 4.3csc) Implications of Immature Language: Because the Java language will continue to evolve, any preprocessor or
compiler approach will have to track Java's evolution. There's a danger
that a real and robust compiler cannot be delivered quickly, and that by
the time HPJava extensions are defined, implemented in a preprocessor, and
distributed, those tools will be at least one generation out of sync with
the latest Java standards. Debugger support for Java is already fairly poor,
even compared with existing HPC languages, so adding nonstandard extensions
can only make the situation worse by confounding Java source/object code
correspondence.
- 4.4csc) Comparison with C++: In C++, two flavors of extensions appeared: small tweaks for sugaring the
syntax of parallel constructs, and deep changes for modifying the semantics
of the language to support concurrency. In HPJava, a limited preprocessor
which implements some shallow (sugaring) syntax changes may be a reasonable
project at a later stage, after the library approach has matured enough
to identify the most egregious kinds of syntactic clutter.
Indiana Contribution (24 feb 96)
- 4.2ind)Implications of Java Philosophy: One of the principles in the design of Java has been simplicity, Rajeev
feels that language annotations may go against the original philosophy.
Gannon is not sure.
- 4.5ind)High Performance Classes: As there are lots of standard classes (java.net, java.awt, java.util, etc.),
it is very intuitive to create high performance classes which can be precompiled
and imported in the user programs. Also, users can extend these standard
high performance classes to suit their needs.
- Various data distribution schemes (supported by HPF) can be implemented
as part of these high performance classes.
Rochester Contribution(28 Feb 96):
- 5.1roc) Generate native code for shared-memory architectures: Parallelization of Java programs on shared-memory parallel architectures.
- The first step is to generate parallel code for shared-memory multiprocessor
workstations.
- The second step is to compile for Shared Virtual Memory systems like Cashmere
being developed at Rochester.
- 5.2roc) Java vs Bytecode: There are three possible paths:
- (a) Bytecode->Native code,
- (b) Java->Bytecode, and
- (c) Java -> native code. Need to understand the tradeoffs for optimizations
for shared-memory architectures.
- 5.3roc) Locality optimizations for (distributed) share-memory architectures: Interesting optimizations are:
- (a) data mapping and transformations,
- (b) cache optimizations, and
- (c) register allocations. Java provides new opportunities and challenges
that are different from other languages like Fortran.
- 5.4roc) How to integrate shared-memory environments across a heterogeneous
collection of machines and interconnects, respecting the dramatically different
latencies and bandwidths: How to compile for hierarchical shared-memory systems composed of cache-coherent
MPs at the top, remote-memory networks in the middle, and message-passing
networks at the bottom.
- 5.5roc) Compiling Java for heterogeneous networks of machines: There is heterogeneity in various aspects of parallel programming: program,
processor, memory and network. A heterogeneous program has parallel loops
with different amount of work in each iteration; heterogeneous processors
have different speeds; heterogeneous memory refers to the different amount
of user-available memory on the machines; and a heterogeneous network has
different cost of communication between processors. We need both compiler
and runtime support.
Indiana Contribution (24 feb 96):
- 5.6ind)General Issues: Interoperability/transparency is a strong point behind design of Java (creation
of bytecode, etc), HP Java should well suit any target architecture.
- Different precompiled classes could be a way to tackle this.
Rice Contribution(27 feb 96):
-
Texas Contribution (29 feb 96):
- 7.1.1tex) Communication Requirements of Java Applications
- The requirements for communication mechanisms in Java should the driven
by the applications of Java. The general nature of the applications of Java
are discusses in the position paper "A Model of Parallel Computation for
Java." The point emphasized herein is that many HPC- based Java applications
will involve large dynamic sets of interacting agents.
- Therefore, any extension of Java for support of HPC-integrated applications
should endeavor to make communication among large dynamic sets easy and
convenient.
- 7.1.2tex) The Current Model of Communication
- The model of communication for Java is implicitly defined. It is based on
assigning a unique name to every communicating agent and/or every object
used in communication.
- The benefits of using this model of communication are that is familiar and
that there is a large technology for support of implementation of this model
of communication.
- 7.1.3tex) Desirable Properties of Model of Communication for Java
- a) It must be simple and uniform.
- b) It should give convenient support for communication among dynamically
constituted sets of agents.
- c) It should support continuous dynamic mapping of Java implemented agents
and objects to dynamic resource configurations.
- d) It must be consistent with the philosophy and current features of Java
and implementable in a consistent syntax and semantics
- 7.1.4tex) Proposed Model of Communication
- The proposed model of communication is state-based communication. The elements
are as follows.
- a) Each class will have another declaration called a "profile" declaration.
The profile declaration will define the set of communications which an instance
of the class is prepared to accept at a given time.
- Profiles are dynamic and reflect the state of each object at a given time.
The profile declaration includes a method for initializating and modifying
profiles.
- b) Each set oriented communication will have two parts; a selector and some
data. A selector is a template for a predicate over state variables which
will occur in profiles.
- c) A communication is initiated by an object creating a communications object
which includes a selector and the associated data. Creation of the communication
object invokes an associative broadcast of the communication object. An
associative broadcast determines all of the object profiles which match
the selector and delivers the data to them.
- A detailed definition of associative broadcast can be found in Bayerdorffer
[BAY94]
- 7.1.5tex) Integration/ Implementation Concepts
- This model of communication can readily be integrated into the concept framework
for system services provided by Java. One possible integration follows.
- a) This model of communication can be implemented in Java using the "implements"
attribute in the same mode as is done for threads wit the class "Runnable."
- b) The interpretive model of execution allows for ready mapping of communication
objects to mechanisms appropriate to local or remote communication.
- 7.1.6tex) Comments
- a) This model of communication is familiar. It is run-time implementation
of a name server. Linda [GER86] uses a model of communication in the same
class of capabilities but with a different set of implementation concepts.
- b) Distributed resource management algorithms such as fault recovery, reconfiguration,
addition and deletion of system resources are much simpler in a state-based
model of communication than in a unique name- based model of communication.
Indiana Contribution (24 feb 96):
- 7.2.1ind)CORBA Model: CORBA uses the following model. a client program (read applet here) requests
a "pointer" to a remote object by making the request to an "object request
broker" (ORB). The ORB locates the object and returns a "pointer" (in java
this implemented as a reference to a local "proxy" (object) for the remote
object. any request made to the proxy is caried out by the remote object.)
- All objects in CORBA have interfaces that are defined in terms of IDL (interface
definition language). these interfaces are very similar to the "Interface"s
in Java.
- 7.2.2ind) Current Activities: Rajeev and Gannon have been investigating this for about a month now.
- There are already to very interesting efforts to build a link between Java
and CORBA, the industry standard for distributed object management. One
is JIDL from Sandia and the other is HORB from ETL in Japan. You should
all look at both of these.
- JIDL => see this => http://herzberg.ca.sandia.gov/jidl/
- HORB => see this => http://ring.etl.go.jp/openlab/horb/.
- the difference between JIDL and HORB can be characterized by the the way
the IDL mechanism works.In HORB java object talk to other java objects by
using the java interface as the IDL. In JIDL, java applets talk directly
to a real CORBA ORB.
- 7.2.3ind) HPJava Issues: For HPJava we see several important issues:
- a) Alink with standard CORBA objects is essential.
- That is, A CORBA object on the network would be accessed by andmanipulated
by a local java proxy object in the applet.
- If this is the case, we need to translate from Corba IDL to java. there
are some technical issue to solve:
- how could the java bytecode interact with formats used in CORBA implementations?
- Indeed are all the IDL types expressible in java? for example arrays and
streams?
- b) how can we design an ORB interface that satisfied the java security model? (more on that later.)
see sections 7.4.2umd and 7.4.3umd
Indiana Contribution (24 feb 96):
7.3.1)Limited Synchronization Capabilities of current Java: Following the exact semantics of Fortran-M channels might be a challenge
in java because of the limited synchronization features of java.
There are several important possibilities here -- exemplars follow:
Maryland Contribution(22 feb 96):
7.4.1umd)Mobile Programs: The intent is to provide a single unified framework for remote access and
remote execution in the form of itinerant programs. Itinerant programs can
execute on and move between the user's machine, the servers providing the
datasets to be processed or third-party compute servers available on the
network. The motion is not just client-server; it can also be between servers.
Programs move either because the current platform does not have adequate
resources or because the cost of computation on the current platform or
at the current location in the network is too high. Various parts of a single
program can be executed at different locations, depending upon cost and
availability of resources as well as user direction. The architecture would
also provide support for plaza servers. Plaza servers provide facilities
for (1) execution of itinerant programs, (2) storage of intermediate data,
(3) monitoring cost, usage and availability of local and remote resources
on behalf of itinerant programs and alerting them if these quantities cross
user-specified bounds, (4) routing messages to and from itinerant programs,
and (5) value-added access to other servers available on the network. Examples
of value-added functionality include conversions to and from standard formats
and operations on data in its native format. In addition to allowing cost
and performance optimization, itinerant programs and plaza servers also
provide a flexible framework for extending the interface of servers, in
particular legacy servers with large volumes of data as well as servers
that are not under the control of the user.
7.4.2umd) Coupling sequential Java Programs: MPI should be bound to Java so that Java programs can communicate by message
passing. We believe that applications will require an ability to process
periodically generated data. Programming to carry this out could be written
in MPI, however, a higher level library might prove to be useful.
Consider long-running itinerant programs that process periodically generated
data; each program processes sequences of data from multiple sources with
possibly different periodicity. An itinerant program can either visit each
of the data sources in order or it can install a surrogate at each data
source, which is activated every time the dataset is updated. A surrogate
acts as a filter for the sequence of data generated by the data source and
communicates appropriate updates to the parent itinerant program (possibly
after preliminary processing). For complex processing on a number of datasets,
a hierarchy of surrogates and result combining programs can be created.
The result of such itinerant programs can either be a single accumulated
result or a sequence of results. What we have in mind is a scheme that is
an extension of our existing scheme for mapping and synchronizing multiple
update sequences, which has been used in our program coupling effort. This
scheme has been used to dynamically link multiple physical simulations being
performed concurrently.
7.4.3umd) Coupling HPJ programs with one another and with other data parallel
programs (e.g. MPI, HPF, HPC++): We consider the problem of efficiently coupling multiple data-parallel programs
at runtime. We propose an approach that establishes mappings between data
structures in different data-parallel programs and implements a user-specified
consistency model. Mappings are established at runtime and can be added
and deleted while the programs being coupled are in execution. Mappings,
or the identity of the processors involved, do not have to be known at compile-time
or even link-time. Programs can be made to interact with different granularities
of interaction without requiring any re-coding. A-priori knowledge of consistency
requirements allows buffering of data as well as concurrent execution of
the coupled applications. Efficient data movement is achieved by pre-computing
an optimized schedule. (This actually is already PCRC work and will appear
in a paper at the ICS conference in May).
Syracuse Contribution(11 feb 96):
7.4.4syr) WebWork: Integrated Programming Environment Tools for National and Grand
Challenges is our joint work with Boston University and Cooperating systems with paper
written before implications of Java as clear as they are now!
7.4.5syr) Computational Web Multiserver - a proposal for Web based HPCC
updates some of the ideas in WebWork
- Web technology development so far focused on the client side (Netscape2,
plugins, Java applets, JavaScript)
- Web servers, so far minimal (e.g. NCSA httpd), are expected to expand now
with the growing demand on backend processing (database, collaboratory,
imaging, compression, rendering, simulation, televirtuality).
- Java offers a promising development platform for computationally extended
Web servers. Current activities include:
- Java is also an attractive platform for PCRC module packaging and unification
of HP languages. Advantages of Java based HPruntime include:
- * secure, architecture neutral, OO but simpler than C++ framework
- * runtime modules dynamically downloadable (via portable opcodes)
- * native class support for performance critical (data parallel) ops
- * built-in OO support for networking and multithreading
- * Java compiler written in Java => portable HP extensibility
- Computational Web server = Java based Web server with native HPCC kernel
support (e.g. for matrix operations), extensible by PCRC modules
- * HPCC builds on pervasive Web technologies
- * Web browser based interactive insight into HPCC runtime
- Higher, fully interpreted layer with intuitive scripting syntax required
for rapid prototyping and high level runtime communication. JavaScript/LiveWire
(now formalized/standardized by W3C) is one possible candidate.
- However, more attractive approach is to develop high level VM on top of
low level Java VM to support variety of interpreted protocols. (One existing
example: postfix syntax based low Telescript layer). We call it WebScript
and view JavaScript, LiveWire, VRML as specific instances/little languages.
- Computational Web Multiserver Architecture:
- * runtime given by a mesh of computational web servers
- * several communication layers possible (HTTP, Java opcode passing, Java
class passing, E-object message passing, WebScript passing)
- * applications written in conventional languages (HPF/C++) or HPJava, HPJavaScript
(HPWebScript)
- * base runtime support server-resident, application-specific runtime libraries
downloaded dynamically and shared
- Summary of software layers:
- a) Java VM
- b) base Java classes (as in JDK 1.0)
- c) native HPCC classes (compiler directive handlers, matrix algebra)
- d) PCRC classes (Java or Java wrappers)
- e) WebScript VM (in Java)
- f) HP-WebScript instances (e.g. HP-JavaScript)
- g) applications
- At NPAC, we developed early protoypes of some of these concepts (with ARPA
support) and demonstrated at SC'93. MOVIE system was an early example of
computational "web" multiserver ("web" didn't exist before '93..). MOVIE
+ F90D based HPFI was an early example of high performance interpreted computational
multiserver. More specifically, the layers a) - g) above were implemented
as follows:
- a) MOVIE/TCE kernel (C with object-based organization)
- b) built-in (C coded) objects (string, dictionary, hashtable etc.)
- c) matrix algebra objects (fields = polymorphic n-dim arrays)
- d) F90D runtime, wrapped and linked to MOVIE via UNIX shared mem
- e) MovieScript VM (part of MOVIE kernel)
- f) HPMS (High Performance MovieScript = MovieScript + interpreted F90)
- g) HPF test applications, converted by modified F90D frontend to HPMS
Indiana Comment (24 feb 96):
- 7.4.6ind) Applet view of HPCC Applications: A HPCC application on a large MPP server or distributed over multiple servers
could contain access/control and modify methods.
- To access the application is to download a part of the application as an
applet.
see the CORBA discussion in Section 7.2
Syracuse Contribution(23 Feb 96):
8.1.1syr) Introduction: We consider using Java to also provide low-level runtime support for the
Meta-Challenges and distributed Interactive Simulations (DIS) discussed
above as well as the traditional Grand and National Challenges: coding the
high-performance runtime system in Java (i.e., traditional PCRC-like, including
Parti/Chaos). There are two basic sets of issues that a runtime system designer
must consider for traditional HPC challenges:
- ** the interface with the application language, e.g., Fortran with message
passing (HPF) or C/C++ with message passing (HPC/C++) Q note: the application
could be coded in Java (or VRML)
- ** the interface with the underlying process control and communications
library, e.g., PVM or MPI.
8.1.2syr) Features for PCRC Runtime in Java: The Syracuse University Fortran 90D runtime consists of about 300 routines/functions.
We expect that number to reduce to less than 150 in the newer PCRC implementation
by for handling regular computations and communications. We add to this
the estimate about 60 functions from the Maryland CHAOS runtime for handling
the irregular case. At present our Fortran 90D runtime (including its use
of Parti/Chaos) requires only 23 different MPI functions. The same will
hold for the newer PCRC version. We claim the following:
- ** All address translation routines can be implemented in Java (since they
usually do not involve communication)
- ** All data movement routines can be implemented in Java, provided we establish
a smooth interface between Java and underlying communication system (e.g.,
MPI)
- ** At present, certain computational functions may have higher performance
in other languages: e.g., MATMUL, initially may be left in Fortran, since
Fortran still has better number-crunching performance, and more easily handles
situations like COMPLEX data types.
8.1.3syr) Issues for PCRC Runtime in Java: As we re-implement the PCRC runtime system for regular and irregular distributed
arrays, we must address the following design issues:
- ** Java currently provides facilities for concurrent processing via threads
and monitors. Should we directly extend JavaUs (native) functionally to
include more parallel-processing support ?
- ** The interface between Java and low level communication systems must be
better understood and benchmarked. For instance, Java now can call a C function
when that function has been specially written to be called by Java. We need
to experiment and evaluate how the Java runtime environment (java) can collaborate
with the MPI runtime environment (mpirun).
- ** The PCRC runtime has deeper roots with "true" compiled languages vice
the interpreted ones. We prototyped the Fortran 90D Interpreter (demonstrated
at SC 94) after developing the Fortran 90D compiler and runtime. Thus we
believe experimentation with prototype interfaces between a PCRC runtime
system (for regular and irregular distributed arrays) coded in Java and
the Java native runtime for interpreted environments are needed.
Rochester Contribution (28 feb 96):
Indiana Contribution24 feb 96):
- 8.2.3ind) Performance of Current Java Threads: This is a clear win for java. The question is if there is an "enhanced"
thread interface that is better than the current "runnable" in Java. We
will do some SMP experiments to measure the current java runtime on SMP
systems. We have both the IBM and SGI versions.
- 8.2.4ind) Java Distributed Memory Model: As mentioned above we can do HPF style partitioned arrays, but a more interesting
thing from the pcrc view might be the metachaos shared objects. we have
been looking at this from the corba side and realized that to do it right
requres a substantial extension of the corba semantics. Kate Kaehey at Indiana
has worked this out as part of the HPC++ CORBA extensions (she will present
this at POOMA next week.)
- From the Java perspective here is the model used in the HPC++ CORBA extensions.
(the maryland gang can comment on "true" metachaos. this is only how we
have come to view the subject.)
- 8.2.5ind) Implications of Current Indiana Research on HPC++ and CORBA: Kaehey's Collective Shared Objects are objects that live on the net. they
can be distributed or localized on a particular server. These object can
have data members which may also be distributed or localized and they have
two types of member functions: regular and collective. regular ones are
norman member functions like standard java. collective member functions
implment collective opeartions such as reductions, scans, broadcasts between
participating clients.
- A client applet must "register" with such an object before it would be able
to talk to do collective member operations. It turns out that this is an
interesting way to model distributed data bases, metachaos style shared
arrays. it was the essential component of our I-way project for sc 95.