HPVM-HDC: A Heterogeneous Programming System for Accelerating Hyperdimensional Computing

Of course. Here is a peer review of the paper from the perspective of 'The Guardian.'

---

Review Form

Reviewer: The Guardian (Adversarial Skeptic)

Summary

The authors present HPVM-HDC, a programming system comprising a C++-based language (HDC++) and a compiler aimed at simplifying the development of Hyperdimensional Computing (HDC) applications for heterogeneous targets, including CPUs, GPUs, and custom HDC accelerators. The system introduces high-level primitives for HDC operations and claims to generate performance-competitive code across these targets from a single source.

While the goal of a unified programming model for this emerging domain is laudable, the work suffers from significant methodological weaknesses in its evaluation and appears to overstate the capabilities of its compiler, particularly concerning the targeting of custom accelerators. The central claims of performance superiority and effortless retargetability are not substantiated by the evidence provided.

Strengths

1. Problem Identification: The paper correctly identifies a critical challenge in the HDC ecosystem: the lack of a portable, high-level programming model that can target a diverse and growing set of hardware, from general-purpose processors to specialized ASICs.
2. System Implementation: The authors have clearly implemented a non-trivial system, including a language frontend, an intermediate representation, and backends for multiple, distinct architectures. The effort to target both a digital ASIC and a ReRAM-based accelerator is noted.
3. Approximation Primitives: The introduction of primitives for managing accuracy-performance trade-offs, such as red_perf (Section 4.2), is a conceptually sound approach for an error-resilient domain like HDC.

Weaknesses

1. Exaggerated Compiler Capabilities for Accelerators: The core premise of a retargetable compiler is undermined by the implementation described for the HDC accelerators. The paper states that HPVM-HDC lowers encoding_loop, training_loop, and inference_loop primitives directly to the accelerators' high-level functional interfaces (Section 4.3, page 8). This is not compilation in a traditional sense; it is a library call wrapper. The system does not appear to synthesize accelerator code from fine-grained HDC primitives (e.g., matmul, hamming_distance). Consequently, the programmer is required to manually structure their code using these coarse-grained "loop" primitives to enable accelerator execution. This negates the claim of a truly hardware-agnostic programming model, as the programmer must be aware of the accelerator's coarse-grained operational model to leverage it.

2. Unconvincing Performance Claims on GPUs: The headline claim of a 1.17x geomean speedup over "optimized baseline CUDA implementations" is not rigorously defended. The authors themselves concede in Section 5.2 (page 10) that "This speedup is primarily the result of different tuning choices in HPVM-HDC generated code compared to the baseline codes." This is a critical flaw. A compiler evaluation must demonstrate that the compiler itself produces superior code from a similar or identical high-level abstraction. Attributing performance gains to manual tuning choices made by the paper's authors, which could have been applied to the baseline, invalidates the comparison. The evaluation is not measuring the compiler's efficacy but rather the authors' tuning effort. The 5% slowdown on HyperOMS further suggests the compiler's code generation is not universally superior.

3. Misleading Accelerator Performance Evaluation: The evaluation in Section 5.2 and Figure 6 is fundamentally flawed. The authors compare "device-only" performance of the ASIC/ReRAM accelerators against a Jetson Orin GPU. This metric is misleading as it omits the cost of data transfer between the host and the accelerator. The paper explicitly states (Section 5.2, page 10) that "the digital ASIC and its ARM host CPU only communicate at approximately 10 kbps." At such a low bandwidth, any non-trivial application would be overwhelmingly bottlenecked by data movement, rendering the "device-only" speedup practically meaningless. A valid evaluation must present end-to-end wall-clock time for the entire application task. The current presentation hides a fatal system bottleneck.

4. Weak Baselines and Metrics:

   • The performance comparison against Python/NumPy on the CPU is acknowledged by the authors as weak but is still presented prominently in Figure 5. Comparing a compiled AOT language (C++) to an interpreted one (Python) is uninformative and inflates the perceived benefits of the system.
   • Lines of Code (LOC), presented in Section 5.4 and Table 4, is a notoriously poor metric for programmability. Comparing C++ LOC to Python LOC is meaningless due to the languages' inherent verbosity differences. While the comparison to CUDA C++ is more relevant, the reduction is modest and does not, on its own, prove a significant improvement in developer productivity.

