Pith. sign in

REVIEW 3 major objections 4 minor 68 references

HiCR, an Abstract Model for Distributed Heterogeneous Programming

T0 review · 3 major / 4 minor · reviewed 2026-08-05 · deepseek-v4-flash

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

Pith's one-line read This paper proposes HiCR, a minimal set of abstract operations that let a distributed heterogeneous application run unchanged on CPUs, GPUs, and NPUs by swapping backend plugins, and argues that the set is semantically complete for any such

desk verdict A genuinely useful runtime-support-layer abstraction, but the paper's headline portability guarantee rests on an under-specified completion semantics that must be pinned down before the claim can be taken as proven. read the letter →

arxiv 2509.01425 v1 pith:PIP4BTOM submitted 2025-09-01 cs.DC

Sergio Miguel Martin , Luca Terracciano , Kiril Dichev , Noah Baumann , Jiashu Lin , Albert-Jan Yzelman This is my paper · ORCID
classification cs.DC
keywords runtimesupportlayerdistributedheterogeneousprogrammingportabilityabstractmodelpluginbackendstopologydiscoverycommunicationmanagementcompute
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

HiCR is a proposed semantic layer between applications and the stack of device drivers, vendor APIs, and communication libraries. The paper claims that just a few abstract operations — discover topology, allocate memory, copy data with memcpy, launch execution states, and manage instances — are enough to express any distributed heterogeneous program. If that is true, an application written once against HiCR can run on a CPU, a GPU, an NPU, or a cluster of mixed nodes by swapping in a backend plugin, with no source-code changes and the same intended results. The authors supply an open-source implementation and demonstrate it on four tests: a ping-pong benchmark, MNIST inference, fine-grained tasking, and a Jacobi stencil solver. The selling point is forward portability: new hardware needs a new backend, not a rewritten application.

What carries the argument

The model itself is the key object: a minimal set of abstract operations mediated by five managers. The Instance Manager discovers or creates instances; the Topology Manager exposes devices, memory spaces, and compute resources; the Memory Manager creates and registers local memory slots; the Communication Manager exchanges global memory slots and performs the only three allowed memcpy directions; the Compute Manager creates processing units, execution units, and execution states. The plugin- or backend-based implementation carries the portability argument: each backend translates a subset of these abstract classes into a specific technology's calls, and selecting a different backend changes

What would settle it

Implement a distributed application that must perform a Global-to-Global data motion (a device-to-device copy initiated by a third instance between two remote instances) and attempt to express it with the HiCR API; if the API cannot express it without staging through a local slot, the claim of universal expressiveness is falsified. Alternatively, take a new accelerator or interconnect for which only a backend is written and run an existing HiCR application; any semantic divergence in its result would refute the 'intended result' guarantee.

Watch

Extended reading notes

Core claim

The central claim is that the semantics of any distributed heterogeneous application can be captured by a small, named set of abstract operations, and that those operations are sufficient because they are realised by interchangeable backends. The model groups components into managers (Instance, Topology, Memory, Communication, Compute), stateless objects (topology, instance templates, execution units) and stateful objects (instances, memory slots, processing units, execution states). Communication is deliberately restricted: all data motion uses a memcpy with only Local-to-Local, Local-to-Global, and Global-to-Local directions; Global-to-Global copies are disallowed because no instance orche

Load-bearing premise

The paper asserts, without formal proof, that the operation set it defines—topology discovery, local memory slots, three-direction memcpy, execution states, and instance management—is semantically complete for every distributed heterogeneous application; if some application needs an operation outside this set, the portability claim collapses.

Editorial extensions

If this is right

  • Applications written only against the abstract HiCR API can be ported to a new architecture by providing a new backend plugin, with no changes to application source.
  • Any newly written backend immediately benefits all HiCR-based programs, multiplying the value of each new plugin.
  • Because HiCR prescribes no programming model, a tasking runtime, a BSP library, or a domain-specific library can each sit on top of the same Runtime Support Layer.
  • The same source code can run on CPU, GPU, and NPU while preserving overall results, as shown by the MNIST test where accuracy matched across backends.
  • Communication performance remains backend-dependent (e.g., the LPF backend delivers roughly 70x better ping-pong goodput than the MPI backend for small messages), so programmers must still benchmark backend choices.

