HiCR: Abstract Model for Heterogeneous Programming

Updated 10 July 2026

HiCR is an abstract model and accompanying C++ library that provides a minimal set of operations for distributed heterogeneous programming, enabling seamless hardware portability.
It defines a clear component taxonomy by splitting managers, stateless, and stateful components to represent hardware topology, memory, and execution effectively.
HiCR serves as a runtime support layer that decouples application semantics from backend implementations, promoting flexibility across diverse compute platforms.

Searching arXiv for papers using “HiCR” to ground the article and clarify possible meanings. I’ll look for exact-title and near-match uses of “HiCR”, plus related expansions that appear in recent arXiv work. HiCR, pronounced “hiker,” is an abstract model and accompanying C++ library for distributed heterogeneous programming. It represents the semantics of distributed heterogeneous applications and runtime systems through a minimal set of abstract operations for hardware topology discovery, kernel execution, memory management, communication, and instance management, while deliberately avoiding implementation commitments. In the software stack described by its authors, HiCR occupies a “Runtime Support Layer” between applications, domain-specific libraries, and runtime systems on one side, and low-level system libraries and drivers on the other, with the stated goal of enabling execution on current and future systems without significant refactoring and without prescribing any governing parallel programming paradigm (Martin et al., 1 Sep 2025).

1. Position in the software stack

The central problem addressed by HiCR is that modern AI and HPC platforms are simultaneously distributed, heterogeneous, and rapidly changing. Applications are commonly tied to concrete combinations such as MPI, CUDA, OpenMP, OpenCL, vendor AI SDKs, or cloud interfaces. When the underlying hardware or system software changes, application code often has to be refactored even if its semantics does not. HiCR addresses this by separating the abstract meaning of operations—allocation, movement, execution, topology discovery, and instance creation—from their concrete realization by backends (Martin et al., 1 Sep 2025).

The model is explicitly not presented as a new programming paradigm. Instead, it is a common substrate that can support runtime systems, domain-specific libraries, and user applications. This placement is formalized by the phrase “Runtime Support Layer,” which denotes a layer above system libraries and drivers and below higher-level runtimes and applications. A plausible implication is that HiCR is intended less as an end-user language than as an interoperability layer for systems software.

The paper also emphasizes implementation independence. HiCR does not prescribe how a ProcessingUnit is implemented, how a transfer is performed, what scheduling strategy is used, or what representation a kernel must take beyond the requirements of the selected backend. This design allows backends to map the same abstract operation set to MPI, LPF, HWLoc, OpenCL, ACL, Pthreads, or cloud-oriented systems without changing the HiCR-level application semantics (Martin et al., 1 Sep 2025).

2. Component taxonomy and semantic model

HiCR is defined by a fixed set of component kinds and abstract operations. The components are divided into three groups: managers, stateless components, and stateful components. Only managers create and manipulate the other two classes of objects (Martin et al., 1 Sep 2025).

Group	Components	Role
Managers	Instance Manager, Topology Manager, Memory Manager, Communication Manager, Compute Manager	Stateless service components that perform operations
Stateless components	Instance Template, Topology, Device, Memory Space, Compute Resource, Execution Unit	Pure descriptions, copyable and serializable
Stateful components	Instance, Local Memory Slot, Global Memory Slot, Processing Unit, Execution State	Runtime objects with mutable state and unique identity

This decomposition gives HiCR its formal structure. A Topology describes the hardware visible to an instance; a Device contains MemorySpace and ComputeResource objects; an ExecutionUnit is a static description of code; an ExecutionState is a concrete invocation with arguments and runtime state; and memory is exposed through LocalMemorySlot and GlobalMemorySlot abstractions. The distinction between stateless and stateful objects is fundamental: stateless components describe capabilities, while stateful components represent allocations, execution contexts, or live distributed entities (Martin et al., 1 Sep 2025).

The paper’s formal content is not theorem-driven. Instead, its rigor lies in the categorization of components, in the allowed operations over those components, and in the semantics assigned to those operations. This suggests that HiCR should be understood as a semantic model with an implementation-neutral API rather than as a calculus or proof system.

