Pith. sign in

REVIEW 3 major objections 7 minor 53 references

Network-Accelerated Non-Contiguous Memory Transfers

T0 review · 3 major / 7 minor · reviewed 2026-08-14 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read The paper claims that a programmable NIC executing per-packet handlers can transparently unpack MPI derived datatypes at or near line rate, achieving true zero-copy non-contiguous transfers.

desk verdict A clever and honest SmartNIC offload paper whose headline speedups rest on an optimistic NIC memory model; the RW-CP idea is real and worth building on, but the numbers for small-block layouts need a more realistic memory simulation or hardware validation. read the letter →

arxiv 1908.08590 v1 pith:57SJ6QSK submitted 2019-08-22 cs.NI cs.DC

Salvatore Di Girolamo , Konstantin Taranov , Andreas Kurth , Michael Schaffner , Timo Schneider , Jakub Beránek , Maciej Besta , Luca Benini
show 2 more authors
Duncan Roweth Torsten Hoefler
This is my paper · ORCID
classification cs.NIcs.DC
keywords MPIderiveddatatypesnon-contiguousmemorytransferszero-copycommunicationsPINprogrammableNICpacketprocessingPortals4networkacceleration
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Non-contiguous memory transfers—sending a column of a matrix, halo exchanges, particle data—remain a persistent bottleneck: they can run up to five times slower than contiguous transfers of the same size. This paper argues that the bottleneck can be moved off the CPU by giving the network card small per-packet programs that unpack MPI derived datatypes as data streams through the NIC. In simulations of a 200 Gbit/s Portals 4 NIC extended with the sPIN packet-streaming model, the approach reaches line rate for many layouts, speeds up real application datatypes by up to 12x over host-based unpacking, and cuts main-memory traffic by a geometric-mean factor of 3.8. The payoff would be true zero-copy communication for a standard, already-widely-used interface, with no application code changes.

What carries the argument

The load-bearing mechanism is the pairing of sPIN, a packet-streaming processing model in which a NIC executes a handler on every packet of a message, with a checkpointed representation of MPI datatype processing state. The general handlers use the dataloops representation of MPI datatypes: a datatype is a tree of descriptors (contig, vector, blockindexed, indexed, struct), and partial progress through that tree is captured in a segment, a stack of dataloop states. To let many handler processing units work on different packets in parallel without write conflicts, the paper introduces checkpoints, snapshots of the segment taken every $\Delta r$ bytes, and three state strategies: HPU-local replicates the segment per virtual handler unit, RO-CP copies the nearest checkpoint in each handler, and RW-CP gives each virtual handler unit exclusive ownership of a checkpoint, avoiding both catch-up phases and copies for in-order delivery. A blocked round-robin scheduler with virtual handler units enforces the packet-to-checkpoint assignment. The same machinery is extended to the sender side with streaming puts and outbound sPIN (PtlProcessPut), which let sender-side handlers generate packets and DMA the right contiguous regions out.

What would settle it

Run the progressing-checkpoint and specialized payload handlers on a cycle-accurate register-transfer-level model of a banked NIC SRAM, or on a prototype SmartNIC, with a 4 MiB vector-datatype message of 128-byte blocks at 200 Gbit/s, and compare throughput against host unpacking; if offload throughput falls below the host for blocks above 256 bytes, or if main-memory traffic counters show DMA writes incur read-for-ownership traffic that erases the 3.8x reduction, the central claim would fail.

Watch

Extended reading notes

Core claim

The paper's central claim is that non-contiguous memory transfers can be transparently network-accelerated, truly achieving zero-copy communications. Concretely, it shows that a NIC running sPIN-style handlers can take each incoming packet of a message described by an MPI derived datatype, compute which scattered addresses in the receive buffer the payload belongs to, and issue DMA writes directly there, so the CPU never copies or touches the data. The authors implement this in a packet-level model of a Portals 4 NIC with cycle-accurate handler cores, compare four offload strategies (specialized handlers, HPU-local, read-only checkpoints, and progressing checkpoints), and report up to 12x speedup of the progressing-checkpoint and specialized handlers over host-based unpacking, plus a 3.8x reduction in data volume moved to and from main memory. They also state the limits: very small blocks (4 bytes) still lose to the host, single-packet messages gain nothing, and unexpected messages must fall back to CPU unpacking.