Reading between the lines

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

  • If the completeness claim is taken at face value, the three-direction memcpy restriction is a testable boundary: any real application needing Global-to-Global or shared-device cross-instance communication would force the model to grow a new operation, exposing the lack of formal proof.
  • Backend selection is performance-critical; the model guarantees semantic portability but not performance portability, so the natural next step is a benchmark suite that quantifies backend overhead to guide users.
  • A practical stress test would be to take a large existing HPC or ML application and port it to HiCR; if semantics break because communication patterns exceed the three allowed directions, the minimality claim would be disproven.
  • The same abstraction style could be extended to other runtime concerns the paper lists as future work—file management, fault tolerance, and security isolation—if the model grows new manager types rather than complicating the existing ones.
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 / 4 minor

Summary. The paper introduces HiCR, an abstract model intended to serve as a "Runtime Support Layer" between applications/runtime systems and the low-level technologies of distributed heterogeneous hardware. HiCR defines a small set of components and operations: instance management, topology discovery, memory management via local/global memory slots, communication via asynchronous memcpy plus a fence operation, and compute via processing units, execution units, and execution states. The paper claims that any HiCR-based program reaches its intended result on any system, provided appropriate backend plugins are selected. The authors describe an open-source C++ implementation with backends for MPI, LPF, HWLoc, OpenCL, ACL, Pthreads, Boost, and nOS-V, plus frontends for channels, data objects, RPC, and tasking. Four experiments are reported: an MPI vs. LPF ping-pong benchmark, MNIST inference on CPU/GPU/NPU, a fine-grained Fibonacci task benchmark, and a coarse-grained Jacobi solver with up to 4 nodes.

Significance. If the semantic claims were made precise, HiCR would be a useful contribution to portable distributed heterogeneous programming. The paper has real strengths: the implementation is open source, the experimental setup is reproducible, and the test cases cover different backend families (CPU threads, OpenCL GPU, NPU, Infiniband/MPI). The ping-pong comparison and the tasking benchmarks are legitimate measurements, and the paper is generally clear about what was run. However, the paper's central claim is the semantic portability of the abstract model, and that claim rests on a definition of completion/ordering that is not given. The empirical tests are not sufficient to establish the universal statement made in §1 and §3. The contribution is therefore promising but needs either a rigorously stated operational/memory semantics or a careful restriction of the portability claim.

major comments (3)
  1. [§3.1.4, §1] The portability claim ('any HiCR-based code will reach its intended result', §1) presupposes a backend-independent semantics for asynchronous operations. In §3.1.4, memcpy is asynchronous and fence 'suspend[s] execution until the expected number of incoming and outgoing data transfers have been completed,' but 'completed' is not defined: origin completion (e.g., MPI_Win_flush) and remote visibility (e.g., MPI_Win_fence) are different notions for one-sided communication. The model also does not define ordering between async execution states (§3.1.5) and memcpy operations on the same memory slot. Without these rules, two backends can legitimately implement the same API with different synchronization strengths and produce different observable outcomes. The test cases in §5 do not exercise such race-prone interleavings. This is the load-bearing gap: please add a memory model or explicitly we
  2. [§3, §3.1.4, §6] The opening of §3 states that HiCR comprises 'a minimal set of components and operations to describe the semantics of any code running on any distributed computing system.' This completeness/minimality claim is not supported. Global-to-Global memcpy is deliberately disallowed in §3.1.4, and §6 lists missing features: interconnect-topology discovery, distributed file management, fault tolerance, multi-user job allocation, security isolation. If the intended claim is limited to programs expressible in HiCR, that scope must be stated explicitly; otherwise the model cannot be said to cover 'any code' on 'any' distributed system. Please either prove/formalize the expressible fragment or revise the claim to be about HiCR-expressible programs.
  3. [§5, Table 2] The experiments demonstrate that four specific applications run with several backends and yield consistent (though not bit-identical) results. This is useful evidence, but it does not substitute for the semantic guarantee promised in §1. In particular, no experiment exercises overlapping one-sided transfers and asynchronous execution states in a way that would distinguish different completion/ordering semantics. The accuracy results in Table 2 are consistent, yet the img-0 scores differ in low-order digits as the text acknowledges; that is acceptable, but it highlights that 'equal results' in the paper is empirical similarity rather than a formal semantic equivalence. If the model itself is the contribution, the missing piece is a rigorous operational semantics, not additional benchmarks.
