Demo Data from EDBT 2026 / reviewers in the wild / expert
M. Abud
dblp:77/6845
· DBLP profile ↗
1ranked-venue papers
0as first author
0since 2021 · last 1996
—ORCID · none
Domains — the database's venue-derived domains; a paper can count in several
Systems, architecture and hardware · 1Software engineering, systems software and programming languages · 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 |
Memory systems · 61% Processor architecture and microarchitecture · 30% Interconnection networks and networks-on-chip · 9% |
Topics — the 4 heaviest of 4, each with the papers that count most for it
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Memory systems
cache coherence |
0.0 | 1 | 1996 | Hiding Communication Latency and Coherence Overhead in Software DSMs · ASPLOS 1996 |
Processor architecture and microarchitecture
latency hiding |
0.0 | 1 | 1996 | Hiding Communication Latency and Coherence Overhead in Software DSMs · ASPLOS 1996 |
Memory systems › shared memory › distributed shared memory
software distributed shared memory |
0.0 | 1 | 1996 | Hiding Communication Latency and Coherence Overhead in Software DSMs · ASPLOS 1996 |
Interconnection networks and networks-on-chip › network interface
programmable network interface |
0.0 | 1 | 1996 | Hiding Communication Latency and Coherence Overhead in Software DSMs · ASPLOS 1996 |
Methods — techniques the papers use, named apart from their topics
execution-driven simulation · 0.0
| Year | Publication | Venue | Position |
|---|---|---|---|
| 1996 | Hiding Communication Latency and Coherence Overhead in Software DSMsabstractIn this paper we propose the use of a PCI-based programmable protocol controller for hiding communication and coherence overheads in software DSMs. Our protocol controller provides three different types of overhead tolerance: a) moving basic communication and coherence tasks away from computation processors; b) prefetching of diffs; and c) generating and applying diffs with hardware assistance. We evaluate the isolated and combined impact of these features on the performance of TreadMarks. We also compare performance against two versions of the Shrimp-based AURC protocol. Using detailed execution-driven simulations of a 16-node network of workstations, we show that the greatest performance benefits provided by our protocol controller come from our hardware-supported diffs. Reducing the burden of communication and coherence transactions on the computation processor is also beneficial but to a smaller extent. Prefetching is not always profitable. Our results show that our protocol controller can improve running time performance by up to 50% for TreadMarks, which means that it can double the TreadMarks speedups. The overlapping implementation of TreadMarks performs as well or better than AURC for 5 of our 6 applications. We conclude that the simple hardware support we propose allows for the implementation of high-performance software DSMs at low cost. Based on this conclusion, we are building the NCP2 parallel system at COPPE/UFRJ. Ricardo Bianchini, Leonidas I. Kontothanassis, Raquel Pinto, M. De Maria, M. Abud, Claudio Luis de Amorim |
ASPLOS | 5 |