Load-bearing premise

The speedup numbers assume the NIC's on-card memory has one-cycle access latency, very high bandwidth, and no bank contention, and the paper itself concedes the simulator may not model memory contention accurately; if real NIC memory is slower or banked, the block size where offload wins moves up and the reported speedups shrink.

Editorial extensions

If this is right

  • MPI libraries could offload datatype unpacking automatically at type-commit and receive-post time, falling back to the host only for unexpected messages or very small blocks.
  • Datatypes reused across multiple receives amortize the checkpoint-creation cost: in 75% of the application cases studied, the speedup pays off in fewer than four reuses.
  • Because the NIC writes each byte of the message exactly once into its final location, main-memory traffic for a received message drops by a geometric-mean factor of 3.8 relative to host unpacking.
  • A co-integrated accelerator built from 32 RISC-V cores and 12 MiB of on-NIC memory (about 23.5 mm² in 22 nm) is estimated to sustain 192 Gbit/s for block sizes of 256 B and above, suggesting offload fits within a NIC power and area budget.
  • At scale, offloading the transpose in FFT2D shortens application runtime by up to 26% relative to host-based unpacking at 64 nodes.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Extension: the checkpoint-interval heuristic treats $\Delta r$ as a static per-message choice, so a natural next step is adaptive checkpoint placement driven by observed packet arrival order, since out-of-order delivery is exactly the case where RW-CP must reset checkpoints.
  • Extension: the same per-packet handler machinery could carry other data-centric transformations, such as filtering, reduction, or on-the-fly compression, while data is in flight; the paper's hardware estimates cover only datatype handlers, so these uses are untested.
  • Extension: if a physical NIC's on-card memory has bank conflicts or higher latency than the single-cycle model used in the simulation, the crossover block size moves upward; the paper's own cycle-accurate hardware results already show lower throughput than the processor simulation for blocks under 256 bytes.
  • Extension: the comparison baseline assumes a NIC refilling small scatter-gather lists over PCIe with about 500 ns latency, so a NIC with a larger or prefetched iovec table would narrow the gap; the reported 12x speedup is best read as an upper bound against that particular baseline.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 7 minor

Summary. The manuscript proposes and evaluates offloading MPI derived-datatype (DDT) processing to a programmable NIC using the sPIN model. It introduces several mechanisms: streaming puts and outbound sPIN for sender-side offload, specialized per-datatype handlers, and general-purpose receiver-side strategies including HPU-local segments, read-only checkpoints (RO-CP), and progressing checkpoints (RW-CP) under a blocked round-robin vHPU scheduler. The evaluation combines an SST+gem5 model of a Cray Slingshot NIC with 32 ARM cores, a cycle-accurate PULP RTL prototype with synthesis-based area and power estimates, and a LogGOPSim-based FFT2D scaling study. The paper reports up to 12x speedup over host-based unpacking, a 3.8x reduction in main-memory traffic, and identifies cases where offload does not help.

Significance. If the performance claims hold, this is a substantial step toward transparent zero-copy non-contiguous transfers: the RW-CP checkpointing scheme is an elegant solution to the packet-handler state-sharing problem, and the combination of an analytic scheduling model, SST+gem5 evaluation, and a synthesizable RTL prototype with concrete area and power numbers is stronger evidence than typical NIC-offload proposals. The paper also honestly discloses regimes where offload does not help, such as very small messages, very small blocks, and unexpected messages. The main weakness is that the headline speedups rest on an optimistic NIC-memory model that the paper itself questions, as detailed in the major comments.

