HPCC and Java -- A Preliminary Report by The Parallel Compiler Runtime Consortium
(PCRC)
- 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.