A fine-grain parallel architecture based on barrier synchronization

Dietz, Henry G.; Hoare, Raymond R.; Mattox, Timothy I.

doi:10.1109/icpp.1996.539061

Cited by 12 publications

(13 citation statements)

References 2 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Likewise, single-user applications may also contain multiple threads participating in different active barriers that require distinct identification. As with the barrier method proposed in this paper, several recent research efforts have aimed at providing this important multiple barrier capability [14,15,17].…”

Section: Characteristics Of Barrier Mechanismsmentioning

confidence: 99%

See 1 more Smart Citation

Distributed-sum termination detection supporting multithreaded execution

2003

View full text Add to dashboard Cite

Section: Characteristics Of Barrier Mechanismsmentioning

confidence: 99%

“…The barrier synchronization issue has been studied from both software [1][2][3][4][5][6][7][8][9] and hardware perspectives [12][13][14][15][16][17][18][19]. A good overview of the barrier synchronization problem is presented by Arenstorf and Jordan [4], along with a representative range of solutions.…”

Section: Previous Workmentioning

confidence: 99%

Distributed-sum termination detection supporting multithreaded execution

2003

View full text Add to dashboard Cite

“…PAPERS, Purdue's Adapter for Parallel Execution and Rapid Synchronization, is a network that allows a number of aggregate computations to be performed within a custom network hub that is attached to a cluster of Linux PCs [23][24][25]. This design uses a combination of barrier synchronization with a four-bit wide global NAND to construct a robust library of aggregate computations and communications.…”

Section: Related Researchmentioning

confidence: 99%

ClusterNet: An Object-Oriented Cluster Network

Hoare

2000

Lecture Notes in Computer Science

View full text Add to dashboard Cite

Abstract. Parallel processing is based on utilizing a group of processors to efficiently solve large problems faster than is possible on a single processor. To accomplish this, the processors must communicate and coordinate with each other through some type of network. However, the only function that most networks support is message routing. Consequently, functions that involve data from a group of processors must be implemented on top of message routing. We propose treating the network switch as a function unit that can receive data from a group of processors, execute operations, and return the result(s) to the appropriate processors. This paper describes how each of the architectural resources that are typically found in a network switch can be better utilized as a centralized function unit. A proof-of-concept prototype called ClusterNet 4EPP has been implemented to demonstrate feasibility of this concept.

show abstract

“…Examples include [11], [12], [13], [14], [15]. Other works have focused on message passing architectures [16], [17], [18], [3], [19], [4], [5], [6].…”

Section: Introductionmentioning

confidence: 99%

“…This quest has spurred numerous research efforts into collective offload designs [3], [4], [5], [6], [7], [8]. Recently, much research has focused on leveraging the programmable processor that has become common on high-performance network interfaces to offload collective operations.…”

Section: Introductionmentioning

confidence: 99%

Implications of application usage characteristics for collective communication offload

Brightwell

Goudy

Rodrigues

et al. 2006

IJHPCN

View full text Add to dashboard Cite

Abstract-The performance of collective communication operations is known to have a significant impact on the scalability of some applications. Indeed, the global, synchronous nature of some collective operations directly implies that they will become the bottleneck when scaling to hundreds of thousands of nodes. This fact has led many researchers to try to improve the efficiency of collective operations. One popular approach improves the implementation of MPI collective operations by using intelligent or programmable network interfaces to offload the burden of communication activities from the host processor(s). Such implementations have shown significant improvement for microbenchmarks that isolate collective communication performance, but these results have not been shown to translate to significant increases in performance for real applications. In order for collective offload implementations to benefit real applications, a greater understanding of application behavior is needed. In this paper, we describe several characteristics of applications and application benchmarks that impact collective communication performance. We analyze network resource usage data in order to guide the design of collective offload engines and their associated programming interfaces. In particular, we provide an analysis of the potential benefit of non-blocking collective communication operations for MPI.

show abstract

A fine-grain parallel architecture based on barrier synchronization

Cited by 12 publications

References 2 publications

Distributed-sum termination detection supporting multithreaded execution

Distributed-sum termination detection supporting multithreaded execution

ClusterNet: An Object-Oriented Cluster Network

Implications of application usage characteristics for collective communication offload

Contact Info

Product

Resources

About