major comments (3)
  1. [Sec. 5.1 and Sec. 4.3.2] The central speedup claims in Figs. 8 and 16 are produced with the gem5 SimpleMemory NIC-memory model configured with 1-cycle latency, 50 GiB/s bandwidth, and channels equal to twice the HPU count. The paper's own PULP cycle-accurate results in Fig. 10 show lower throughput for block sizes below 256 B due to L2 SPM contention, and Sec. 4.3.2 explicitly concedes that 'the gem5-based simulation may not model memory contention properly.' Because RW-CP and specialized handlers access checkpoints and dataloops on every packet, this optimistic memory model shifts the crossover point where offload beats host unpacking and inflates the reported 10-12x speedups for small-block application layouts. Please add a sensitivity analysis over NIC-memory latency, bandwidth, and channel count, or re-run the application-level benchmarks with PULP-derived handler costs.
  2. [Sec. 5.1 (host baseline)] The host-based unpack baseline is profiled on a single-threaded Intel i7-4770, while the sPIN NIC is modeled with 32 Cortex-A15 HPUs. The 'up to 12x speedup over host-based unpacking' headline therefore compares a single-core host implementation against a 32-core NIC model, which may overstate the benefit of offload. Please justify the single-threaded baseline, or include a stronger host baseline such as a multi-core optimized unpack or a contemporary server CPU, to demonstrate that the speedups are not an artifact of this asymmetry.
  3. [Sec. 5.3 (Fig. 16)] The Portals 4 iovec comparison is modeled rather than measured: it assumes v=32 scatter-gather entries per fetch and a 500 ns PCIe read latency to load the next iovec batch, and the paper states that no Portals 4 implementation is publicly available. Because Fig. 16 presents this as a competing network-accelerated solution, the relative claims against iovec offload depend on these unvalidated parameters. Please label the Portals 4 curve as a model and provide sensitivity to v and the PCIe read latency.
minor comments (7)
  1. [Abstract vs. Sec. 5.3] The abstract reports 'up to 10x speedup' while Sec. 5.3 states 'RW-CP and native can reach up to 12x speedup'; please make these numbers consistent.
  2. [Fig. 16] Figure 16 is extremely dense and the per-bar annotations are unreadable at normal print size; consider splitting it into multiple figures or providing a table of the underlying values.
  3. [Sec. 3.2.4] In the RW-CP message-processing-time model, the symbols Tpkt, k, P, and npkt are not all defined at first use, and the expression 'npkt/P' should be clearly specified as a ceiling division; please revise for clarity.
  4. [Sec. 5.2] The statement 'We observe similar results for other MPI derived datatypes but omit them due to space limitations' is an unsupported claim; please either include a representative additional datatype result or explicitly mark this as future work.
  5. [Sec. 4.3.2] The y-axis label in Fig. 10 contains the typo 'Througput'; it should read 'Throughput'.
  6. [Sec. 5.1] The phrase 'x32 PCIe Gen4' should be written as '32-lane PCIe Gen4' for clarity.
  7. [References] Reference [2] contains a duplicated URL prefix 'http://http://'; please fix it.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the speedup claims emerge from SST/gem5 and PULP simulations against an external host baseline, not from a self-referential derivation.

full rationale

The central claim that sPIN can transparently accelerate non-contiguous MPI datatype transfers is supported by simulation results (Fig. 8, Fig. 16, Fig. 19) that compare offload strategies against host-based unpacking with MPITypes on an Intel i7. The speedups are computed as ratios of simulated times; no fitted constant or derived equation reproduces the headline result by construction. The RW-CP checkpoint interval is selected using the analytic model TC = Tpkt + (Δr/k)(P−1)Tpkt + (npkt/P)TPH(γ), but this model only chooses a scheduling parameter; it does not encode the measured speedup, and the actual throughput is obtained from the SST/gem5 and PULP simulations. The paper builds on the authors' own sPIN concept [14] and gem5 integration approach [38], but these self-citations are not load-bearing for the quantitative results: the paper implements its own NIC model in SST and validates with a cycle-accurate PULP RTL prototype. The acknowledged limitation that 'the gem5-based simulation may not model memory contention properly' (Sec. 4.3.2) is a modeling validity concern, not a circular dependency. No equation or benchmark in the paper reduces to its own inputs, and no prediction is equivalent to a fitted parameter by construction. Accordingly, no circular step is identified.

Assumptions & free parameters 3 free parameters · 4 assumptions · 3 invented entities

The central speedup claim depends on the NIC being able to execute handlers quickly, which in turn depends on the modeled memory system and the new sPIN extensions. No external artifact validates these entities; they are evaluated only within the paper's simulators.