Questions to Address In Rebuttal

1. Regarding accelerator targeting: Can the HPVM-HDC compiler automatically identify and map a standard, fine-grained loop implementing inference (e.g., a C++ for-loop containing matrix multiplication and an argmin) to the accelerator's execute_inference function? Or must the programmer explicitly replace their fine-grained code with the __hetero_hdc_inference_loop intrinsic for the accelerator to be used? If the latter, how is this functionally different from a preprocessor macro or a library API call?

2. Regarding GPU performance: Please provide a controlled experiment that isolates the performance gains attributable solely to the HPVM-HDC compiler's automatic code generation versus those from manual "tuning choices" that differ from the baseline implementations. For a fair comparison, the same algorithmic structure and tuning parameters should be applied to both the baseline and the HDC++ version.

3. Regarding accelerator evaluation: Please provide an end-to-end performance comparison for HD-Classification on the Digital ASIC, including all necessary data transfers over the 10 kbps host-device link for the Isolet dataset. How does the total wall-clock time compare to the Jetson Orin in this realistic scenario?

4. Regarding the approximation optimizations: The analysis in Section 5.3 is confined to a single application (HD-Classification). How can we be confident that these trade-offs, particularly the observation that encoding is less amenable to perforation than similarity search, generalize to other HDC workloads like those presented in Table 2?

Of course. Here is a peer review of the paper from the perspective of "The Synthesizer."

---

Review Form

Reviewer: The Synthesizer (Contextual Analyst)

Summary

This paper introduces HPVM-HDC, a complete, end-to-end programming system designed to address the programmability and portability challenges in the field of Hyperdimensional Computing (HDC). The authors propose a C++ based language, HDC++, which provides high-level, domain-specific primitives for HDC operations. This language is coupled with a retargetable compiler, HPVM-HDC (an extension of the existing HPVM framework), that can compile a single HDC++ program to a diverse set of hardware targets: multi-core CPUs, GPUs, a taped-out digital HDC ASIC, and a simulated ReRAM-based accelerator. The system also incorporates HDC-specific approximation optimizations, such as automatic binarization and reduction perforation, allowing developers to explore the performance-accuracy trade-off space inherent to HDC. The core contribution is not an algorithmic advance in HDC itself, but rather the creation of a critical piece of infrastructure—the first unified software ecosystem that bridges the gap between high-level HDC algorithm development and efficient execution on heterogeneous, specialized hardware.

Strengths

1. High Significance as Enabling Infrastructure: The most significant contribution of this work is its role as an enabler for the entire HDC research community. The success of any alternative computing paradigm, especially one that relies on custom accelerators, is critically dependent on a viable software stack. This work is to HDC what systems like TensorFlow/PyTorch and compilers like TVM/MLIR are to the deep learning ecosystem. By providing a unified path from a single source code to CPUs, GPUs, and custom hardware, HPVM-HDC dramatically lowers the barrier to entry for both algorithm researchers wanting to test on real hardware and hardware architects looking to demonstrate the value of their custom designs. This is a foundational contribution that could significantly accelerate the maturation of the HDC field.

2. Excellent Scope and Completeness: The system is impressively comprehensive for a first paper. It is not just a language proposal or a single-target compiler. The authors have delivered an end-to-end solution that considers:

   • A high-level programming model (HDC++) that captures the essential operations of HDC (Section 3, page 5).
   • A retargetable compiler intermediate representation (HPVM-HDC IR) that can express both HDC primitives and generic parallelism (Section 4.1, page 5).
   • Backends for a truly heterogeneous set of targets, spanning the spectrum from general-purpose (CPU/GPU) to highly specialized (ASIC/ReRAM) hardware (Section 4.3, page 8). The demonstration on a real, taped-out ASIC is particularly compelling.
   • Domain-specific optimizations that exploit the error-resilient nature of HDC, which is one of its key selling points (Section 4.2, page 7). The evaluation of these trade-offs in Figure 7 (page 11) is well-executed.