3. Topology, execution, memory, and communication

HiCR’s topology model begins with the Instance, defined as the part of the distributed system a process sees and controls. An instance contains a Topology, and the topology contains a set of devices. The paper writes this structure as a collection $D = \{d_0, \dots, d_k\}$ , with each device $d$ exposing memory spaces $M(d) = \{m_{d,0}, \dots, m_{d,i}\}$ and compute resources $C(d) = \{c_{d,0}, \dots, c_{d,j}\}$ (Martin et al., 1 Sep 2025).

A MemorySpace is any hardware element exposing explicitly addressable memory of non-zero size. A ComputeResource is any hardware or logical element capable of performing computation. This includes CPU cores, SMT threads, GPU compute units, streams, or NPU cores. The TopologyManager discovers these objects and returns topology descriptions that can be serialized and exchanged across instances, allowing a program to assemble a distributed view of resources (Martin et al., 1 Sep 2025).

The execution model breaks kernel launch into four abstractions: ComputeResource, ProcessingUnit, ExecutionUnit, and ExecutionState. A ProcessingUnit is a runtime object created from a compute resource and represents an initialized execution context. An ExecutionUnit is a static description of a function or kernel. An ExecutionState represents one execution of that unit, including runtime metadata such as arguments or stack state. The ComputeManager::execute(p, s) operation starts asynchronous execution of an ExecutionState on a ProcessingUnit, while await blocks until completion and finalize tears the processing unit down (Martin et al., 1 Sep 2025).

Memory is represented through LocalMemorySlot and GlobalMemorySlot. A LocalMemorySlot corresponds to a contiguous memory segment of known size in a specific memory space. A GlobalMemorySlot is a distributed handle produced collectively so that remote instances can access a registered local buffer. The MemoryManager provides allocation, deallocation, and registration operations, enabling HiCR to manage both newly allocated and externally created buffers (Martin et al., 1 Sep 2025).

Communication is intentionally minimal. HiCR standardizes on an asynchronous memcpy(dst_slot, dst_offset, src_slot, src_offset, size) and a fence(). The allowed directions are Local→Local, Local→Global, and Global→Local; Global→Global is forbidden. The fence operation blocks until the expected number of relevant transfers have completed. This yields a narrow but well-defined semantic core for heterogeneous and distributed movement of data (Martin et al., 1 Sep 2025).

4. Instances, plugins, and integration with runtimes

Instance management is handled by the InstanceManager. HiCR distinguishes launch-time instances, created by an external launcher such as mpirun, from runtime-created instances, created by the program itself from an InstanceTemplate. The InstanceTemplate can encode hardware needs, topological constraints, or cloud-specific attributes, and the backend decides how to realize those requirements (Martin et al., 1 Sep 2025).

A notable constraint is that no two running instances share a device. Cross-instance interaction therefore occurs through distributed-memory communication rather than shared-device semantics. HiCR also defines a Root Instance, used for tie-breaking or coordination but not endowed with special computational capabilities (Martin et al., 1 Sep 2025).

The implementation strategy is plugin-based. The Core API is a set of abstract C++ classes, and concrete backends derive from these classes. The paper gives examples in which an MPI instance manager, HWLoc topology and memory managers, and Pthreads communication and compute managers are instantiated and then treated through the abstract HiCR interfaces. This permits the same HiCR-level application to run across different implementations and hardware targets (Martin et al., 1 Sep 2025).

The model is also described as orthogonal to programming paradigms. It can underlie message-passing systems, task-based runtimes, actor models, PGAS-style systems, or skeleton frameworks. The paper positions HiCR relative to systems such as StarPU, HPX, OpenMP, OpenACC, SYCL, Kokkos, Chapel, X10, OCR, and IRIS. In particular, IRIS is described as similar in portability goals but limited by lack of distributed support and by a prescribed task-based style, whereas HiCR supports distributed memory and does not prescribe a particular programming style (Martin et al., 1 Sep 2025).

The authors further mention frontends built on top of the core abstractions, including Channels, Data Objects, RPC, and Tasking. This indicates that HiCR is meant to host higher-level coordination mechanisms without absorbing them into the core abstraction.

