An analysis of NIC resource usage for offloading MPI

Brightwell, Ron; Underwood, Keith D.

doi:10.1109/ipdps.2004.1303192

Cited by 33 publications

(32 citation statements)

References 24 publications

(29 reference statements)

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Even at small scale, applications can spend a large portion of their time waiting for messages to arrive and reductions in bandwidth or failure to substantially improve latency over conventional methods can greatly exacerbate this problem. A custom NIC that integrates the network controller, and in some cases the messaging protocol, onto the chip to reduce power, is expected to also increase messaging throughput and communication performance [2,17]. Although there is a risk of choosing a network interface that is not compatible with all the underlying data communication layers, applications that send small and frequent messages are likely to benefit from such integration.…”

Section: Integrated Componentsmentioning

confidence: 99%

Abstract Machine Models and Proxy Architectures for Exascale Computing

Ang

Barrett

Benner

et al. 2014

2014 Hardware-Software Co-Design for High Performance Computing

View full text Add to dashboard Cite

To achieve exascale computing, fundamental hardware architectures must change. The most significant consequence of this assertion is the impact on the scientific applications that run on current high performance computing (HPC) systems, many of which codify years of scientific domain knowledge and refinements for contemporary computer systems. In order to adapt to exascale architectures, developers must be able to reason about new hardware and determine what programming models and algorithms will provide the best blend of performance and energy efficiency into the future. While many details of the exascale architectures are undefined, an abstract machine model is designed to allow application developers to focus on the aspects of the machine that are important or relevant to performance and code structure. These models are intended as communication aids between application developers and hardware architects during the co-design process. We use the term proxy architecture to describe a parameterized version of an abstract machine model, with the parameters added to elucidate potential speeds and capacities of key hardware components. These more detailed architectural models are formulated to enable discussion between the developers of analytic models and simulators and computer hardware architects. They allow for application performance analysis and hardware optimization opportunities. In this report our goal is to provide the application development community with a set of models that can help software developers prepare for exascale. In addition, use of proxy architectures, through the use of proxy architectures, we can enable a more concrete exploration of how well application codes map onto the future architectures.

show abstract

Section: Integrated Componentsmentioning

confidence: 99%

Abstract Machine Models and Proxy Architectures for Exascale Computing

Ang

Barrett

Benner

et al. 2014

2014 Hardware-Software Co-Design for High Performance Computing

View full text Add to dashboard Cite

show abstract

“…On the other hand, a lot of messages comparable to the number of nodes stay in the unexpected message queue in some case. For example, FT and IS of NAS Parallel Benchmarks (NPB) is so according to the research by Brightwell [4]. He reported that in FT the average search length for the unexpected message queue at 128 nodes is 20% or more than the number of nodes, and that it increases in proportion to the number of nodes.…”

Section: Unexpected Message Searching Latencymentioning

confidence: 99%

“…In Brightwell's work [4], a significant portion of the messages received by the NAS Parallel Benchmarks (NPB)…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Network Interface Architecture with Scalable Low-Latency Message Receiving Mechanism

Tanabe

Ohta

2013

IEICE Trans. Inf. & Syst.

View full text Add to dashboard Cite

SUMMARYMost of scientists except computer scientists do not want to make efforts for performance tuning with rewriting their MPI applications. In addition, the number of processing elements which can be used by them is increasing year by year. On large-scale parallel systems, the number of accumulated messages on a message buffer tends to increase in some of their applications. Since searching message queue in MPI is time-consuming, system side scalable acceleration is needed for those systems. In this paper, a support function named LHS (Limited-length Head Separation) is proposed. Its performance in searching message buffer and hardware cost are evaluated. LHS accelerates searching message buffer by means of switching location to store limited-length heads of messages. It uses the effects such as increasing hit rate of cache on host with partial offloading to hardware. Searching speed of message buffer when the order of message reception is different from the receiver's expectation is accelerated 14.3 times with LHS on FPGA-based network interface card (NIC) named DIMMnet-2. This absolute performance is 38.5 times higher than that of IBM BlueGene/P although the frequency is 8.5times slower than BlueGene/P. LHS has higher scalability than ALPU in the performance per frequency. Since these results are obtained with partially on loaded linear searching on old Pentium R 4, performance gap will increase using state of art CPU. Therefore, LHS is more suitable for larger parallel systems. The discussions for adopting proposed method to state of art processors and systems are also presented. key words: network interface, MPI, message passing, queue management, low latency communication, scalability

show abstract

“…In previous work, we collected and analyzed data related to the MPI posted receive and unexpected message queues, and measured expected versus unexpected messages [26]. We used these measurements to characterize the amount of processing and memory resources that are needed for offloading MPI semantics.…”

Section: A Mpi Profilingmentioning

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

An analysis of NIC resource usage for offloading MPI

Abstract: Modern cluster interconnection networks rely on pro-

Cited by 33 publications

References 24 publications

Abstract Machine Models and Proxy Architectures for Exascale Computing

Abstract Machine Models and Proxy Architectures for Exascale Computing

Network Interface Architecture with Scalable Low-Latency Message Receiving Mechanism

Implications of application usage characteristics for collective communication offload

Contact Info

Product

Resources

About