Can a compiler spend HDC's accuracy budget? Reviewing ApproxHDC

Hyperdimensional Computing (HDC) is often described as robust because meaning is distributed across thousands of components. Change a few components, round their values more aggressively, or skip part of a calculation, and the final hypervector may drift rather than collapse. That gradual degradation is useful, but it leaves a practical question: which shortcuts are safe for this application, on this hardware, at the quality level we actually need?

In Compiler-Driven Approximation Tuning for Hyperdimensional Computing, Xavier Routh and colleagues introduce ApproxHDC, a framework that turns that question into an automated search problem.¹ A developer supplies an HDC application and a minimum acceptable task score. ApproxHDC then tries different application, compiler, and simulated-hardware settings, looking for a faster or more energy-efficient combination that still meets the score.

We think this is the paper’s most important contribution. Its strongest results are substantial, with reported central processing unit (CPU) speedups up to 17.3× and graphics processing unit (GPU) speedups up to 15× across the main application suite. More interestingly, the best settings differ from one workload to another. Sometimes dimension dominates. Sometimes the system changes the representation or number of training iterations. In one application, selectively skipping work inside a similarity calculation matters as well.

The result is a useful picture of HDC optimization: robustness may create an accuracy budget, but there is no universal way to spend it.

What ApproxHDC actually tunes

ApproxHDC builds on HPVM-HDC, an HDC programming and compiler system based on the Heterogeneous Parallel Virtual Machine (HPVM). A compiler normally turns source code into instructions for a processor. HPVM adds a shared internal description of a program that can be translated for different kinds of hardware. HPVM-HDC adds the HDC++ language, familiar HDC operations, HDC-specific optimizations, and routes to CPUs, GPUs, and accelerator models.² An accelerator is specialized hardware designed to perform a narrower set of calculations efficiently.

HPVM-HDC already supports automatic binarization, which replaces a higher-precision representation with a binary one when possible. It also supports reduction perforation. Many HDC operations reduce thousands of component-wise values to one similarity score or bundled hypervector. Perforation calculates only a selected portion of those values, trading some information for less work. The HPVM-HDC paper studies these transformations but leaves their automatic selection as an open problem.

ApproxHDC fills that gap with a repeated trial-and-measure loop based on OpenTuner.³

1. The compiler finds the individual HDC operations in the program.
2. ApproxHDC chooses a complete set of application, compiler, and hardware settings.
3. It compiles and runs that version, measuring both execution cost and task quality.
4. The tuner uses the result to decide which settings to try next.

Knob family	Examples in ApproxHDC	In plain language
Compiler transformations	Binary hypervectors; how much of a reduction operation to calculate	Change how one HDC operation is executed
Application choices	Dimension, data type, algorithm, training iterations, decision threshold	Change the HDC model or task settings
Simulated hardware	Converter precision, memory-programming checks, bits stored per cell	Change modeled speed, energy, storage density, and error

Not every choice makes sense for every HDC operation or hardware target. ApproxHDC builds its menu from the operations present in the program. Developers can add task-specific settings or mark sensitive operations with a no_approx instruction, meaning “leave this part exact.” In the evaluated applications, that protection is used particularly for encoding.

This makes the automation deliberately collaborative. The compiler knows which transformations can be applied. The developer can protect stages that should remain exact. The tuner then discovers which complete combinations meet the quality target in practice.

The individual ingredients have an important lineage. HPVM-HDC supplies the HDC programming model and existing transformations. OpenTuner supplies the general search machinery. Earlier systems such as ApproxHPVM and ApproxTuner already explored quality-aware compilation across software and approximate hardware for other workloads.⁴ ApproxHDC’s contribution is the HDC-specific integration: one search can see choices inside individual HDC operations, settings that affect the whole model, and settings belonging to the modeled hardware.

What the reported results show

The main evaluation covers four applications on CPUs and GPUs. HD-Classification and HD-Clustering use ISOLET, a dataset of people speaking letters of the alphabet. RelHD learns from a graph of scientific papers called Cora. HD-HashTable searches genome sequences using HDC. The general rule accepts a configuration when its quality score is no more than 0.05 below the original version. For classification accuracy, that is a loss of five percentage points, not a five-percent relative change.

The following table keeps the reported quality point beside each speedup. These are the best configurations the authors report finding within their tuning budgets, not results we independently reproduced.