minor comments (4)
  1. [§4] The sentence 'An up-to-date list of existing frontends can be found in HiCR’s' is incomplete; the expected pointer or URL is missing.
  2. [§5.1] In the goodput discussion, 'larger messages (> 109 bytes)' should presumably read '>10^9 bytes'; the superscript appears to have been lost.
  3. [§3.1.4] The phrase 'The latter involve transfers between instances...' refers to two distinct directions (Local-to-Global and Global-to-Local); the wording is confusing and should be rephrased.
  4. [Table 1] The table lists an X for OpenCL under Instance, but §4.2 does not describe instance management for OpenCL; please clarify what this entry means or correct the table.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: HiCR's portability claim rests on external validation and design, not on self-referential derivation.

full rationale

The paper's central claim is that abstract HiCR operations allow the same application code to run across heterogeneous and distributed systems by switching backends. This is a design claim, not a derived numerical prediction. The experimental sections compare the same HiCR code over external technologies (MPI, OpenCL, ACL, Pthreads, HWLoc, nOS-V, Boost) and third-party hardware, and the results are measured rather than fitted. No parameter is fitted to a subset of data and then renamed as a prediction; no equation is shown to equal its input by construction. The author-owned components that appear — LPF (reference [57]), the LPF/noc_extension branch [36], and the TaskR scheduler — are used as backends or test harnesses, not as premises that force the portability conclusion. The portability assertion would stand or fall on whether the abstract API semantics are well-defined and correctly implemented, independent of these self-references. The paper's broader claim that HiCR can describe 'any code running on any distributed computing system' is an unproven completeness assertion, and the model's asynchronous completion semantics are under-specified, but these are soundness gaps rather than circularity. There is no self-definitional equivalence, fitted-input mislabeling, or load-bearing self-citation chain.

Assumptions & free parameters 0 free parameters · 4 assumptions · 2 invented entities

The HiCR model is built on explicit design choices about what a distributed heterogeneous runtime must express. These are stated as assumptions in Section 3: node/device structure, instance disjointness, communication directions, and execution state lifecycle. There are no fitted numeric parameters; the experimental claims are direct measurements.

assumptions (4)
  • domain assumption A distributed system consists of interconnected nodes, each with processing units and local memory.
    Section 3, base hardware model.
  • domain assumption No two running HiCR instances may share access to the same device.
    Section 3.1.1, enforces disjointness and simplifies memory/communication semantics.
  • domain assumption All communication is mediated by a communication manager, and Global-to-Global transfers are not permitted.
    Section 3.1.4, design choice to avoid remote-orchestrated transfers.
  • domain assumption An execution state is single-use and cannot be restarted after completion.
    Section 3.1.5, lifecycle constraint.
invented entities (2)
  • Runtime Support Layer independent evidence
    purpose: A new software abstraction level between applications/runtime systems and low-level system libraries.
    Implemented as the open-source HiCR library; the paper's experiments exercise the layer, giving an observable artifact.
  • HiCR abstract components (Instance, Topology, Memory Slot, Global Memory Slot, Execution Unit, Execution State) independent evidence
    purpose: Minimal semantic building blocks for topology discovery, memory management, communication, and compute execution.
    Concrete C++ abstract classes with multiple backend implementations; code is publicly available and used in the benchmarks.

how reviews work

0 comments
Cite this review

Pith. "Pith review of HiCR, an Abstract Model for Distributed Heterogeneous Programming." pith.science (2026). https://pith.science/paper/PIP4BTOM

@misc{pith2026250901425,
  author       = {Pith},
  title        = {Pith review of: HiCR, an Abstract Model for Distributed Heterogeneous Programming},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/PIP4BTOM}},
  note         = {Machine review of arXiv:2509.01425}
}
read the original abstract

We present HiCR, a model to represent the semantics of distributed heterogeneous applications and runtime systems. The model describes a minimal set of abstract operations to enable hardware topology discovery, kernel execution, memory management, communication, and instance management, without prescribing any implementation decisions. The goal of the model is to enable execution in current and future systems without the need for significant refactoring, while also being able to serve any governing parallel programming paradigm. In terms of software abstraction, HiCR is naturally located between distributed heterogeneous systems and runtime systems. We coin the phrase \emph{Runtime Support Layer} for this level of abstraction. We explain how the model's components and operations are realized by a plugin-based approach that takes care of device-specific implementation details, and present examples of HiCR-based applications that operate equally on a diversity of platforms.

Figures

Figures reproduced from arXiv: 2509.01425 by the authors.

