HORSE

Do We Need Tensor Cores for Stencil Computations? (SC’26)

Abstract

This repository contains the SC'26 Artifact Evaluation package for the paper "Do We Need Tensor Cores for Stencil Computations?".

The paper revisits the interplay between stencil characteristics and Tensor Core constraints. We characterize the algorithmic inefficiencies that limit Tensor Core stencil performance and introduce HORSE, the Hardware- and Overhead-aware Roofline Stencil Estimator, to estimate stencil performance across hardware units. HORSE provides a first-order estimate of the relative performance of Tensor Cores and general-purpose units under different stencil and hardware configurations, and uses that estimate to identify the sweet spot where Tensor Cores outperform general-purpose units.

Clone

git clone --recurse-submodules https://github.com/KevinWu2017/HORSE.git
cd HORSE
git submodule update --init --recursive

Environment

Check the machine from the repository root:

python scripts/env/check_env.py

Required for the main AE targets:

• NVIDIA A100-80GB PCIe GPU.
• Ubuntu 22.04 with CUDA 12.8.
• At least 64GB host memory and 10GB free disk space.
• NVIDIA H100 PCIe GPU for the optional Table III sensitivity target.

Typical runtime: within 30 minutes on the A100/H100 PCIe platforms used for AE validation.

Commands

Run all AE-covered targets:

python artifact/run.py all-ae

all-ae writes artifact/results/summary.md with completed, skipped, or failed for each target. Generated files, raw measurements, metadata, and logs are written under artifact/results/. Packaged CSV inputs are under artifact/inputs/ (tables/, model/, and roofline/).

Output folders created by all-ae:

Output folder	Paper element
artifact/results/fig-theoretical-intensity/	Figure 9
artifact/results/fig-ebisu-roofline/	Figure 10
artifact/results/table-a100-criteria/	Table II
artifact/results/table-h100-sensitivity/	Table III
artifact/results/table-sparse-tc/	Table IV
artifact/results/table-formulation/	Table V

Run individual targets:

# Figure 9: theoretical problem classification
python artifact/run.py fig-theoretical-intensity

# Figure 10: EBISU profiled roofline
python artifact/run.py fig-ebisu-roofline

# Table II: A100 criteria verification
python artifact/run.py table-a100-criteria

# Table III: H100 sensitivity
python artifact/run.py table-h100-sensitivity

# Table IV: dense vs sparse Tensor Cores
python artifact/run.py table-sparse-tc

# Table V: formulation validation
python artifact/run.py table-formulation

Acknowledgement

This artifact references and builds on the following open-source projects. We thank the authors for their excellent work:

• microsoft/ConvStencil
• neozhang307/EBISU-ICS23

Contact

If you have any questions, please send an email to the authors at cpwu2017@126.com or guqiqi_1998@163.com.

Citation

If you use our code, please cite our paper:

@misc{gu2026needtensorcoresstencil,
      title={Do We Need Tensor Cores for Stencil Computations?}, 
      author={Qiqi Gu and Chenpeng Wu and Heng Shi and Jianguo Yao and Haibing Guan},
      year={2026},
      eprint={2603.00477},
      archivePrefix={arXiv},
      primaryClass={cs.DC},
      url={https://arxiv.org/abs/2603.00477}, 
}

The artifact also includes SPIDER code used for sparse Tensor Core stencil evaluation. If you use this part of the code, please also cite:

@inproceedings{10.1145/3774934.3786414,
author = {Gu, Qiqi and Wu, Chenpeng and Shi, Heng and Yao, Jianguo},
title = {SPIDER: Unleashing Sparse Tensor Cores for Stencil Computation via Strided Swapping},
year = {2026},
isbn = {9798400723100},
publisher = {Association for Computing Machinery},
address = {New York, NY, USA},
url = {https://doi.org/10.1145/3774934.3786414},
doi = {10.1145/3774934.3786414},
abstract = {Recent research has focused on accelerating stencil computations by exploiting emerging hardware like Tensor Cores. To leverage these accelerators, the stencil operation must be transformed to matrix multiplications. However, this transformation introduces undesired sparsity into the kernel matrix, leading to significant redundant computation. In this paper, we present SPIDER, the first system to turn this unresolved sparsity into an optimization opportunity by exploring the potential of Sparse Tensor Cores (SpTCs) for stencil acceleration. Specifically, SPIDER introduces an efficient and elegant transformation method that integrates two cooperative techniques: an ahead-of-time strided swapping transformation for kernel matrices and an on-the-fly row-swapping mechanism for inputs. This rule-based approach effectively transforms stencil computation into operations compatible with SpTCs, introducing only slight compile-time overhead and zero runtime overhead. Additionally, SPIDER incorporates multiple optimizations to maximize computational efficiency. Experimental evaluations demonstrate that SPIDER outperforms vendor library cuDNN by 6.23\texttimes{} and state-of-the-art (SOTA) Tensor Core-based approaches (ConvStencil, FlashFFTStencil, etc.) by 1.98\texttimes{} on average.},
booktitle = {Proceedings of the 31st ACM SIGPLAN Annual Symposium on Principles and Practice of Parallel Programming},
pages = {218–231},
numpages = {14},
keywords = {Sparse Tensor Core, Stencil Computation, Structured Sparsity},
location = {Sydney, NSW, Australia},
series = {PPoPP '26}
}