Application	Reported quality point	Reported CPU speedup	Reported GPU speedup	What mostly produced the gain
HD-Clustering	NMI 0.72 → 0.6737 CPU / 0.6708 GPU	17.3×	13.4×	Integer representation, Hamming similarity, fewer training iterations
RelHD	Accuracy 0.71 at the accepted setting	11.4×	15×	Dimension reduced from 2,048 to 128
HD-Classification	Accuracy 0.87 → 0.82	11.6×	12.9×	Dimension 2,048 → 256 and training iterations 10 → 3
HD-HashTable	Accuracy 0.83 → 0.78	2×	14.7×	Dimension, bucket packing, threshold, and partial similarity work

For clustering, the paper uses normalized mutual information (NMI) rather than accuracy. NMI measures how closely the discovered clusters agree with the known grouping; higher is better. A 17.3× speedup means the selected CPU configuration is reported to run about 17.3 times as fast as that application’s original, untuned configuration.

The headline speedups are impressive, but where they come from is more revealing. HD-Clustering changes its numeric representation and similarity method while reducing training from 20 iterations to 3. RelHD receives most of its speedup from a 16× reduction in dimension. HD-Classification combines a smaller dimension with fewer training iterations. In all three, calculating only part of an individual reduction contributes little or nothing to the fastest reported GPU configuration.

HD-HashTable shows why the wider search space still matters. Its selected GPU configuration reduces dimension from 8,192 to 512, changes how many genomic fragments share each stored bucket, tunes the decision threshold, and uses roughly 65% of the query hypervector when calculating similarity. Here, selectively skipping work inside one operation contributes materially to the 14.7× result.

This is not a failure of compiler-driven approximation. It shows that HDC workloads expose quality–efficiency trade-offs at several levels, and that the useful level depends on the task. A tuner that considered only skipped calculations would miss the dominant gains in three applications. A tuner that considered only settings for the whole model would miss the more local opportunity in HD-HashTable.

Pruning the space without losing the useful choices

Letting the tuner choose exactly where to begin skipping, how often to skip, and how much of every operation to calculate creates an enormous menu. For HD-Classification, the paper estimates roughly $10^{89}$ possible combinations in the fullest space, compared with $10^3$ when reduction perforation is disabled—a difference of 86 orders of magnitude. These are rough counts of possible settings, not the number of versions the tuner actually runs. They nevertheless explain why choosing a sensible menu matters.

The paper’s most useful simplification is to protect encoding and let the tuner choose only how much of selected reductions to calculate. Within the same fixed search time, this smaller menu often reaches better configurations than exposing every skipping pattern. The lesson is intuitive: more choices do not help if the tuner spends its time on combinations that are unlikely to preserve quality.

ApproxHDC therefore combines two kinds of knowledge. The compiler prevents choices that do not make sense for the program, while developer annotations narrow the search toward choices that are more likely to preserve the task’s meaning. A future system might learn more of that sensitivity automatically, but this developer-guided version is already a practical way to contribute domain knowledge.

A richer search space than MicroHD

The paper also compares ApproxHDC with MicroHD, an HDC optimizer that tunes dimension, the number of encoding levels, and how many bits are used to store values.⁵ Both systems must remain above an ISOLET accuracy cutoff of 0.845. ApproxHDC reports a 24.7× relative speedup at accuracy about 0.847, while MicroHD reports 7.1× at about 0.871. ApproxHDC first exceeds MicroHD’s best relative speedup after roughly 282 seconds of tuning.

The comparison supports a narrow but useful conclusion: the additional choices inside individual operations can locate a faster accepted setting. ApproxHDC’s selected configuration uses about 44% of one cosine-similarity calculation during training and about 82% during inference, choices MicroHD cannot express.

MicroHD also finishes at the higher accuracy point. That does not make its result better or worse in isolation: both satisfy the stated cutoff, and they spend the remaining quality budget differently. A fuller comparison would use one common implementation and show the complete curve of speed versus accuracy. For this paper, the experiment is best viewed as evidence that compiler choices inside individual HDC operations widen the range of settings an optimizer can reach.

Extending the same interface to in-memory hardware

ApproxHDC’s most forward-looking experiment targets the SpecPCM phase-change-memory simulator.⁶ To understand this part of the paper, it helps to separate the HDC model from the hardware that runs it.

In a conventional computer, the processor repeatedly fetches data from memory, performs a calculation, and writes the result back. Moving the data can consume a large share of the time and energy. In-memory computing reduces that movement by performing selected calculations inside, or very close to, the memory array. This is a natural fit for HDC similarity operations, which repeatedly combine many stored components in parallel.

Conceptual schematic: in-memory computing shortens the data path by performing part of the similarity calculation in the memory array. It does not model individual neurons.

