Demonstration venue · read-only. Every page can be browsed; the buttons that would change it are switched off. Create an account to run TaxoReview on your own data. A simulation from public publication records: the people listed were not invited and did not agree to review.
? Tutorial for this page

Sergey Oblomov

dblp:208/1933 · DBLP profile ↗
← Back
1ranked-venue papers
0as first author
0since 2021 · last 2017
—ORCID · none

Domains — the database's venue-derived domains; a paper can count in several

Systems, architecture and hardware · 1

Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.

Computer architecture, parallel and distributed computing, and storage systems
1 paper
Parallel and multicore computing · 70% High-performance computing · 23% Interconnection networks and networks-on-chip · 7%

Topics — the 4 heaviest of 5, each with the papers that count most for it

TopicWeightPapersLastEvidence papers
Parallel and multicore computing › parallel programming models
message passing
0.312017
Why is MPI so slow?: analyzing the fundamental limits in implementing MPI-3.1 · SC 2017
Parallel and multicore computing › parallel programming models › message passing
MPI implementation
0.312017
Why is MPI so slow?: analyzing the fundamental limits in implementing MPI-3.1 · SC 2017
Parallel and multicore computing
parallel programming models
0.312017
Why is MPI so slow?: analyzing the fundamental limits in implementing MPI-3.1 · SC 2017
High-performance computing
performance optimization at scale
0.312017
Why is MPI so slow?: analyzing the fundamental limits in implementing MPI-3.1 · SC 2017

Methods — techniques the papers use, named apart from their topics

instruction-level analysis · 0.3communication stack optimization · 0.3
YearPublicationVenuePosition
2017 Why is MPI so slow?: analyzing the fundamental limits in implementing MPI-3.1
abstract
This paper provides an in-depth analysis of the software overheads in the MPI performance-critical path and exposes mandatory performance overheads that are unavoidable based on the MPI-3.1 specification. We first present a highly optimized implementation of the MPI-3.1 standard in which the communication stack---all the way from the application to the low-level network communication API---takes only a few tens of instructions. We carefully study these instructions and analyze the root cause of the overheads based on specific requirements from the MPI standard that are unavoidable under the current MPI standard. We recommend potential changes to the MPI standard that can minimize these overheads. Our experimental results on a variety of network architectures and applications demonstrate significant benefits from our proposed changes.
Kenneth Raffenetti, Abdelhalim Amer, Lena Oden, Charles Archer, Wesley Bland, Hajime Fujita 0002, Yanfei Guo, Tomislav Janjusic, Dmitry Durnov, Michael Blocksome, Min Si, Akhil Langer, Gengbin Zheng, Masamichi Takagi, Paul K. Coffman, Sayantan Sur, Alexander Sannikov, Sergey Oblomov, Michael Chuvelev, Masayuki Hatanaka, Paul F. Fischer, Thilina Ratnayaka, Matthew Otten, Misun Min, Pavan Balaji
SC20