3. Contextualization and Vision: The paper is well-positioned within the broader landscape. The authors correctly identify the "programmability wall" as the primary obstacle to the adoption of HDC accelerators. They build upon a known, robust compiler framework (HPVM, Section 2.3, page 4) and clearly differentiate their work from existing HDC libraries (which lack accelerator support) and the only other known HDC compiler, HDCC (which is CPU-only and less flexible), as discussed in the Related Work section (Section 6, page 12). The work embodies a forward-looking vision for hardware-software co-design in the post-Moore era.

Weaknesses

1. Modest Performance Gains on General-Purpose Hardware: While the performance is claimed to be "competitive," the 1.17x geomean speedup over optimized baseline CUDA implementations (Figure 5, page 9) is not, in itself, a groundbreaking performance result. However, this is a minor weakness in the context of this paper's primary goals. The key achievement is attaining this level of performance while providing portability and improved programmability. The value proposition is the combination of all three, not just raw speed on one platform. The authors should be careful to frame this result as achieving performance-parity with hand-tuned code, which is a major success for a retargetable compiler.

2. Limited Generality of Accelerator Backend: The two custom accelerators targeted (the digital ASIC and ReRAM simulator) appear to expose similar, coarse-grained, high-level interfaces (e.g., monolithic execute_inference calls, as shown in Listing 6, page 8). It is not yet clear how well the HPVM-HDC compilation approach would generalize to future HDC accelerators that might expose finer-grained, more diverse hardware primitives. The current approach of mapping high-level inference_loop primitives directly to accelerator APIs is effective here but may not be a universally applicable strategy.

3. Ad-Hoc Nature of HDC++: The HDC++ language is a pragmatic extension of C++ using special types and compiler intrinsics. While this is a perfectly reasonable starting point, it lacks the elegance and formal semantics of a standalone DSL. This could present challenges for future extension and formal analysis. This is more of an observation on the design trade-offs than a critical flaw.

Questions to Address In Rebuttal

1. Regarding the 1.17x geomean speedup over baseline CUDA: Can the authors provide more insight into the source of this speedup? Is it due to fundamentally better code generation strategies in HPVM-HDC, or is it more a result of different (and perhaps better) tuning choices made during the implementation of the HDC++ versions compared to the available baselines? Clarifying this would help contextualize the performance claims.

2. The paper presents an excellent first step in targeting custom accelerators. Could the authors comment on the extensibility of the HPVM-HDC compiler framework? Specifically, how would the compilation strategy need to adapt if a new HDC accelerator were introduced that did not have a coarse-grained "inference" or "training" instruction, but instead exposed lower-level primitives like "parallel XOR" or "bundled addition"? Does the IR have the capacity to target such an architecture effectively?

3. The HDC++ language introduces a set of 24 primitives (Table 1, page 6). How was this set of primitives chosen? What is the anticipated process for extending the language and compiler should new, fundamental HDC operations emerge from algorithm research in the future?

Excellent. I will now assume the persona of "The Innovator" and provide a peer review based exclusively on the novelty of the presented work.

---

Review Form

Reviewer: The Innovator (Novelty Specialist)

Summary

The paper presents HPVM-HDC, a programming system comprising a C++-based language (HDC++) and a compiler for generating code for heterogeneous targets, including CPUs, GPUs, and two specific Hyperdimensional Computing (HDC) accelerators (a digital ASIC and a ReRAM-based design). The authors claim this is the first system to enable productive, portable development of HDC applications across such a diverse set of hardware. The core novel claim rests on the creation of a complete, retargetable compilation framework for the HDC domain, moving beyond existing CPU-only compilers or Python-based libraries.

My assessment is that the central contribution—the integrated, heterogeneous compilation system for HDC—is indeed novel. While individual components build upon existing concepts (HDC primitives, compiler infrastructures, approximation techniques), their synthesis into a unified framework that can target custom HDC hardware is a new and significant contribution to the field.

Strengths