free parameters (3)
  • epsilon for RW-CP checkpoint interval = 0.2
    User-set bound on scheduling overhead used in Sec 3.2.4 to choose the checkpoint interval; lower epsilon uses more NIC memory for checkpoints and shapes the reported speedups.
  • Checkpoint interval delta_r = per experiment
    Chosen per message and datatype via the analytic model in Sec 3.2.4 under the epsilon bound, NIC memory limit, and packet buffer limit; the choice affects handler runtimes and the throughput numbers.
  • Portals 4 baseline iovec entries v = 32
    Set to the maximum scatter-gather entries of a Mellanox ConnectX-3 card (Sec 5.3), used as the comparison baseline; if a real NIC supported more entries the baseline would be stronger.
assumptions (4)
  • domain assumption Portals 4 matching semantics and sPIN execution model as defined in prior work [14]
    The paper builds its NIC model on these interfaces without re-deriving them; the claims inherit their correctness.
  • domain assumption Network delivers header and completion packets as first and last packets of a message
    Assumed in Sec 2.1.2 to route packets to the correct ME and handlers; out-of-order control packets would break the execution model.
  • domain assumption In-order payload arrival for the RW-CP performance model
    The TC model in Sec 3.2.4 assumes packets of a sequence arrive in order; out-of-order arrival incurs checkpoint resets not counted in the model.
  • domain assumption Host unpack baseline is single-threaded MPITypes with cold caches
    Sec 5.1 and 5.3 measure host unpack on one Intel i7-4770 core; the paper does not consider multithreaded unpack on the host, which would narrow the speedup.
invented entities (3)
  • Streaming puts (PtlSPutStart/PtlSPutStream)
    purpose: Extend Portals 4 so multiple contiguous regions can be sent as one message without sender-side packing
    Only implemented in the SST simulator; no real NIC or formal specification outside this paper.
  • PtlProcessPut and outbound sPIN
    purpose: Allow the NIC to execute handlers on outgoing packets, offloading sender-side datatype processing
    New interface operation described in Sec 3.1.2 and simulated, but not realized in hardware.
  • Virtual HPUs (vHPUs) with blocked-RR scheduling
    purpose: Schedule packet handler sequences to avoid write conflicts in checkpoint-based datatype processing
    New scheduling abstraction in Sec 3.2.1; its performance is evaluated only in simulation.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Network-Accelerated Non-Contiguous Memory Transfers." pith.science (2026). https://pith.science/paper/57SJ6QSK

@misc{pith2026190808590,
  author       = {Pith},
  title        = {Pith review of: Network-Accelerated Non-Contiguous Memory Transfers},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/57SJ6QSK}},
  note         = {Machine review of arXiv:1908.08590}
}
read the original abstract

Applications often communicate data that is non-contiguous in the send- or the receive-buffer, e.g., when exchanging a column of a matrix stored in row-major order. While non-contiguous transfers are well supported in HPC (e.g., MPI derived datatypes), they can still be up to 5x slower than contiguous transfers of the same size. As we enter the era of network acceleration, we need to investigate which tasks to offload to the NIC: In this work we argue that non-contiguous memory transfers can be transparently networkaccelerated, truly achieving zero-copy communications. We implement and extend sPIN, a packet streaming processor, within a Portals 4 NIC SST model, and evaluate strategies for NIC-offloaded processing of MPI datatypes, ranging from datatype-specific handlers to general solutions for any MPI datatype. We demonstrate up to 10x speedup in the unpack throughput of real applications, demonstrating that non-contiguous memory transfers are a first-class candidate for network acceleration.

Figures

Figures reproduced from arXiv: 1908.08590 by the authors.