Phase-change memory (PCM) stores information by switching a material between physical states with different electrical resistance. An array of PCM cells can both hold values and help calculate dot products. SpecPCM is a software simulator of such an accelerator. It predicts how a design would behave; the ApproxHDC experiment does not run on a newly fabricated PCM chip.

ApproxHDC adds four kinds of hardware setting to the choices already available for HD-Classification:

Hardware setting	What it means
Analog-to-digital converter precision	How precisely an analog electrical signal is turned into a digital number; fewer bits are cheaper but coarser
Converter range	The span of analog values the converter can represent before values are clipped or compressed
Write-verify cycles	How many times the system checks and corrects a memory cell while programming it
Bits per memory cell	How many values one physical cell stores; more values improve density but are harder to distinguish reliably

The best runtime configuration reports a 4.7× speedup at accuracy 0.8138, compared with a 0.84 baseline. Most of that runtime improvement comes from reducing training iterations from 10 to 2. The selected hardware settings have little modeled effect on execution time. Their more interesting contribution is energy: the paper reports a nearby setting with up to 7.1× modeled energy reduction for an additional 0.6 percentage points of accuracy loss.

What the experiment demonstrates	What remains earlier-stage
One tuning interface can expose software, application, and hardware choices	The hardware behavior is predicted by the SpecPCM simulator
Task accuracy can limit how aggressively the modeled device is simplified	The main runtime gain comes from fewer training iterations
Converter range and precision can change modeled energy without changing the HDC app	ApproxHDC is not evaluated on a fabricated hardware target

This distinction does not diminish the interface. Other HDC hardware studies have shown that storage precision, array layout, and physical device variation can affect application accuracy, including work with measured arrays made from ferroelectric memory, another emerging memory technology.⁷ ApproxHDC offers a way to include those hardware imperfections in the same deployment decision as software shortcuts. The next step is to compare its simulator predictions with measurements from real devices and complete hardware systems.

A brief evidence boundary

The reviewed paper is the first arXiv version, submitted in June 2026. It does not link the ApproxHDC software, the complete record of settings it tried, the random seeds needed to repeat those trials, or a fixed package containing the results. We therefore treat its numbers as results reported by the authors rather than results we independently reproduced.

The search is partly random, so separate runs may explore different settings. The paper shows the best result found as each run progresses, but not how much the outcome varies when the whole search is repeated. It also does not describe the data split clearly enough to tell whether the tuner chooses settings on one validation set and reports final performance on a separate test set. That separation helps prevent the tuning process itself from adapting too closely to the examples used to judge it.

For a concise review, we would not make these issues the centre of the story. They mainly define the next standard of evidence: repeat the search, preserve every tested configuration, separate the data used for choosing settings from the data used for final evaluation, and publish enough of the toolchain to recreate the range of speed–quality trade-offs.

The HDC Labs perspective

Our explanation of holographic hypervectors describes why damage to a distributed representation can change similarity gradually. ApproxHDC turns that intuition into an engineering question. If the final task tolerates a small change in quality, which parts of the pipeline can be made cheaper without changing too many decisions?

The results show why “HDC is robust” is not enough guidance by itself. Encoding is sensitive enough that the evaluated searches often protect it. Reducing dimension is highly effective for RelHD and HD-Classification, but the safe dimension depends on the application. Calculating only part of a similarity score is useful in HD-HashTable and the MicroHD comparison, yet often unnecessary elsewhere.

We find it helpful to describe the compiler as allocating a quality budget. A configuration spends that budget through several mechanisms:

1. Lower dimension reduces redundancy and work.
2. Fewer iterations stop learning earlier.
3. A different representation or algorithm changes both cost and the kinds of patterns the model handles well.
4. Perforation discards part of an operation.
5. Approximate hardware introduces coarser rounding or physical device noise.

Overall accuracy or NMI tells us whether the total expenditure was acceptable. It does not show how close an individual prediction came to changing. For a similarity-based classifier, we would also track the decision margin: the gap between the winning similarity score and the runner-up.

$$\Delta( \mathbf{h}_{\text{query}} ) = \operatorname{sim}( \mathbf{h}_{\text{query}}, \mathbf{h}_{\text{winner}} ) - \operatorname{sim}( \mathbf{h}_{\text{query}}, \mathbf{h}_{\text{runner-up}} ).$$

Here, $\mathbf{h}_{\text{query}}$ is the encoded example, while $\mathbf{h}_{\text{winner}}$ and $\mathbf{h}_{\text{runner-up}}$ are the two closest class hypervectors. A large $\Delta$ means the decision has room to absorb more noise. A small $\Delta$ means a slight change could reverse the result.

This is our proposed extension, not a metric reported by ApproxHDC. A configuration can preserve average accuracy while shrinking many margins, leaving it more fragile when the data changes or the hardware adds further noise. Conversely, a cheaper configuration might preserve wide margins even if a few difficult examples change class. Looking at the distribution of those margins could help the tuner distinguish the two cases.

The wider implication is that HDC’s simple operations and distributed representations make it unusually natural to expose quality as a deployment setting. The same source application could become a conservative server version, a lower-dimensional edge-device version, or a version adjusted for in-memory hardware, each with an explicit minimum task score. Reaching that point would require reliable tuning procedures and simulator models checked against real hardware measurements, but ApproxHDC makes the interface concrete.

Experiments we would run next

The next experiments should explain where ApproxHDC’s gains come from and how stable they remain beyond one tuning run.

1. Repeat the search. Publish random seeds, every tested configuration, complete traces, and the variation in best-found quality and performance under equal time budgets.
2. Test each knob family separately. Compare application settings, algorithm choices, changes inside individual operations, and hardware settings before combining them.
3. Measure decision margins. Track winning-versus-runner-up similarity gaps and score distributions alongside aggregate task quality.
4. Test reuse. Apply a configuration to a second dataset, a different quality allowance, and another hardware target before tuning again from scratch.
5. Make the search cost worthwhile. Compare tuning time with the expected deployment lifetime, number of queries, or number of devices that can reuse the result.

Testing the knob families separately is particularly important. If dimension and iteration count capture most of the available gain for one workload, a small, fast tuner may be sufficient. If choices inside individual operations or hardware settings create speed–quality trade-offs that the simpler tuner cannot reach, the full compiler-driven space earns its complexity. Both outcomes would improve deployment guidance.

Closing position

ApproxHDC asks a productive question: can the tolerance associated with HDC become something a compiler manages rather than something a developer assumes? The paper’s answer is promising. Across four CPU/GPU applications, its reported configurations show substantial speedups within an explicit task-quality allowance, and the workload-by-workload differences justify looking across more than one layer of the system.

The paper does not yet establish a reproducible tool validated on real accelerator hardware. What it does establish is a useful design for one: the compiler can see individual HDC operations, developers can add new settings, the tuner measures task quality directly, and one minimum-quality rule can cover both software and simulated hardware choices.

That changes the practical role of robustness. Instead of hard-coding the same dimension, precision, and execution policy everywhere, an HDC deployment can ask a more direct question:

How much quality does this application need on this device, and what is the cheapest configuration that still provides it?

ApproxHDC’s contribution is to make that question programmable.

Footnotes

1. Xavier Routh et al., “Compiler-Driven Approximation Tuning for Hyperdimensional Computing” ↗ , arXiv:2606.26547v1 (2026 preprint). ↩

2. Russel Arbore et al., “HPVM-HDC: A Heterogeneous Programming System for Accelerating Hyperdimensional Computing” ↗ , Proceedings of the 52nd Annual International Symposium on Computer Architecture (2025). ↩

3. Jason Ansel et al., “OpenTuner: An Extensible Framework for Program Autotuning” ↗ , Proceedings of the 23rd International Conference on Parallel Architectures and Compilation Techniques (2014). ↩

4. Hashim Sharif et al., “ApproxHPVM: A Portable Compiler IR for Accuracy-Aware Optimizations” ↗ , Proceedings of the ACM on Programming Languages 3, OOPSLA (2019); Hashim Sharif et al., “ApproxTuner: A Compiler and Runtime System for Adaptive Approximations” ↗ , Proceedings of the 26th ACM SIGPLAN Symposium on Principles and Practice of Parallel Programming (2021). ↩

5. Flavio Ponzina and Tajana Rosing, “MicroHD: An Accuracy-Driven Optimization of Hyperdimensional Computing Algorithms for TinyML Systems” ↗ , tinyML Research Symposium (2024). ↩

6. Keming Fan et al., “SpecPCM: A Low-Power PCM-Based In-Memory Computing Accelerator for Full-Stack Mass Spectrometry Analysis” ↗ , arXiv:2411.09760v2. ↩

7. Arman Kazemi et al., “Achieving Software-Equivalent Accuracy for Hyperdimensional Computing with Ferroelectric-Based In-Memory Computing” ↗ , Scientific Reports 12 (2022). ↩