5. Empirical demonstrations across backends

The paper supports its portability claims through several HiCR-only applications executed with different backend combinations (Martin et al., 1 Sep 2025).

Example	Backends / platforms	Reported result
Ping–pong communication benchmark	LPF vs MPI one-sided RMA	For small messages, LPF achieves about $70\times$ better goodput; for messages $>10^9$ bytes, both converge to about 80% of a 100 Gbps link
Heterogeneous inference pipeline	Pthreads + OpenBLAS, OpenCL on Intel P630, ACL on Huawei Ascend 910A	94.64% accuracy on 10,000 test images across all combinations
Fine-grained tasking, Fibonacci	nOS-V vs Pthreads + Boost	150,049 tasks for $F(24)=46{,}368$ ; 1.34 s with nOS-V and 0.21 s with Pthreads + Boost
Coarse-grained 3D Jacobi	nOS-V vs Pthreads + Boost	40.5 s and about 43.1 GFlop/s for nOS-V; 39.9 s and about 43.7 GFlop/s for Pthreads + Boost

The communication benchmark uses two instances connected through a Channels frontend and tests message sizes from 1 byte to approximately 2.14 GB. The result illustrates that the same HiCR application can exhibit substantially different performance depending on backend selection, while retaining identical abstract semantics (Martin et al., 1 Sep 2025).

The inference example runs a simple neural network for MNIST digits on CPU, GPU, and NPU backends. The reported accuracy is the same across combinations, although the first-image score differs slightly because of floating-point differences and different kernel implementations or evaluation order. This result is presented as evidence that a single HiCR codebase can span Intel and Huawei platforms and multiple accelerator classes without HiCR-layer refactoring (Martin et al., 1 Sep 2025).

The two tasking case studies are designed to contrast fine-grained and coarse-grained scheduling behavior. In the Fibonacci benchmark, user-level coroutines reduce context-switch overhead relative to system-wide scheduling. In the 3D Jacobi heat-equation solver on a $704^3$ grid with a 13-point Manhattan distance-1 stencil, both backends achieve similar performance because scheduling overhead is small relative to the computation. A scaling experiment up to four nodes using LPF over Infiniband shows good strong and weak scaling for both backends (Martin et al., 1 Sep 2025).

6. Scope, limitations, future work, and disambiguation

HiCR’s design is guided by minimality, implementation independence, separation of concerns, future-proofing, and layer neutrality. At the same time, the paper is explicit about what the model does not define. HiCR does not provide a global memory consistency model, a task dependency graph structure, or an automatic load-balancing scheme. It also omits explicit interconnect-topology modeling, distributed file I/O, multi-user job scheduling, built-in fault tolerance, and security isolation in its current form (Martin et al., 1 Sep 2025).

The authors also note practical constraints. Existing sequential codes may require substantial refactoring to adopt HiCR, and performance depends strongly on backend quality. A poor backend preserves semantics but may fail to exploit the hardware effectively. Planned extensions include interconnect topology modeling with latency and bandwidth attributes, distributed file management, multi-user job allocation, fault tolerance, and security isolation (Martin et al., 1 Sep 2025).

The label “HiCR” is also used in unrelated arXiv contexts, and that ambiguity is technically significant. In chromatin-conformation analysis, BHiCect 2.0 is described as essentially a “HiCR” tool because it converts Hi-C contact maps into an explicit hierarchical multi-resolution representation of chromatin organization (Kumar et al., 19 Dec 2025). In computational pathology, HistoCRF is stated to be abbreviated as “HiCR” in some contexts, where it denotes a training-free CRF-based framework for refining histopathology patch labels (Godelaine et al., 17 Jan 2026). In medical-data work on hypertensive intracerebral hemorrhage, “HiCR” appears as shorthand for hypertensive intracerebral hemorrhage research rather than for a systems abstraction (Li et al., 2024). Within distributed heterogeneous programming, however, HiCR refers specifically to the abstract model and Runtime Support Layer introduced in “HiCR, an Abstract Model for Distributed Heterogeneous Programming” (Martin et al., 1 Sep 2025).