I. Foster, C. Kesselman, and S. Tuecke. Nexus: An interoperability toolkit for parallel and distributed computer systems. Technical report, ANL, MCS-TM-1R89, Argonne National Laboratory, 1994.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....The main aspect of future work is the implementation of both the workpool and coordinators for hybrid environments (heterogeneous networks workstations and PCs some of them being MPPs) We have not yet decided upon a base platform. We are considering CC [5] or the underlying NEXUS system [7].The needed migration of coordinators is described in [14] 5. Related Work Coordinators share the basic idea of implicit coordination with futures but extends it to imperative scenarios Moreover, they do not rely on the strictness property which has been initially used to define futures 5 . ....

I. Foster, C. Kesselman, and S. Tuecke. Nexus: An interoperability toolkit for parallel and distributed computer systems. Technical report, ANL, MCS-TM-1R89, Argonne National Laboratory, 1994.

....models support logical rather than physical processes. To our knowledge, none support independence of the data model. Compositional C (CC , see [3] which supports both models does not provide a process model which is completely independent of the data model. The same applies for Nexus [5] and for TPVM[4] which sticks to physical rather than logical processes. The most prominent abstract process model has been introduced by Linda[6] In Linda, processes are abstract entities which communicate by means of a global data space named tuple space (rather than by process to process ....

I. Foster, C. Kesselman, and S. Tuecke. Nexus: An interoperability toolkit for parallel and distributed computer systems. Technical report, ANL, MCS-TM-1R89, Argonne National Laboratory, 1994.

....is too simple. There is, for instance, the need for grouping of work pieces. Moreover, some tasks might want to communicate explicitly with each other. This cannot be expressed in LINDA in a straightforward way. More explicit process models, such as the process model of PVM[GBD 93] Nexus[FKT94] CC [CK94] or ISIS[Bir93] on the other hand, request a too detailed knowledge about process control for most application programmers. Moreover, only PVM and ISIS support grouping of processes (which is crucial for scientific computing) We believe that an adequate process model for application ....

....a somewhat different prototype implementation of a distributed workpool based on PVM[GBD 93] we have decided to start from scratch using a platform which already supports a process model for both shared and distributed platforms. Because TPVM[FS94] it not available we have decided use Nexus[FKT94] The language CC which is based on Nexus cannot be used because we do not want to allow the user to mix two different programming models (DIPP and CC ) The programming model of Nexus can completely be hidden since it is a library. Some of the implementation aspects have been solved already ....

I. Foster, C. Kesselman, and S. Tuecke. Nexus: An interoperability toolkit for parallel and distributed computer systems. Technical report, ANL, MCS-TM-1R89, Argonne National Laboratory, 1994.

....way at the Computer Center of the University of Stuttgart in Germany (Rechenzentrum Universitaet Stuttgart) This project attempts to interconnect pairs of MPPs via specialist processes that use standard TCP IP for communications. More on this project and the newly developed Nexus MPI project [21] will be discussed in section 5. 3.0 PVMPI MPI Connect project 3.1 The PVMPI System We developed a prototype system PVMPI2 [9] to study the issues of interconnecting MPI and PVM. Four separate issues were addressed: mapping identifiers and managing MPI and PVM IDs . transparent MPI ....

....use the vendor optimized MPI communications. In the case of the Cray T3E and Intel Paragon XP machines, these communication nodes will not have access to PVM and thus will be forced to utilize a different inter machine communication medium such as SNIPE [19] SNIPE uses either TCP IP or the NEXUS [21] communications library from Globus [20] SNIPE provides its name resolution service via the Resource Catalogue and Distribution Service (RCDS) 22] which replaces PVM s group server PVMGS. Figures 6a 6d show the different communication layouts and process placements involved for each of the ....

Ian Foster, Carl Kesselman, Robert Olson, and Steve Tuecke. Nexus: An interoperability toolkit for parallel and distributed computer systems. Technical Report ANL/MCS-TM-189, Argonne National Laboratory, 1994.

....of chanter threads used for data parallel computations. All communication operations follow MPI syntax and semantics. Chant is currently being used to support the Opus language and runtime system, which extends High Performance Fortran (HPF) to support task parallel constructs. 4.4. 2 Nexus Nexus [45], currently developed at the Argonne National Laboratory, is a runtime system integrating lightweight threads and communication. Nexus supports multiple threads of control, dynamic processor acquisition, dynamic address space creation, a global memory model via interprocessor references, and ....

Ian Foster, Carl Kesselman, Robert Olson, and Steve Tuecke. Nexus: An Interoperability Toolkit for Parallel and Distributed Computer Systems. Technical Report ANL/MCSTM -189, Argonne National Laboratory, 1994.

....[1] which allows efficient management of a great number of activities inside applications. PM 2 (Parallel Multithreaded Machine) 2] is a preemptive multithreaded run time system developped in the ESPACE project. The basic functionnality of PM 2 is the LRPC (Lightweight Remote Procedure Call) [3], which consists of forking a remote thread to execute a specified service. Other works have a similar approach: Athapascan [4] and Cilk [5] Another goal of the ESPACE project is to provide a wide range of dynamic load balancing policies. The principle is to dynamically distribute computations ....

