An analysis of VI Architecture primitives in support of parallel and distributed communication

Begel, Andrew; Buonadonna, Philip; Culler, David

doi:10.1002/cpe.616

Cited by 7 publications

(4 citation statements)

References 28 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…This approach can in principle result in lower NI or host overheads, but the question remains if this potential performance increase outweighs the significant loss of flexibility. Software-based implementations of the VI architecture also exist, however [Begel et al 2002].…”

Section: Related Workmentioning

confidence: 99%

Cluster communication protocols for parallel-programming systems

Verstoep

Bhoedjang

Rühl

et al. 2004

ACM Trans. Comput. Syst.

View full text Add to dashboard Cite

Clusters of workstations are a popular platform for high-performance computing. For many parallel applications, efficient use of a fast interconnection network is essential for good performance. Several modern System Area Networks include programmable network interfaces that can be tailored to perform protocol tasks that otherwise would need to be done by the host processors. Finding the right trade-off between protocol processing at the host and the network interface is difficult in general. In this work, we systematically evaluate the performance of different implementations of a single, user-level communication interface. The implementations make different architectural assumptions about the reliability of the network and the capabilities of the network interface. The implementations differ accordingly in their division of protocol tasks between host software, network-interface firmware, and network hardware. Also, we investigate the effects of alternative data-transfer methods and multicast implementations, and we evaluate the influence of packet size. Using microbenchmarks, parallel-programming systems, and parallel applications, we assess the performance of the different implementations at multiple levels. We use two hardware platforms with different performance characteristics to validate our conclusions. We show how moving protocol tasks to a relatively slow network interface can yield both performance advantages and disadvantages, depending on specific characteristics of the application and the underlying parallelprogramming system.

show abstract

Section: Related Workmentioning

confidence: 99%

Cluster communication protocols for parallel-programming systems

Verstoep

Bhoedjang

Rühl

et al. 2004

ACM Trans. Comput. Syst.

View full text Add to dashboard Cite

show abstract

“…GASnet has been implemented natively on a variety of network hardware and software API's including Quadrics [20], Infiniband, Myrinet, IBM LAPI, and Cray's Portals [7] and SHMEM. The VI Architecture (Infiniband) has been also used to speed up performance for Active Messages and Split-C [5] as well as lower level DSM implementation [11].…”

Section: Pgas Runtime Supportmentioning

confidence: 99%

Introducing mNUMA

Vance

Kogge

2010

Proceedings of the Fourth Conference on Partitioned Global Address Space Programming Model

View full text Add to dashboard Cite

We describe design details of a LightWeight Processing migration-NUMA architecture, a novel high performance system design that provides hardware support for a partitioned global address space, migrating subjects, and word level synchronization primitives. Using the architectural definition, combinations of structures are shown to work together to carry out basic actions such as address translation, migration, in-memory synchronization, and work management. We present results from simulation of microkernels showing that LWP-mNUMA compensates for latency with far greater memory access concurrency than possible on a conventional systems. In particular, several microkernels model tough, irregular access patterns that have limited speedups -in certain problem areas -to dozens of conventional processors. On these, results show speedup increasing up to 1024 multicore mNUMA processing nodes, running over 1 million threadlets.LightWeight Processing migration-NUMA refers to this synergistic combination of massively parallel lightweight multithreading, migration based consistency, and memory extensions for word level inter-thread synchronization.LWP-mNUMA draws on previous investigation [14] into architectural techniques to support applications which do not map well to distributed memory systems. In the process of mapping graph traversal applications [17] onto a novel architecture [27], a new architecture, programming model, and algorithmic approach emerged simultaneously. This paper presents initial results of this co-design.This paper begins with a description (section 2) of the programming environment supported by mNUMA hardware. Next, the architecture itself is presented in two sections. Section 3 presents major hardware components and memory structures. Then, section 4 explains how these components interact to ensure correct and efficient operation of memory access, thread management, and synchronization. Section 5 presents a set of experimental results. After the reader has seen how mNUMA fits together, section 6 presents related work. Section 7 concludes with summary and future work. Mobile-Subjective Programming ModelAll computation and communication in an mNUMA system occurs by the action of subjects. Subjects are strictly runtime entities, dynamically created from code objects specified by a programmer. Subjectivity results from always placing executing objects in ex-A0