Figure 1
Figure 1. A layered view of runtime support for user applications. Any of the layers may invoke functionality of one or more of the layers below it to support runtime operations. Given the complexity of modern computing systems, ap￾plications typically rely on a multitude of third-party and sys￾tem libraries [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Diagram showing the components of the HiCR model and the available operations between them. The model is divided in three component groups: Managers, components whose operations represent an application’s semantic building blocks; Stateless, components that represent static information, and Stateful, components with an internal state that mutates over time. for applications that deploy on cloud infrastructures. In t… view at source ↗
Figure 3
Figure 3. The current implementation of the HiCR model. Its components and operations are exposed in a Core API, which serves as interface between the user-level applications and the underlying system libraries. The core API is distributed together with a set of built-in backends, plugins containing the implementation of subsets of model’s components for several popular libraries, and frontends, HiCR-based libraries providing… view at source ↗
Figures from the paper (7 more)
Figure 4
Figure 4. Figure 4: shows an example of backend instantiation, prior to running a HiCR application. The example starts by initializ￾ing the MPI library and passing an MPI communicator object to the MPI instance manager constructor (Line 3). Then, it in￾stantiates the HWLoc topology and me…
Figure 5
Figure 5. Figure 5: This example copies a message along all the memory spaces detected by the topology manager. These memory spaces may belong to one or multiple different physical devices on a given node. 1 // Initializing execution in all compute resources 2 std :: vector < HiCR :: Proc…
Figure 6
Figure 6. Figure 6: This example runs a given execution unit on all of the available compute resources for parallel execution. 4.1.2 Example: Parallel Execution [PITH_FULL_IMAGE:figures/full_fig_p007_6.png]
Figure 8
Figure 8. Figure 8: Observed goodput for ping-pong benchmarks using the LPF (top series) and MPI (bottom series) backends over multiple message sizes. LPF relies on IBverbs directly while MPI relies on OpenMPI RMA primitives. 5.2 Test Case 2: Heterogeneous Inference This test case impleme…
Figure 9
Figure 9. Figure 9: Execution timelines for the Fibonacci example that executes 150 049 tasks using 8 cores. Each horizontal line represents the timeline of a CPU core, with solid traces indicating meaningful work and empty spaces indicating scheduling overhead [PITH_FULL_IMAGE:figures/f…
Figure 10
Figure 10. Figure 10: Execution timelines for the Jacobi example running 500 iterations using 1 × 2 × 22 = 44 threads of a Intel Xeon Gold 6238T system with hyperthreading enabled (but here unused). greatly reduce overheads compared to delegating scheduling decisions to the OS. 5.4 Test Ca…
Figure 11
Figure 11. Figure 11: Strong and weak scaling of the Jacobi example using up to 4 nodes of dual-socket Intel Xeon Gold 6238T CPUs. Each node has 22 cores per socket with hyperthreading enabled (but here unused). The benefits of nOS-V may hence be exploited without no￾ticeable performance i…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

68 extracted references · 66 canonical work pages

  1. [1]

    Partitioned Global Address Space (PGAS) Languages

    2011. Partitioned Global Address Space (PGAS) Languages. In Ency- clopedia of Parallel Computing , David A. Padua (Ed.). Springer, 1465

    work page 2011

  2. [2]

    Jimmy Aguilar Mena, Omar Shaaban, Vicenç Beltran, Paul Carpenter, Eduard Ayguade, and Jesus Labarta Mancho. 2022. OmpSs-2@ Clus- ter: Distributed memory execution of nested OpenMP-style tasks. In European Conference on Parallel Processing . Springer, 319–334

    work page 2022

  3. [3]

    David Álvarez, Kevin Sala, and Vicenç Beltran. 2024. nOS-V: Co- Executing HPC Applications Using System-Wide Task Scheduling. In IEEE International Parallel and Distributed Processing Symposium . IEEE, 312–324

    work page 2024

  4. [4]

    https://rocm.docs.amd.com/projects/HIP/en/latest/

    AMD Heterogeneous-computing Interface for Portability (HIP) 2025- 03-24. . https://rocm.docs.amd.com/projects/HIP/en/latest/

    work page 2025

  5. [5]

    Cédric Augonnet, Olivier Aumage, Nathalie Furmento, Raymond Namyst, and Samuel Thibault. 2012. StarPU-MPI: Task Programming over Clusters of Machines Enhanced with Accelerators. In Recent Ad- vances in the Message Passing Interface - European MPI Users’ Group Meeting (Lecture Notes in Computer Science, Vol. 7490) , Jesper Lars- son Träff, Siegfried Benkne...

    work page 2012

  6. [6]

    Cédric Augonnet, Samuel Thibault, Raymond Namyst, and Pierre- André Wacrenier. 2009. StarPU: A Unified Platform for Task Schedul- ing on Heterogeneous Multicore Architectures. In Euro-Par Parallel Processing (Lecture Notes in Computer Science, Vol. 5704) , Henk J. Sips, Dick H. J. Epema, and Hai-Xiang Lin (Eds.). Springer, 863–874

    work page 2009

  7. [7]

    Badia, Francisco D

    Eduard Ayguadé, Rosa M. Badia, Francisco D. Igual, Jesús Labarta, Rafael Mayo, and Enrique S. Quintana-Ortí. 2009. An Extension of the StarSs Programming Model for Platforms with Multiple GPUs. InEuro- Par Parallel Processing (Lecture Notes in Computer Science, Vol. 5704) , Henk J. Sips, Dick H. J. Epema, and Hai-Xiang Lin (Eds.). Springer, 851–862

    work page 2009

  8. [8]

    David Beckingsale, Thomas R. W. Scogland, Jason Burmark, Rich Hor- nung, Holger Jones, William Killian, Adam J. Kunen, Olga Pearce, Peter Robinson, and Brian S. Ryujin. 2019. RAJA: Portable Performance for Large-Scale Scientific Applications. In IEEE/ACM International Work- shop on Performance, Portability and Productivity in HPC . IEEE, 71–81

    work page 2019

Show all 68 references
  1. [9]

    Roberto Belli and Torsten Hoefler. 2015. Notified Access: Extending Remote Memory Access Programming Models for Producer-Consumer Synchronization. In 2015 IEEE International Parallel and Distributed 11 Processing Symposium. 871–881. https://doi.org/10.1109/IPDPS.2015.30

    2015 doi

  2. [10]

    https://www.boost.org/doc/libs/1_84_0/ libs/context/doc/html/index.html

    Boost Context 2025-03-24. . https://www.boost.org/doc/libs/1_84_0/ libs/context/doc/html/index.html

    2025

  3. [11]

    George Bosilca, Aurelien Bouteiller, Anthony Danalis, Mathieu Faverge, Thomas Hérault, and Jack J Dongarra. 2013. Parsec: Ex- ploiting heterogeneity to enhance scalability. Computing in Science & Engineering 15, 6 (2013), 36–45

    2013

  4. [12]

    https://learn.microsoft.com/en-us/cpp/parallel/amp/cpp-amp- overview?view=msvc-170

    C++ Accelerated Massive Parallelism (C++ AMP) 2025-03-24. . https://learn.microsoft.com/en-us/cpp/parallel/amp/cpp-amp- overview?view=msvc-170

    2025

  5. [13]

    Chamberlain, and Hans P

    David Callahan, Bradford L. Chamberlain, and Hans P. Zima. 2004. The Cascade High Productivity Language. In International Workshop on High-Level Programming Models and Supportive Environments . IEEE Computer Society, 52–60

    2004

  6. [14]

    Paul Cardosi and Bérenger Bramas. 2023. Specx: a C++ task-based runtime system for heterogeneous distributed architectures. CoRR abs/2308.15964 (2023)

    2023 arXiv

  7. [15]

    Saraswat, Christopher Donawa, Allan Kielstra, Kemal Ebcioglu, Christoph von Praun, and Vivek Sarkar

    Philippe Charles, Christian Grothoff, Vijay A. Saraswat, Christopher Donawa, Allan Kielstra, Kemal Ebcioglu, Christoph von Praun, and Vivek Sarkar. 2005. X10: an object-oriented approach to non-uniform cluster computing. In Proceedings of the Annual ACM SIGPLAN Confer- ence on...

    2005

  8. [16]

    Qiong Chen, Jianmin Qian, Yulin Che, Ziqi Lin, Jianfeng Wang, Jie Zhou, Licheng Song, Yi Liang, Jie Wu, Wei Zheng, Wei Liu, Linfeng Li, Fangming Liu, and Kun Tan. 2024. YuanRong: A Production General- purpose Serverless System for Distributed Applications in the Cloud. In Proc...

    2024

  9. [17]

    https://www.intel.com/content/www/ us/en/developer/tools/oneapi/data-parallel-c-plus-plus.html

    Data Parallel C++ 2025-03-24. . https://www.intel.com/content/www/ us/en/developer/tools/oneapi/data-parallel-c-plus-plus.html

    2025

  10. [18]

    Jeffrey Dean and Sanjay Ghemawat. 2008. MapReduce: simplified data processing on large clusters. Commun. ACM 51, 1 (2008), 107–113

    2008

  11. [19]

    Jirí Dokulil and Siegfried Benkner. 2022. The OCR-Vx experience: lessons learned from designing and implementing a task-based runtime system. J. Supercomput. 78, 10 (2022), 12344–12379

    2022

  12. [20]

    Jiri Dokulil, Martin Sandrieser, and Siegfried Benkner. 2016. Implement- ing the open community runtime for shared-memory and distributed- memory systems. In 2016 24th Euromicro International Conference on Parallel, Distributed, and Network-Based Processing (PDP) . IEEE, 364– 368

    2016

  13. [21]

    Romain Dolbeau, Stéphane Bihan, and François Bodin. 2007. HMPP: A hybrid multi-core parallel programming environment. In Workshop on general purpose processing on graphics processing units, Vol. 28. Citeseer

    2007

  14. [22]

    Carter Edwards and Daniel Sunderland

    H. Carter Edwards and Daniel Sunderland. 2012. Kokkos Array performance-portable manycore programming model. In Proceedings of the International Workshop on Programming Models and Applications for Multicores and Manycores, Minyi Guo and Zhiyi Huang (Eds.). ACM, 1–10

    2012

  15. [23]

    El-Ghazawi and Lauren Smith

    Tarek A. El-Ghazawi and Lauren Smith. 2006. UPC - UPC: unified par- allel C. In Proceedings of the ACM/IEEE Conference on High Performance Networking and Computing. ACM Press, 27

    2006

  16. [24]

    Badia, and Eduard Ayguadé Parra

    Vinoth Krishnan Elangovan, Rosa M. Badia, and Eduard Ayguadé Parra. 2012. OmpSs-OpenCL Programming Model for Heterogeneous Systems. In Languages and Compilers for Parallel Computing (Lecture Notes in Computer Science, Vol. 7760) , Hironori Kasahara and Keiji Kimura (Eds.). Spr...

    2012

  17. [25]

    Johan Enmyren and Christoph W Kessler. 2010. SkePU: a multi- backend skeleton programming library for multi-GPU systems. In Proceedings of the fourth international workshop on High-level parallel programming and applications. 5–14

    2010

  18. [26]

    Thierry Gautier, João V. F. Lima, Nicolas Maillard, and Bruno Raffin

  19. [27]

    Vetter, Giulio Picierro, and Marco Cesati

    Roberto Gioiosa, Burcu Ozcelik Mutlu, Seyong Lee, Jeffrey S. Vetter, Giulio Picierro, and Marco Cesati. 2020. The Minos Computing Library: efficient parallel programming for extremely heterogeneous systems. In Annual Workshop on General Purpose Processing using Graphics Proces...

    2020

  20. [28]

    https://e.huawei.com/en/ products/computing/ascend

    Huawei Ascend Computing 2025-03-24. . https://e.huawei.com/en/ products/computing/ascend

    2025

  21. [29]

    https: //www.hiascend.com/document/detail/zh/canncommercial/700/ overview/index.html

    Huawei Ascend Computing Language 2025-03-24. . https: //www.hiascend.com/document/detail/zh/canncommercial/700/ overview/index.html

    2025

  22. [30]

    https://docs.nvidia.com/ networking/display/rdmaawareprogrammingv17/vpi+verbs+api

    Infiniband Verbs API 2025-03-24. . https://docs.nvidia.com/ networking/display/rdmaawareprogrammingv17/vpi+verbs+api

    2025

  23. [31]

    https://network.nvidia.com/ pdf/whitepapers/IB_Intro_WP_190.pdf

    Introduction to Infiniband 2025-03-24. . https://network.nvidia.com/ pdf/whitepapers/IB_Intro_WP_190.pdf

    2025

  24. [32]

    Herbert Jordan, Philipp Gschwandtner, Peter Thoman, Peter Zangerl, Alexander Hirsch, Thomas Fahringer, and Dietmar Fey. 2020. The allscale framework architecture. Parallel Comput. 99 (2020), 102648

    2020

  25. [33]

    Hartmut Kaiser, Thomas Heller, Bryce Adelstein-Lelbach, Adrian Serio, and Dietmar Fey. 2014. HPX: A Task Based Programming Model in a Global Address Space. In Proceedings of the International Conference on Partitioned Global Address Space Programming Models, Allen D. Malony an...

    2014

  26. [34]

    Jungwon Kim, Seyong Lee, Beau Johnston, and Jeffrey S. Vetter. 2021. IRIS: A Portable Runtime System Exploiting Multiple Heterogeneous Programming Systems. In IEEE High Performance Extreme Computing Conference. IEEE, 1–8

    2021

  27. [35]

    Seyong Lee and Jeffrey S. Vetter. 2014. OpenARC: open accelerator research compiler for directive-based, efficient heterogeneous comput- ing. In The International Symposium on High-Performance Parallel and Distributed Computing, Beth Plale, Matei Ripeanu, Franck Cappello, and ...

    2014

  28. [36]

    Light Parallel Foundations - Source Code, Branch: noc_extension [n. d.]. https://github.com/Algebraic-Programming/LPF/tree/noc_ extension/. (2025-03-24)

    2025

  29. [37]

    Grzegorz Malewicz, Matthew H Austern, Aart JC Bik, James C Dehnert, Ilan Horn, Naty Leiser, and Grzegorz Czajkowski. 2010. Pregel: a system for large-scale graph processing. In Proceedings of the 2010 ACM SIGMOD International Conference on Management of data . 135– 146

    2010

  30. [38]

    Mattson, Romain Cledat, Vincent Cavé, Vivek Sarkar, Zoran Budimlic, Sanjay Chatterjee, Joshua B

    Timothy G. Mattson, Romain Cledat, Vincent Cavé, Vivek Sarkar, Zoran Budimlic, Sanjay Chatterjee, Joshua B. Fryman, Ivan Ganev, Robin Knauerhase, Min Lee, Benoît Meister, Brian Nickerson, Nick Pepperling, Bala Seshasayee, Sagnak Tasirlar, Justin Teller, and Nick Vrvilo. 2016. ...

    2016

  31. [39]

    https://www.kaggle.com/datasets/ hojjatk/mnist-dataset

    MNIST Dataset 2025-03-24. . https://www.kaggle.com/datasets/ hojjatk/mnist-dataset

    2025

  32. [40]

    https://www.mpi-forum.org/

    MPI Forum 2025-03-24. . https://www.mpi-forum.org/

    2025

  33. [41]

    https://developer.nvidia.com/cuda-toolkit

    Nvidia CUDA 2025-03-24. . https://developer.nvidia.com/cuda-toolkit

    2025

  34. [42]

    https://developer.nvidia.com/thrust

    Nvidia Thrust 2025-03-24. . https://developer.nvidia.com/thrust

    2025

  35. [43]

    https://ovni.readthedocs.io/

    Obtuse but Versatile Nanoscale Instrumentation (ovni) 2025-03-19. . https://ovni.readthedocs.io/

    2025

  36. [44]

    https://ompcluster.gitlab.io/

    OmpCluster 2025-03-24. . https://ompcluster.gitlab.io/

    2025

  37. [45]

    https://pm.bsc.es/ompss-2

    OmpSs-2 2025-03-24. . https://pm.bsc.es/ompss-2

    2025

  38. [46]

    https://www.openacc

    Open Accelerators (OpenACC) 2025-03-24. . https://www.openacc. org/sites/default/files/inline-files/OpenACC_2_0_specification.pdf

    2025

  39. [47]

    https://registry

    Open Computing Language (OpenCL) 2025-03-24. . https://registry. khronos.org/OpenCL/specs/3.0-unified/html/OpenCL_API.html

    2025

  40. [48]

    https://www.openmp

    Open Multi-Processing (OpenMP) 2025-03-24. . https://www.openmp. org/specifications/

    2025

  41. [49]

    https://www

    OpenBLAS: An optimized BLAS library 2025-03-24. . https://www. openmathlib.org/OpenBLAS/ 12

    2025

  42. [50]

    https: //tools.bsc.es/paraver

    Paraver: a flexible performance analysis tool 2025-03-19. . https: //tools.bsc.es/paraver

    2025

  43. [51]

    https://www.open- mpi.org/projects/hwloc

    Portable Hardware Locality (hwloc) 2025-03-24. . https://www.open- mpi.org/projects/hwloc

    2025

  44. [52]

    https://man7.org/linux/man-pages/ man7/pthreads.7.html

    POSIX Threads 2025-03-24. . https://man7.org/linux/man-pages/ man7/pthreads.7.html

    2025

  45. [53]

    Ari Rasch, Martin Wrodarczyk, Richard Schulze, and Sergei Gor- latch. 2018. OCAL: An Abstraction for Host-Code Programming with OpenCL and CUDA. In IEEE International Conference on Parallel and Distributed Systems. IEEE, 408–416

    2018

  46. [54]

    Robson, Ronak Buch, and Laxmikant V

    Michael P. Robson, Ronak Buch, and Laxmikant V. Kalé. 2016. Run- time Coordinated Heterogeneous Tasks in Charm++. In International Workshop on Extreme Scale Programming Models and Middleware . IEEE Computer Society, 40–43

    2016

  47. [55]

    Marc Sergent, Célia Tassadit Aitkaci, Pierre Lemarinier, and Guillaume Papauré. 2019. Efficient notifications for MPI one-sided applications. In Proceedings of the 26th European MPI Users’ Group Meeting (Zürich, Switzerland) (EuroMPI ’19). Association for Computing Machinery, ...

    2019

  48. [56]

    Quinn O Snell, Armin R Mikler, and John L Gustafson. 1996. Netpipe: A network protocol independent performance evaluator. In IASTED international conference on intelligent information management and systems, Vol. 6. Washington, DC, USA), 49

    1996

  49. [57]

    Wijnand Suijlen and A. N. Yzelman. 2019. Lightweight Parallel Founda- tions: a model-compliant communication layer. CoRR abs/1906.03196 (2019)

    2019 arXiv

  50. [58]

    https://www.khronos.org/sycl/

    SYCL 2025-03-24. . https://www.khronos.org/sycl/

    2025

  51. [59]

    Enric Tejedor and Rosa M. Badia. 2008. COMP Superscalar: Bringing GRID Superscalar and GCM Together. InIEEE International Symposium on Cluster Computing and the Grid . IEEE Computer Society, 185–193

    2008

  52. [60]

    Peter Thoman, Philip Salzmann, Biagio Cosenza, and Thomas Fahringer. 2019. Celerity: High-Level C++ for Accelerator Clusters. In Euro-Par: Parallel Processing (Lecture Notes in Computer Science, Vol. 11725), Ramin Yahyapour (Ed.). Springer, 291–303

    2019

  53. [61]

    Hernandez, and Jeffrey S

    Pedro Valero-Lara, Jungwon Kim, Oscar R. Hernandez, and Jeffrey S. Vetter. 2021. OpenMP Target Task: Tasking and Target Offloading on Heterogeneous Systems. In Euro-Par: Parallel Processing Workshops (Lecture Notes in Computer Science, Vol. 13098), Ricardo Chaves, Dora B. Hera...

    2021

  54. [62]

    Leslie G. Valiant. 1990. A Bridging Model for Parallel Computation. Commun. ACM 33, 8 (1990), 103–111

    1990

  55. [63]

    https://xcalablemp.org/XACC.html

    XcalableACC 2025-03-24. . https://xcalablemp.org/XACC.html

    2025

  56. [64]

    https://xcalablemp.org/index.html

    XcalableMP 2025-03-24. . https://xcalablemp.org/index.html

    2025

  57. [65]

    Yuan Yuan, Meisam Fathi Salmi, Yin Huai, Kaibo Wang, Rubao Lee, and Xiaodong Zhang. 2016. Spark-GPU: An accelerated in-memory data processing engine on clusters. In 2016 IEEE International Conference on Big Data (Big Data) . 273–283. https://doi.org/10.1109/BigData.2016. 7840613

    2016 doi

  58. [66]

    Afshin Zafari, Elisabeth Larsson, and Martin Tillenius. 2019. DuctTeip: An efficient programming model for distributed task-based parallel computing. Parallel Comput. 90 (2019)

    2019

  59. [67]

    Matei Zaharia, Mosharaf Chowdhury, Michael J Franklin, Scott Shenker, and Ion Stoica. 2010. Spark: Cluster computing with work- ing sets. In 2nd USENIX workshop on hot topics in cloud computing (HotCloud 10). 13

    2010

  60. [2013]

    In IEEE International Symposium on Parallel and Distributed Processing

    XKaapi: A Runtime System for Data-Flow Task Programming on Heterogeneous Architectures. In IEEE International Symposium on Parallel and Distributed Processing. IEEE Computer Society, 1299–1308

Pith tools

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