{"id":"42b884fa-991b-4664-8368-daee07984fc5","arxiv_id":"2509.01425","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"HiCR defines a minimal, technology-agnostic set of operations for distributed heterogeneous computing, implemented as a plugin-based runtime support library that preserves application semantics across backends.","lead":"The paper introduces HiCR, a small set of abstract programming operations that lets the same distributed application code run on different hardware and communication libraries without rewriting it. It sits as a 'runtime support layer' between applications and low-level system software, with pluggable backends for MPI, OpenCL, Huawei NPUs, and more.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Portability guarantee rests on unspecified asynchronous completion semantics: the model defines no memory-consistency or remote-completion rule for memcpy/fence, so 'intended result' is not well-defined.","rationale":"The reader's weakest_assumption points to operation-set completeness, and Section 6 does list missing operations (file management, fault tolerance, security). I agree that completeness is unsupported. However, the more fundamental, load-bearing flaw is that the operations that are defined lack formal semantics—especially the completion/visibility model for asynchronous memcpy and fence. Even if the operation set were complete, the portability claim would still not follow unless 'intended result' is defined with respect to a precise memory and synchronization model. The paper gives no such model, and the four test cases are far too narrow to rule out backend-dependent behavior under adversarial interleavings. This concern is not a rejection of the systems contribution: the open-source implementation, the plugin architecture, and the concrete examples are real evidence that the approach can work. The issue is that the central universality guarantee is stated much more strongly than the evidence supports. The paper can address it by adding an operational or axiomatic semantics for the core API, defining fence in terms of remote visibility when needed, and by stress-testing cross-backend synchronization on the proposed sentinel program. Given these are addressable, retaining the reader's CONDITIONAL verdict is appropriate; I do not see grounds to move to ACCEPT or REJECT. My 'partial' agreement reflects that I identify a different (though adjacent) root cause than the reader's operation-set completeness, and my proposed test targets that root cause directly.","tokens_in":16849,"tokens_out":11567,"duration_ms":144181,"concrete_test":"Implement a two-instance HiCR program using only the core API: instance A allocates a global memory slot, writes a sentinel with a Local-to-Global memcpy, then calls fence; instance B repeatedly performs Global-to-Local memcpy from that slot and calls fence, attempting to observe the sentinel, without any out-of-band RPC or channel handshake. Run the identical program on the MPI backend and the LPF backend. If B never observes the sentinel on either backend, or the number of iterations until observation differs materially, then fence does not provide a portable remote-completion guarantee, directly falsifying the §1 portability claim. This test isolates the missing semantic rule rather than relying on hand-written synchronization in a frontend.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's central claim ('any HiCR-based code will reach its intended result regardless of the system it executes on', §1) presupposes that the abstract operations have a precise, backend-independent semantics. That precondition is not met. In §3.1.4, memcpy is made asynchronous and fence is said to 'suspend execution until the expected number of incoming and outgoing data transfers have been completed.' But the model never defines what 'completed' means for one-sided communication: origin completion (e.g., MPI_Win_flush) vs remote visibility (e.g., MPI_Win_fence or post/start/complete/wait) can differ. For a Local-to-Global memcpy, a fence at the origin does not, in general, guarantee that the data is visible to a remote instance. The model also does not define ordering between asynchronous execution states (§3.1.5) and memcpy operations acting on the same memory slot. Without such ordering or visibility rules, two backends may legitimately implement the same API calls with different synchronization strengths, so the same HiCR program can observe different outcomes. The four empirical test cases (Section 5) do not exercise these race-prone interleavings. Section 6 additionally admits that distributed file management, fault tolerance, and interconnect-topology discovery are missing, undercutting the §3 claim of describing 'any code running on any distributed computing system'; however, the more load-bearing weakness is the under-specified semantics of the operations the model does define, because this threatens the portability guarantee even for programs expressible in the current core API.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":17245,"tokens_out":4751,"duration_ms":57101,"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":[{"comment":"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","section":"§3.1.4, §1"},{"comment":"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.","section":"§3, §3.1.4, §6"},{"comment":"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.","section":"§5, Table 2"}],"minor_comments":[{"comment":"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.","section":"§4"},{"comment":"In the goodput discussion, 'larger messages (> 109 bytes)' should presumably read '>10^9 bytes'; the superscript appears to have been lost.","section":"§5.1"},{"comment":"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.","section":"§3.1.4"},{"comment":"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.","section":"Table 1"}],"recommendation":"major_revision","confidential_remarks":"The paper's universal portability claim is broader than what the formal content currently supports. I do not see circularity in using MPI/OpenCL/OpenBLAS/ACL as backends: testing against external technologies is appropriate. The main risk is that the word 'model' raises an expectation of precise semantics that the manuscript does not yet provide. A major revision that supplies a memory model for memcpy/fence/execution-state ordering, or that carefully scopes the portability claim, would be within the scope of the paper. The benchmarks and the implementation are solid enough to build on."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Thanks for the Pith Report. I read the paper. My take is close to yours: this is a real systems contribution with a genuine abstraction gap, but the central claim — any HiCR-based code reaches its intended result regardless of the system it executes on — is not backed by the evidence.\n\nWhat is actually new: HiCR slices the problem at a different level than StarPU, OCR, IRIS, and the rest. It offers a minimal operation set (topology, memory slots, one-sided memcpy, compute, instance management) without prescribing a programming model, and the plugin-backend design means a HiCR program can switch from MPI to LPF to OpenCL to ACL without source changes. The implementation is open source, the examples are clear, and the benchmarks are honest. The MNIST test running the same HiCR code on CPU, GPU, and NPU with matching accuracy is a legitimate portability data point. The LPF-vs-MPI ping-pong showing 70x goodput for small messages is a nice concrete result.\n\nThe soft spot is real and, I'd say, load-bearing. The model never defines what 'completed' means for a memcpy. In §3.1.4, fence merely 'suspends execution until the expected number of incoming and outgoing data transfers have been completed.' For one-sided communication, local completion (e.g., MPI_Win_flush) and remote visibility (e.g., MPI_Win_fence) are different. Two backends can implement the same API call with different synchronization strengths, and then the same HiCR program can legitimately observe different results. The four test cases do not stress these race-prone interleavings. On top of that, the operation set is asserted to be semantically complete but no proof is given, and Section 6 admits missing features (file management, fault tolerance, interconnect topology discovery) that undercut the 'any code' phrasing. These are addressable — pin down the memory model, add a few race-prone test cases, and soften the claim — but as written, the portability guarantee is a design goal, not a proven property.\n\nThis is not a fatal flaw; it's a revision problem. The paper is a serious contribution that deserves referee time. I would accept it for peer review with major revisions. For a reading group, it's worth a session on abstraction layers in heterogeneous runtimes, though I'd pair it with a discussion of the semantic gap.\n\nRecommendation: send to peer review. The authors should be asked to formalize the completion/visibility semantics and to test a data race or a remote-completion pattern.","headline":"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.","tokens_in":17705,"tokens_out":3374,"would_cite":false,"duration_ms":37589,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"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","keywords":["runtime support layer","distributed heterogeneous programming","portability","abstract model","plugin backends","topology discovery","communication management","compute management"],"falsifier":"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.","tokens_in":16809,"feed_emoji":"🔀","tokens_out":6809,"duration_ms":70679,"temperature":0.7,"pith_summary":"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.","feed_headline":"One API lets the same code run on CPUs, GPUs, and NPUs","feed_subtitle":"A minimal abstract model plus plugin backends keeps program semantics fixed as hardware changes.","key_machinery":"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","core_discovery":"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","pith_inferences":["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."],"forward_implications":["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."],"supporting_citations":[{"why":"Supplies the one-sided communication semantics and backend used in the ping-pong and scaling experiments.","marker":"[57]"},{"why":"Provides the CPU topology and memory discovery backend used across test cases.","marker":"[51]"},{"why":"Supplies the open heterogeneous-device execution backend used for the CPU and GPU inference runs.","marker":"[47]"},{"why":"Provides the digit-recognition dataset that defines the inference correctness test.","marker":"[39]"},{"why":"Supplies the vendor NPU backend used in the inference experiment.","marker":"[28]"},{"why":"Provides the system-wide task scheduler compared in the fine- and coarse-grained tasking tests.","marker":"[3]"}],"fun_headline_variants":["HiCR model: same code for CPUs, GPUs, NPUs","Abstract operations make code hardware-agnostic","One model, many backends: code runs everywhere","Minimal ops set keeps app semantics fixed on new chips","Plugin-based model runs distributed apps on any hardware"],"cache_read_input_tokens":2688,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["HiCR model: same code for CPUs, GPUs, NPUs","Abstract operations make code hardware-agnostic","One model, many backends: code runs everywhere","Minimal ops set keeps app semantics fixed on new chips","Plugin-based model runs distributed apps on any hardware"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000245,"raw_usage":{"total_tokens":1326,"prompt_tokens":653,"completion_tokens":673,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":397,"completion_tokens_details":{"reasoning_tokens":595}},"tokens_in":397,"tokens_out":673,"duration_ms":8239,"temperature":1.0,"reasoning_tokens":595,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-05T12:32:02.727379+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[{"cited_title":"Lightweight Parallel Foundations: a model-compliant communication layer","cited_arxiv_id":"1906.03196","evidence_quote":"Supplies the one-sided communication semantics and backend used in the ping-pong and scaling experiments."},{"cited_title":"https://www.open- mpi.org/projects/hwloc","cited_arxiv_id":null,"evidence_quote":"Provides the CPU topology and memory discovery backend used across test cases."},{"cited_title":"https://registry","cited_arxiv_id":null,"evidence_quote":"Supplies the open heterogeneous-device execution backend used for the CPU and GPU inference runs."},{"cited_title":"https://www.kaggle.com/datasets/ hojjatk/mnist-dataset","cited_arxiv_id":null,"evidence_quote":"Provides the digit-recognition dataset that defines the inference correctness test."},{"cited_title":"https://e.huawei.com/en/ products/computing/ascend","cited_arxiv_id":null,"evidence_quote":"Supplies the vendor NPU backend used in the inference experiment."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Provides the system-wide task scheduler compared in the fine- and coarse-grained tasking tests."}],"review_version":1}