Figure 1
Figure 1. sPIN NIC Model 2.1.2 NIC Model [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. shows the latency of a one-byte put operation (i.e., from when the data leaves the initiator to when it reaches the host mem￾ory). The data is collected from the simulation environment of Sec. 5. With sPIN, the latency is increased by ∼ 24%, that is the overhead for copying the packet to the NIC memory, scheduling the packet handler, and let it issue a DMA write command. While the latency depends on the complexity o… view at source ↗
Figure 3
Figure 3. NAS LU data layout and communication. Accelerating Non-Contiguous Memory Transfers (NCMT) is a com￾mon problem of HPC codes (e.g., the NAS LU benchmark exists since 1993), and (some) support for non-contiguous communica￾tions is present in all major HPC programming languages. When evaluating non-contiguous memory transfer support, an important consideration to make is the compactness of the resulting type map: Every… view at source ↗
Figures from the paper (15 more)
Figure 4
Figure 4. Figure 4: Network-accelerated DDT processing strategies. [PITH_FULL_IMAGE:figures/full_fig_p004_4.png]
Figure 5
Figure 5. Figure 5: MPITypes dataloops for an index of vectors [PITH_FULL_IMAGE:figures/full_fig_p005_5.png]
Figure 7
Figure 7. Figure 7: Packets scheduling in RW-CP (∆r = 2 · k). How do we select the checkpoint interval? While RW-CP opti￾mizes the handler completion time, the employed blocked-RR sched￾uling policy introduces a packet scheduling dependency (i.e., the packets belonging to the same sequenc…
Figure 6
Figure 6. Figure 6: Checkpointing the segment state. Whenever a handler executes on a packet, it selects the closest checkpoint that can be used to process the packet payload, makes a local copy of it, and then starts processing. This solution bounds the handler runtime to O(∆r), but intr…
Figure 8
Figure 8. Figure 8: Unpacking throughput of an MPI_Type_vector as function of the block size. The specialized handler reaches line rate already for 64 B block size (i.e., γ = 32). The throughput of RO-CP is limited by the segment copy, while the catch-up phase of HPU-local shrinks with th…
Figure 9
Figure 9. Figure 9: a) Proposed hardware architecture of the sPIN accelerator. Single-headed arrows indicate half-duplex, and double [PITH_FULL_IMAGE:figures/full_fig_p008_9.png]
Figure 10
Figure 10. Figure 10: DDT processing throughput on ARM and PULP. [PITH_FULL_IMAGE:figures/full_fig_p008_10.png]
Figure 11
Figure 11. Figure 11: RW-CP Instructions per Cycle (IPC) on PULP. The [PITH_FULL_IMAGE:figures/full_fig_p008_11.png]
Figure 12
Figure 12. Figure 12: Payload handlers execution breakdown for differ [PITH_FULL_IMAGE:figures/full_fig_p009_12.png]
Figure 13
Figure 13. Figure 13: From left to right: Receive throughput scalability; [PITH_FULL_IMAGE:figures/full_fig_p010_13.png]
Figure 14
Figure 14. Figure 14: Maximum DMA write requests queue occupancy [PITH_FULL_IMAGE:figures/full_fig_p010_14.png]
Figure 15
Figure 15. Figure 15: DMA write requests queue over time for γ = 16 and different datatype processing strategies [PITH_FULL_IMAGE:figures/full_fig_p010_15.png]
Figure 17
Figure 17. Figure 17: Histogram of the data volumes moved to/from [PITH_FULL_IMAGE:figures/full_fig_p011_17.png]
Figure 18
Figure 18. Figure 18: Number of times a datatype needs to be reused to [PITH_FULL_IMAGE:figures/full_fig_p011_18.png]
Figure 19
Figure 19. Figure 19: FFT2D strong scaling: runtime (continuous) and [PITH_FULL_IMAGE:figures/full_fig_p012_19.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

53 extracted references · 51 canonical work pages

  1. [1]

    T. Shanley. 2003. Infiniband Network Architecture. Addison-Wesley Professional

    work page 2003

  2. [2]

    Mellanox Technologies

    2019. Mellanox Technologies. http://http://www.mellanox.com/. (2019)

    work page 2019

  3. [3]

    Alverson, et al

    B. Alverson, et al . 2012. Cray XC series network. Cray Inc., White Paper WP- Aries01-1112 (2012)

    work page 2012

  4. [4]

    W Barrett, et al

    B. W Barrett, et al. 2018. The Portals 4.2 Network Programming Interface. Sandia National Laboratories, November 2012, Technical Report SAND2012-10087 (2018)

    work page 2018

  5. [5]

    Schneider, et al

    T. Schneider, et al. 2013. Protocols for Fully Offloaded Collective Operations on Accelerated Network Adapters. InParallel Processing (ICPP), 2013 42nd International Conference on. 593–602

    work page 2013

  6. [6]

    Di Girolamo, et al

    S. Di Girolamo, et al. 2016. Exploiting Offload Enabled Network Interfaces. IEEE MICRO 36, 4 (Jul. 2016). 12 Network-Accelerated Non-Contiguous Memory Transfers SC ’19, November 17–22, 2019, Denver, CO, USA

    work page 2016

  7. [7]

    Schneider, R

    T. Schneider, R. Gerstenberger, and T. Hoefler. 2012. Micro-Applications for Communication Data Access Patterns and MPI Datatypes. In Recent Advances in the Message Passing Interface - Proceedings of the 19th European MPI Users’ Group Meeting, EuroMPI 2012, 2012. , Vol. 7490. Springer, 121–131

    work page 2012

  8. [8]

    Schneider, R

    T. Schneider, R. Gerstenberger, and T. Hoefler. 2014. Application-oriented ping- pong benchmarking: how to assess the real communication overheads. Journal of Computing 96, 4 (Apr. 2014), 279–292

    work page 2014

Show all 53 references
  1. [9]

    Hoefler and S

    T. Hoefler and S. Gottlieb. 2010. Parallel Zero-Copy Algorithms for Fast Fourier Transform and Conjugate Gradient using MPI Datatypes. In Recent Advances in the Message Passing Interface (EuroMPI’10) , Vol. LNCS 6305. Springer, 132–141

    2010

  2. [10]

    Gropp, et al

    W. Gropp, et al. 2011. Performance Expectations and Guidelines for MPI De- rived Datatypes. In Recent Advances in the Message Passing Interface (EuroMPI’11) , Vol. 6960. Springer, 150–159

    2011

  3. [11]

    Schneider, F

    T. Schneider, F. Kjolstad, and T. Hoefler. 2013. MPI Datatype Processing using Runtime Compilation. InProceedings of the 20th European MPI Users’ Group Meeting. ACM, 19–24

    2013

  4. [12]

    Santhanaraman, J

    G. Santhanaraman, J. Wu, and D. K Panda. 2004. Zero-copy MPI derived datatype communication over InfiniBand. In European Parallel Virtual Machine/Message Passing Interface Users’ Group Meeting . Springer, 47–56

    2004

  5. [13]

    Wang, et al

    H. Wang, et al. 2011. Optimized non-contiguous MPI datatype communication for GPU clusters: Design, implementation and evaluation with MVAPICH2. In 2011 IEEE International Conference on Cluster Computing . IEEE, 308–316

    2011

  6. [14]

    Hoefler, et al

    T. Hoefler, et al . 2017. sPIN: High-performance streaming Processing in the Network. In Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis (SC17)

    2017

  7. [15]

    F Van der Wijngaart and P

    R. F Van der Wijngaart and P. Wong. 2002. NAS parallel benchmarks version 2.4. (2002)

    2002

  8. [16]

    Nieplocha, et al

    J. Nieplocha, et al. 2006. High performance remote memory access communication: The ARMCI approach. The International Journal of High Performance Computing Applications 20, 2 (2006), 233–253

    2006

  9. [17]

    Chapman, et al

    B. Chapman, et al. 2010. Introducing OpenSHMEM: SHMEM for the PGAS com- munity. In Proceedings of the Fourth Conference on Partitioned Global Address Space Programming Model. ACM, 2

    2010

  10. [18]

    Mellor-Crummey, et al

    J. Mellor-Crummey, et al. 2009. A new vision for Coarray Fortran. In Proceedings of the Third Conference on Partitioned Global Address Space Programing Models . ACM, 5

    2009

  11. [19]

    El-Ghazawi and L

    T. El-Ghazawi and L. Smith. 2006. UPC: unified parallel C. In Proceedings of the 2006 ACM/IEEE conference on Supercomputing . ACM, 27

    2006

  12. [20]

    Message Passing Interface Forum. 2012. MPI: A Message-Passing Interface Stan- dard Version 3.0. (09 2012). Chapter author for Collective Communication, Process Topologies, and One Sided Communications

    2012

  13. [21]

    Gropp, E

    W. Gropp, E. Lusk, and D. Swider. 1999. Improving the performance of MPI derived datatypes. In Proceedings of the Third MPI Developer’s and User’s Conference . MPI Software Technology Press, 25–30

    1999

  14. [22]

    Byna, et al

    S. Byna, et al . 2006. Automatic memory optimizations for improving MPI de- rived datatype performance. In European Parallel Virtual Machine/Message Passing Interface Users’ Group Meeting . Springer, 238–246

    2006

  15. [23]

    Tanabe and H

    N. Tanabe and H. Nakajo. 2008. Introduction to acceleration for MPI derived datatypes using an enhancer of memory and network. In European Parallel Virtual Machine/Message Passing Interface Users’ Group Meeting . Springer, 324–325

    2008

  16. [24]

    J. L. Träff. 2014. Optimal MPI Datatype Normalization for Vector and Index-block Types. In Proceedings of the 21st European MPI Users’ Group Meeting (EuroMPI/ASIA ’14). ACM, New York, NY, USA, Article 33, 6 pages. DOI:http://dx.doi.org/10.1145/ 2642769.2642771

    2014

  17. [25]

    Ross, et al

    R. Ross, et al. 2009. Processing MPI datatypes outside MPI. In European Parallel Virtual Machine/Message Passing Interface Users’ Group Meeting . Springer, 42–53

    2009

  18. [26]

    R. Ross, N. Miller, and W. D Gropp. 2003. Implementing fast and reusable datatype processing. In European Parallel Virtual Machine/Message Passing Interface Users’ Group Meeting. Springer, 404–413

    2003

  19. [27]

    Kurth, et al

    A. Kurth, et al . 2017. HERO: Heterogeneous embedded research platform for exploring RISC-V manycore accelerators on FPGA.arXiv preprint arXiv:1712.06497 (2017)

    2017 arXiv

  20. [28]

    Rossi, et al

    D. Rossi, et al. 2017. Energy-Efficient Near-Threshold Parallel Computing: The PULPv2 Cluster. IEEE Micro 37, 5 (Sep. 2017), 20–31

    2017

  21. [29]

    Gautschi, et al

    M. Gautschi, et al. 2017. Near-Threshold RISC-V Core With DSP Extensions for Scalable IoT Endpoint Devices. IEEE Transactions on Very Large Scale Integration (VLSI) Systems 25, 10 (Oct 2017), 2700–2713. DOI:http://dx.doi.org/10.1109/TVLSI. 2017.2654506

    2017

  22. [30]

    Mellanox Technologies. 2019. Mellanox BlueField SmartNIC. http://www.mellanox. com/related-docs/prod_adapter_cards/PB_BlueField_Smart_NIC.pdf. (2019). On- line; accessed 05. April 2019

    2019

  23. [31]

    H. T. Mair, et al . 2016. 4.3 A 20nm 2.5GHz ultra-low-power tri-cluster CPU subsystem with adaptive power allocation for optimal mobile SoC performance. In IEEE International Solid-State Circuits Conference (ISSCC) . 76–77

    2016

  24. [32]

    Pyo, et al

    J. Pyo, et al. 2015. 23.1 20nm high-K metal-gate heterogeneous 64b quad-core CPUs and hexa-core GPU for high-performance and energy-efficient mobile application processor. In 2015 IEEE International Solid-State Circuits Conference - (ISSCC) Digest of Technical Papers. 1–3

    2015

  25. [33]

    Sohan, et al

    R. Sohan, et al. 2010. Characterizing 10 Gbps network interface energy consump- tion. In IEEE Local Computer Network Conference . 268–271

    2010

  26. [34]

    L Janssen, et al

    C. L Janssen, et al. 2010. A simulator for large-scale parallel computer architectures. International Journal of Distributed Systems and Technologies (IJDST) 1, 2 (2010), 57–73

    2010

  27. [35]

    Nathan Binkert, et al . 2011. The gem5 simulator. ACM SIGARCH Computer Architecture News 39, 2 (2011), 1–7

    2011

  28. [36]

    A Endo, D

    F. A Endo, D. Couroussé, and H. Charles. 2014. Micro-architectural simulation of in-order and out-of-order arm microprocessors with gem5. In 2014 International Conference on Embedded Computer Systems: Architectures, Modeling, and Simulation (SAMOS XIV). IEEE, 266–273

    2014

  29. [37]

    Tousi and C

    A. Tousi and C. Zhu. 2017. Arm Research Starter Kit: System Modeling using gem5. (2017)

    2017

  30. [38]

    Hoefler, T

    T. Hoefler, T. Schneider, and A. Lumsdaine. 2010. LogGOPSim - Simulating Large- Scale Applications in the LogGOPS Model. In Proceedings of the 19th ACM Interna- tional Symposium on High Performance Distributed Computing . ACM, 597–604

    2010

  31. [39]

    Lawrence Livermore National Laboratory. 2018. Comb is a communication per- formance benchmarking tool. (2018). https://github.com/LLNL/Comb

    2018

  32. [40]

    Plimpton

    S. Plimpton. 1995. Fast Parallel Algorithms for Short-range Molecular Dynamics. J. Comput. Phys. 117, 1 (March 1995), 1–19. DOI:http://dx.doi.org/10.1006/jcph. 1995.1039

    1995

  33. [41]

    Bernard, et al

    C. Bernard, et al. 1991. Studying quarks and gluons on MIMD parallel computers. The International Journal of Supercomputing Applications 5, 4 (1991), 61–70

    1991

  34. [42]

    Carrington, et al

    L. Carrington, et al. 2008. High-frequency Simulations of Global Seismic Wave Propagation Using SPECFEM3D GLOBE on 62K Processors. In Proceedings of the 2008 ACM/IEEE Conference on Supercomputing (SC ’08) . IEEE Press, Piscataway, NJ, USA, Article 60, 11 pages. http://dl.acm.o...

    2008

  35. [43]

    B Sjogreen. 2018. SW4 final report for iCOE. Technical Report. Lawrence Livermore National Lab.(LLNL), Livermore, CA (United States)

    2018

  36. [44]

    W. C. Skamarock and J. B. Klemp. 2008. A Time-split Nonhydrostatic Atmospheric Model for Weather Research and Forecasting Applications. J. Comput. Phys. 227, 7 (March 2008), 3465–3485. DOI:http://dx.doi.org/10.1016/j.jcp.2007.01.037

    2008 doi

  37. [45]

    Neugebauer, et al

    R. Neugebauer, et al. 2018. Understanding PCIe performance for end host net- working. In Proceedings of the 2018 Conference of the ACM Special Interest Group on Data Communication. ACM, 327–341

    2018

  38. [46]

    Martinasso, et al

    M. Martinasso, et al . 2016. A PCIe Congestion-Aware Performance Model for Densely Populated Accelerator Servers. In Proceedings of the International Confer- ence for High Performance Computing, Networking, Storage and Analysis (SC16) . IEEE Press, 63:1–63:11

    2016

  39. [47]

    Hoefler, C

    T. Hoefler, C. Siebert, and A. Lumsdaine. 2009. Group Operation Assembly Lan- guage - A Flexible Way to Express Collective Communication, In ICPP-2009 - The 38th International Conference on Parallel Processing. (Sep. 2009)

    2009

  40. [48]

    J. L. Träff, et al . 1999. Flattening on the Fly: efficient handling of MPI derived datatypes. In Recent Advances in Parallel Virtual Machine and Message Passing Interface, Jack Dongarra, Emilio Luque, and Tomàs Margalef (Eds.). Springer Berlin Heidelberg, Berlin, Heidelberg, 109–116

    1999

  41. [49]

    Prabhu and W

    T. Prabhu and W. Gropp. 2015. DAME: A runtime-compiled engine for derived datatypes. In Proceedings of the 22nd European MPI Users’ Group Meeting . ACM, 4

    2015

  42. [50]

    Schneider, R

    T. Schneider, R. Gerstenberger, and T. Hoefler. 2013. Compiler optimizations for non-contiguous remote data movement. In International Workshop on Languages and Compilers for Parallel Computing . Springer, 307–321

    2013

  43. [51]

    TV Eicken, et al . 1992. Active messages: a mechanism for integrated commu- nication and computation. In [1992] Proceedings the 19th Annual International Symposium on Computer Architecture. IEEE, 256–266

    1992

  44. [52]

    Besta and T

    M. Besta and T. Hoefler. 2015. Accelerating Irregular Computations with Hardware Transactional Memory and Active Messages. In Proceedings of the 24th Symposium on High-Performance Parallel and Distributed Computing (HPDC’15) . ACM, 161– 172

    2015

  45. [53]

    Besta and T

    M. Besta and T. Hoefler. 2015. Active Access: A Mechanism for High-Performance Distributed Data-Centric Computations. In Proceedings of the 29th International Conference on Supercomputing (ICS’15) . ACM, 155–164. 13

    2015

Pith tools

Reviewed August 14, 2026 · model on record in the stance chip above.