Results 1 - 10
of
39
Software Overhead in Messaging Layers: Where Does the Time Go?
- In Proceedings of the Sixth Symposium on Architectural Support for Programming Languages and Operating Systems (ASPLOS-VI
, 1994
"... Despite improvements in network interfaces and software messaging layers, software communication overhead still dominates the hardware routing cost in most systems. In this study, we identify the sources of this overhead by analyzing software costs of typical communication protocols built atop the a ..."
Abstract
-
Cited by 68 (10 self)
- Add to MetaCart
Despite improvements in network interfaces and software messaging layers, software communication overhead still dominates the hardware routing cost in most systems. In this study, we identify the sources of this overhead by analyzing software costs of typical communication protocols built atop the active messages layer on the CM-5. We show that up to 50--70% of the software messaging costs are a direct consequence of the gap between specific network features such as arbitrary delivery order, finite buffering, and limited fault-handling, and the user communication requirements of in-order delivery, end-to-end flow control, and reliable transmission. However, virtually all of these costs can be eliminated if routing networks provide higher-level services such as in-order delivery, end-to-end flow control, and packet-level fault-tolerance. We conclude that significant cost reductions require changing the constraints on messaging layers: we propose designing networks and network interfaces...
Fast Messages (FM): Efficient, Portable Communication for Workstation Clusters and Massively-Parallel Processors
- IEEE CONCURRENCY
, 1997
"... ..."
A Resource Query Interface for Network-Aware Applications
- Cluster Computing
, 1999
"... Development of portable network-aware applications demands an interface to the network that allows an application to obtain information about its execution environment. This paper motivates and describes the design of Remos, an API that allows network-aware applications to obtain relevant informatio ..."
Abstract
-
Cited by 55 (15 self)
- Add to MetaCart
Development of portable network-aware applications demands an interface to the network that allows an application to obtain information about its execution environment. This paper motivates and describes the design of Remos, an API that allows network-aware applications to obtain relevant information. The major challenges in defining a uniform interface are network heterogeneity, diversity in traffic requirements, variability of the information, and resource sharing in the network. Remos addresses these issues with two abstraction levels, explicit management of resource sharing, and statistical measurements. The flows abstraction captures the communication between nodes, and the topologies abstraction provides a logical view of network connectivity. Remos measurements are made at network level, and therefore information to manage sharing of resources is available. Remos is designed to deliver best effort information to applications, and it explicitly adds statistical reliability and va...
A Comparison of Architectural Support for Messaging in the TMC CM-5 and the Cray T3D
- In Proceedings of the International Symposium on Computer Architecture
, 1995
"... Programming models based on messaging continue to be an important programming model for parallel machines. Messaging costs are strongly influenced by a machine's network interface architecture. We examine the impact of architectural support for messaging in two machines -- the TMC CM-5 and the Cray ..."
Abstract
-
Cited by 55 (15 self)
- Add to MetaCart
Programming models based on messaging continue to be an important programming model for parallel machines. Messaging costs are strongly influenced by a machine's network interface architecture. We examine the impact of architectural support for messaging in two machines -- the TMC CM-5 and the Cray T3D -- by exploring the design and performance of several messaging implementations. The additional features in the T3D support remote operations: memory access, fetch-and-increment, atomic swaps, and prefetch. Experiments on the CM-5 show that requiring processor involvement for message reception can increase the communication overheads from 60% to 300% for moderate variations in computation grain size at the destination. In contrast, the T3D hardware for remote operations decouples message reception from processor activity, producing high-performance messaging independent of computation grain size or variability. In addition, hardware support for a shared address space in the T3D can be us...
ReMoS: A Resource Monitoring System for Network-Aware Applications
, 1997
"... Development of portable network-aware applications demands an interface to the network that allows an application to obtain information about its execution environment. This paper motivates and describes the design of Remos, an API that allows network-aware applications to obtain relevant informatio ..."
Abstract
-
Cited by 41 (8 self)
- Add to MetaCart
Development of portable network-aware applications demands an interface to the network that allows an application to obtain information about its execution environment. This paper motivates and describes the design of Remos, an API that allows network-aware applications to obtain relevant information. The major challenges in defining a uniform interface are network heterogeneity, diversity in traffic requirements, variability of the information, and resource sharing in the network. Remos addresses these issues with two abstraction levels, explicit management of resource sharing, and statistical measurements. The flows abstraction captures the communication between nodes, and the topologies abstraction provides a logical view of network connectivity. Remos measurements are made at network level, and therefore information to manage sharing of resources is available. Remos is designed to deliver best effort information to applications, and it explicitly adds statistical reliability and variability measures to the core information. The paper also presents preliminary results and experience with a prototype Remos implementation for a high speed IP-based network testbed.
Distributed Shared Memory: Where we are and where . . .
"... It has been almost ten years since the birth of the first distributed shared memory (DSM) system, Ivy. While significant progress has been made in the area of improving the performance of DSM and DSM has been the focus of several dozen PhD theses, its overall impact on "real" users and applications ..."
Abstract
-
Cited by 41 (1 self)
- Add to MetaCart
It has been almost ten years since the birth of the first distributed shared memory (DSM) system, Ivy. While significant progress has been made in the area of improving the performance of DSM and DSM has been the focus of several dozen PhD theses, its overall impact on "real" users and applications has been small. The goal of this paper is to present our position on what remains to be done before DSM will have a significant impact on real applications. More specifically, we reflect on what we believe have been the major advances in the area, what the important outstanding problems are, and what work needs to be done. Finally, we describe amodest step towards solving these problems, the Quarks DSM system.
IceT: Distributed Computing and Java
- Concurrency, Practice and Experience
, 1997
"... Metacomputing, or distributed processing on networks (local networks, intranets, or the Internet), has re-emerged as a technology with tremendous promise and potential, owing in part to the emergence of the Java language and programming system. Java both influences and is influenced by the requisite ..."
Abstract
-
Cited by 32 (2 self)
- Add to MetaCart
Metacomputing, or distributed processing on networks (local networks, intranets, or the Internet), has re-emerged as a technology with tremendous promise and potential, owing in part to the emergence of the Java language and programming system. Java both influences and is influenced by the requisite and dynamic aspects of network programming. However, its viability as a programming language for the scientific community is yet to be established. This paper describes IceT, a novel framework for collaborative and highperformance distributed computing which has been built upon a Java substrate. The IceT system exploits the portability and scripting advantages of Java and incorporates well established distributed and concurrent computing techniques into the framework, while retaining the ability to access specialized processing capabilities and precompiled code. The result is a dynamic and efficient distributed computing environment upon which data and processes are highly portable amongst ...
Do Faster Routers Imply Faster Communication?
- In First International Workshop, PCRCW'94, volume 853 of LNCS
, 1994
"... . Despite significant improvements in network interfaces and software messaging layers, software communication overhead still dominates the hardware routing cost in most parallel systems. In this study, we identify the sources of this overhead by relating user communication services to particular ..."
Abstract
-
Cited by 19 (0 self)
- Add to MetaCart
. Despite significant improvements in network interfaces and software messaging layers, software communication overhead still dominates the hardware routing cost in most parallel systems. In this study, we identify the sources of this overhead by relating user communication services to particular network hardware features. Based on a detailed analysis of the active messages layer on the CM-5, we assign the software messaging cost to specific user communication services and network features. Our study shows that 50--70% of the software cost of messaging can be attributed to providing end-to-end flow control, in-order delivery, and reliable transmission services. This overhead is a direct effect of specific network features -- arbitrary delivery order, finite buffering, and limited fault-handling -- and is unlikely to be eliminated through improved software implementations. We conclude that reducing this software overhead requires changing the constraints on messaging layers...
A.: An object-oriented platform for distributed high-performance Symbolic Computation
- Mathematics and Computers in Simulation 49
, 1999
"... We describe the Distributed Object-Oriented Threads System (DOTS), a programming environment designed to support object-oriented fork/join parallel programming in a heterogeneous distributed environment. A mixed network of Windows NT PC’s and UNIX workstations is transformed by DOTS into a homogeneo ..."
Abstract
-
Cited by 14 (9 self)
- Add to MetaCart
We describe the Distributed Object-Oriented Threads System (DOTS), a programming environment designed to support object-oriented fork/join parallel programming in a heterogeneous distributed environment. A mixed network of Windows NT PC’s and UNIX workstations is transformed by DOTS into a homogeneous pool of anonymous compute servers forming together a multicomputer. DOTS is a complete redesign of the Distributed Threads System (DTS) using the object-oriented paradigm both in its internal implementation and in the programming paradigm it supports. It has been used for the parallelization of applications in the field of computer algebra and in the field of computer graphics. We also give a brief account of applications in the domain of symbolic computation that were developed using DTS. Key words: distributed threads system, heterogeneous networks, Windows NT
The Charm Parallel Programming Language and System: Part I - Description of Language Features
, 1995
"... We describe a parallel programming system for developing machine independent programs for all MIMD machines. Many useful approaches to this problem are seen to require a common base of support, which can be encapsulated in a language that abstracts over resource management decisions and machine s ..."
Abstract
-
Cited by 14 (3 self)
- Add to MetaCart
We describe a parallel programming system for developing machine independent programs for all MIMD machines. Many useful approaches to this problem are seen to require a common base of support, which can be encapsulated in a language that abstracts over resource management decisions and machine specific details. This language can be used for implementing other high level approaches as well as for efficient application programming. The requirements for such a language are defined, and the language supported by the Charm system is described, and illustrated with examples. Charm is one of the first languages to support message driven execution, and embodies unique abstractions such as branch office chares and specifically shared variables. In Part II of this paper, we talk about the runtime support system for Charm. The system thus provides ease of programming on MIMD platforms without sacrificing performance. This research was supported in part by the National Science Foundatio...