I. Foster, C. Kesselman, R. Olson, and S. Tuecke. Nexus: An interoperability toolkit for parallel and distributed computer systems. Technical Report ANL/MCS-TM-189, Argonne National Laboratory, 1994.

....to suspend the execution of a running thread and resume the execution of a previously suspended thread; 2) a scheduler that manages the transfer of control among the threads; and (3) concurrency control mechanisms. Many thread packages and standards have been developed in the past few years [10, 6]. However, the gluing together of scheduling, concurrency control and other features with the mechanisms to suspend and resume threads is problematic for the requirements of interoperability. e.g. the particular scheduling strategy provided by the threads package may not be appropriate for the ....

I. Foster, C. Kesselman, R. Olson, and S. Tuecke. Nexus: An interoperability toolkit for parallel and distributed computer systems. Technical Report ANL/MCS-TM-189, Argonne National Laboratory, 1994.

....However, sockets are rather heavy weight, and sending a message incurs at least 800 microseconds of overhead on the Sparc cluster. 3. 6 Related Work The fiber abstraction in the Multipol runtime layer is similar to the thread abstraction in TAM [CSS 91] Cilk [BJK 95] and Nexus [FKOT91] and the chare abstraction in Charm [SK91, KK93] TAM is a threaded abstraction machine for data flow computation. TAM threads are nonblocking units of computation for latency hiding which are generated by a compiler (each thread corresponds to a basic block in the data flow graph of a ....

Ian Foster, Carl Kesselman, Robert Olson, and Steve Tuccke. Nexus: An interoperability toolkit for parallel and distributed computer systems. Technical Report ANL/MCS-TM-189, Argonne National Laboratory, 1991.

....an execution flow to another location. An asynchronous LRPC is a mean of initiating remote independent treatments efficiently, because it involves only one message sending (no implicit results return) In this respect, it s very similar to the RSR mechanism available with the NEXUS runtime system [8]. Of course, if needed, it would always be possible to return results later by doing another asynchronous LRPC, but it s not the right way to go since a third variant of LRPC is provided: the deferred waiting LRPC. This last mechanism allows to decompose a LRPC in two steps: The LRP Call ....

I. Foster, C. Kesselman, R. Olson, and S. Tuecke. "Nexus: An interoperability toolkit for parallel and distributed computer systems", Technical Report ANL/MCS-TM-189 , Argonne National Laboratory, USA, 1994.

....multiple remote operations in large physical messages to reduce communication overhead. In addition to threading support, the runtime system also provides a set of portable communication primitives for bulk synchronous communication and asynchronous communication. Like TAM [6] and Nexus [7], the runtime system can be used as a compilation target, but it is primarily designed for direct programming by library and application programmers. Our design and implementation targets distributed memory architectures, including the Thinking Machines CM5, Intel Paragon, IBM SP1, and future ....

....better communication efficiency, and then increases due to redundant work. size changes from 1K bytes to 16K bytes due to a proportional increase in redundant work. 6 RELATED WORK Past research has produced a variety of runtime systems such as TAM [6] the Chare kernel [15] Cilk [12] and Nexus [7]. TAM threads are similar in spirit to the Multipol atomic threads in that they are used to hide latency. However, since TAM is designed as a compilation target, the threads are statically allocated within the scope of an activation frame, and a fixed scheduling policy is used to maintain locality ....

Ian Foster, Carl Kesselman, Robert Olson, and Steve Tuccke. Nexus: An interoperability toolkit for parallel and distributed computer systems. Technical Report ANL/MCS-TM-189, Argonne National Laboratory, 1991.

....any information on the Nexus interface or other internal details. 1 Introduction Nexus is a runtime library designed primarily as a compiler target for langages supporting task parallel and mixed data and task parallel execution. The Nexus interface and Nexus design are described elsewhere [1, 2]; here, we provide the information needed to execute programs that use Nexus services. We term a compiler that targets the Nexus runtime system a Nexus compiler, and an executable built with such a compiler a Nexus executable. A Nexus executable can be passed command line arguments intended for ....

I. Foster, C. Kesselman, R. Olson, and S. Tuecke, Nexus: An interoperability toolkit for parallel and distributed computer systems, Technical Report ANL/MCS-TM-189, Mathematics and Computer Science Division, Argonne National Laboratory, 1994.

....3.1 Core Abstractions The Nexus interface is organized around five basic abstractions: nodes, contexts, threads, global pointers, and remote service requests. The associated services provide direct support for light weight threading, address space management, communication, and synchronization [14]. A computation consists of a set of threads, each executing in an address space called a context. An individual thread executes a sequential program, which may read and write data shared with other threads executing in the same context. It can also generate asynchronous remote service ....

Ian Foster, Carl Kesselman, Robert Olson, and Steve Tuecke. Nexus: An interoperability toolkit for parallel and distributed computer systems. Technical Report ANL/MCS-TM-189, Argonne National Laboratory, 1994.

....2.1 Core Abstractions The Nexus interface is organized around five basic abstractions: nodes, contexts, threads, global pointers, and remote service requests. The associated services provide direct support for light weight threading, address space management, communication, and synchronization [8]. A computation consists of a set of threads, each executing in an address space called a context. An individual thread executes a sequential program, which may read and write data shared with other threads executing in the same context. It can also generate asynchronous remote service requests, ....

Ian Foster, Carl Kesselman, Robert Olson, and Steve Tuecke. Nexus: An interoperability toolkit for parallel and distributed computer systems. Technical Report ANL/MCS-TM-189, Argonne National Laboratory, 1994.

....FM processes are used to encapsulate data parallel HPF computations, and virtual computers are used to control the allocation of computational resources to HPF computations. The Argonne FM compiler compiles FM to Fortran 77 plus calls to a thread management and message passing library called Nexus [6]. Nexus message passing functions are implemented in terms of TCP IP, shared memory operations, MPI, NX, or PVM, depending on the target architecture. Compilation proceeds without sophisticated analysis, with each FM statement being replaced with a mixture of Fortran code, calls to Nexus ....

I. Foster, C. Kesselman, R. Olson, and S. Tuecke, Nexus: An Interoperability toolkit for parallel and distributed computer systems, Technical Report ANL/MCS-TM-189, Argonne National Laboratory, 1994.

....any information on the Nexus interface or other internal details. 1 Introduction Nexus is a runtime library designed primarily as a compiler target for langages supporting task parallel and mixed data and task parallel execution. The Nexus interface and Nexus design are described elsewhere [1, 2]; here, we provide the information needed to execute programs that use Nexus services. First, we introduce a few basic terms and concepts which are used in this document. We term a compiler that targets the Nexus runtime system a Nexus compiler, and an executable built with such a compiler a Nexus ....

I. Foster, C. Kesselman, R. Olson, and S. Tuecke, Nexus: An interoperability toolkit for parallel and distributed computer systems, Technical Report ANL/MCS-TM-189, Argonne National Laboratory, 1994.

....how these two mechanisms interact with each other and with threads, and how they can be used to implement a wide variety of parallel program structures. Our proposed global pointer and remote service request mechanisms have been incorporated into a multithreaded communication library called Nexus [26], which we and others have used to build a variety of higher level communication libraries [30, 27, 40] and to implement several parallel languages [10, 39, 25] We use a Nexus implementation to perform detailed performance studies of our proposed communication mechanisms on several parallel ....

I. Foster, C. Kesselman, R. Olson, and S. Tuecke. Nexus: An interoperability toolkit for parallel and distributed computer systems. Technical Report ANL/MCS-TM-189, Argonne National Laboratory, 1993.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC