Demo Data from EDBT 2026 / reviewers in the wild / expert
Sergey Oblomov
dblp:208/1933
· DBLP profile ↗
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
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Parallel and multicore computing › parallel programming models
message passing |
0.3 | 1 | 2017 | 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.3 | 1 | 2017 | Why is MPI so slow?: analyzing the fundamental limits in implementing MPI-3.1 · SC 2017 |
Parallel and multicore computing
parallel programming models |
0.3 | 1 | 2017 | Why is MPI so slow?: analyzing the fundamental limits in implementing MPI-3.1 · SC 2017 |
High-performance computing
performance optimization at scale |
0.3 | 1 | 2017 | 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
| Year | Publication | Venue | Position |
|---|---|---|---|
| 2017 | Why is MPI so slow?: analyzing the fundamental limits in implementing MPI-3.1abstractThis 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 |
SC | 20 |