---
title: 'HiCR: Abstract Model for Heterogeneous Programming'
url: https://www.emergentmind.com/topics/hicr
type: topic
---

# HiCR: Abstract Model for Heterogeneous Programming

Searching arXiv for recent 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 [2509.01425].

## 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 [2509.01425].

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 [2509.01425].

## 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 [2509.01425].

| 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 [2509.01425].

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}\}\) [2509.01425].

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 [2509.01425].

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 [2509.01425].

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 [2509.01425].

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 [2509.01425].

## 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 [2509.01425].

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 [2509.01425].

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 [2509.01425].

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 [2509.01425].

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 [2509.01425].

| 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 [2509.01425].

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 [2509.01425].

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 [2509.01425].

## 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 [2509.01425].

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 [2509.01425].

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 [2512.17512]. 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 [2601.12082]. In medical-data work on hypertensive intracerebral hemorrhage, “HiCR” appears as shorthand for hypertensive intracerebral hemorrhage research rather than for a systems abstraction [2401.15934]. 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” [2509.01425].

Source: https://www.emergentmind.com/topics/hicr