show abstract

“…A mediumlevel software layer should be implemented on top of VIA to provide the application with highlevel network protocols like sockets, message passing interface (MPI), and remote procedure calls (RPC). This layer can already be optimized for a specific type of application, taking into consideration communication patterns and application-dependent limitations [30][31][32].VIA provides a communicating process with a directly accessible interface to a network interface controller (NIC). This is called a virtual interface (VI) and represents the endpoint of a point-to-point communication channel.…”

mentioning

confidence: 99%

Software Distributed Shared Memory: a VIA-based implementation and comparison of sequential consistency with home-based lazy release consistency

Iosevich

Schuster

2005

Softw: Pract. Exper.

View full text Add to dashboard Cite

A Distributed Shared Memory (DSM) system provides a distributed application with a shared virtual address space. This article proposes a design for implementing the DSM communication layer on top of the Virtual Interface Architecture (VIA), an industry standard for user-level networking protocols on high-speed clusters. User-level communication protocols operate in user mode, thus removing the operating system kernel's overhead from the critical communication pass, and significantly diminishing communication overhead as a result. We analyze VIA's facilities and limitations in order to ascertain which implementation trade-offs can be best applied to our development of an efficient communication substrate optimized for DSM requirements. We then implement a multithreaded version of the Home-based Lazy Release Consistency (HLRC) protocol on top of this substrate. In addition, we compare the performance of this HLRC protocol with that of the Sequential Consistency (SC) protocol in which a MULTIVIEW (MV) memory mapping technique was used. This technique enables a fine-grained access to shared memory, while still relying on the virtual memory hardware to track memory accesses. We perform an 'apple-toapple' comparison on the same testbed environment and benchmark suite, and investigate the effectiveness and scalability of both protocols. ; 35:755-786 SOFTWARE DISTRIBUTED SHARED MEMORY 757 synchronization points are reached; that is, between these synchronization points, the shared memory may appear inconsistent to different processors. These alternate models guarantee, for properlylabeled [4] programs, results equivalent to those of a sequentially consistent system. Informally, a program is properly labeled if the program contains enough synchronization to avoid data races. Synchronization operations are divided into ACQUIRE and RELEASE operations, used respectively to obtain and yield exclusive access to shared data. These operations can be thought of as standard lock operations.Lazy Release Consistency (LRC) [5,6] is a refinement of the Release Consistency (RC) model [4]. The RC model requires that shared memory accesses be performed globally upon a RELEASE operation only. The idea of LRC is to make those accesses visible only to the processor that acquires a lock rather than perform all operations globally. A home-based implementation of LRC (HLRC) was proposed by Iftode [10]. In this implementation each shared page has an assigned home node that always hosts the most updated contents of the page. These updated contents may be fetched by a non-home node that needs an updated version. ContributionThis work compares the runtime performance of two multithreaded memory coherence protocols: a multithreaded implementation of the HLRC model and an efficient multithreaded implementation of the SC model that uses a MULTIVIEW [11,12] memory mapping technique. We also examine and compare the scalability of these protocols to a multithreaded mode of execution. Previous studies proposed non-preemptive multithreading [13] or creati...

show abstract

An analysis of VI Architecture primitives in support of parallel and distributed communication

Cited by 7 publications

References 28 publications

Cluster communication protocols for parallel-programming systems

Cluster communication protocols for parallel-programming systems

Introducing mNUMA

Software Distributed Shared Memory: a VIA-based implementation and comparison of sequential consistency with home-based lazy release consistency

Contact Info

Product

Resources

About