1. A Genuinely Novel System for a Niche Domain: The primary strength of this work is its novelty in addressing a clear gap. The prior art in HDC programming tools consists of:

   • Libraries: TorchHD [19], OpenHD [30], etc., are Python libraries, not compilers. They lack a formal intermediate representation (IR) and the ability to be retargeted to novel hardware architectures like the ASICs presented here. They are bound by the backend of their host framework (e.g., PyTorch).
   • Domain-Specific Compilers with Limited Scope: The authors correctly identify HDCC [61] as the closest prior art. However, HDCC is a source-to-source compiler targeting only multi-core CPUs with POSIX threads. The "delta" here is substantial: HPVM-HDC introduces a proper compiler IR and targets a truly heterogeneous set of devices, including GPUs and, most importantly, custom accelerators. This leap from a single-target compiler to a multi-target, hardware-agnostic framework is the paper's core innovation.

2. First Demonstration of Application Portability to Custom HDC Hardware: A key element of the novelty is the successful targeting of the digital ASIC and the ReRAM accelerator simulator (Section 5.2, page 10). To my knowledge, no prior work has demonstrated a high-level programming language and compiler capable of generating code for these specific, research-grade accelerators from the same source code that runs on a CPU/GPU. This is a "zero to one" contribution in terms of enabling software for this class of hardware.

3. Novel Integration of Domain-Specific Optimizations: While the concepts of binarization and skipping computations (perforation) are not new in the broader context of machine learning acceleration (they are analogous to quantization and pruning), their implementation as automated, IR-level compiler transformations within an HDC-specific framework is novel. Section 4.2 describes a formal approach to applying these approximations that goes beyond ad-hoc, manual code changes seen in prior HDC application papers.

Weaknesses

1. Reliance on an Existing Compiler Framework: The novelty is somewhat circumscribed by the fact that the system is built upon the existing HPVM compiler infrastructure [13]. The paper is transparent about this, but it's crucial to state that the novelty is not in the compiler's core architecture (the hierarchical dataflow graph representation) but in its specialization for the HDC domain. The contribution is a new front-end (HDC++) and new back-ends, not a new compiler paradigm.

2. Primitives are Not Fundamentally New: The HDC++ language itself is primarily a collection of primitives (Table 1, page 6) that encapsulate well-known HDC operations (e.g., random projection, Hamming distance). The language design does not introduce novel concepts for expressing parallelism or computation beyond what is necessary to represent these operations for the compiler. Its novelty is functional—as an effective interface to the compiler—rather than conceptual.

3. Coarse-Grained Accelerator Interface: The novelty of the accelerator targeting is slightly diminished by the coarse-grained nature of the interface (encoding_loop, training_loop, inference_loop as described in Section 4.3, page 8). This approach maps large, monolithic stages of an algorithm to the hardware. While practical and effective for the specific accelerators targeted, it represents a less sophisticated compilation strategy than, for example, generating a custom instruction stream from finer-grained primitives. The novelty is in making the connection, not necessarily in the sophistication of the code generation for the accelerators themselves.

Questions to Address In Rebuttal

1. Distinction from General-Purpose ML Compilers: Extensible compiler frameworks like MLIR and TVM are explicitly designed to support new domains and hardware targets through new "dialects" and lowering passes. What is the fundamental novelty of the HPVM-HDC approach that could not have been achieved by defining an "HDC dialect" in MLIR? Is the contribution primarily an engineering one based on the authors' familiarity with HPVM, or is there a core architectural reason why HPVM is uniquely suited for this task in a way that represents a novel compilation strategy?

2. Generalizability of the Accelerator Backend: The paper demonstrates targeting two specific accelerators with similar coarse-grained programming models. How general is this backend design? If a third party designed a new HDC accelerator with a fundamentally different, finer-grained instruction set (e.g., focusing on permutation operations), would the HPVM-HDC framework require a complete backend rewrite, or are there novel, reusable components in your accelerator code generation strategy?

3. Novelty of the IR Extensions: The paper states that HDC primitives are represented as LLVM intrinsics within the HPVM-HDC IR (Section 4.1, page 5). Beyond simply adding new intrinsics, were any novel extensions or modifications required for the HPVM dataflow graph IR itself to efficiently represent the unique data dependencies or computational patterns found in HDC (e.g., the manipulation of entire hypervectors as atomic units)? If not, it would suggest the novelty lies more in the front-end and back-end rather than the core representation.