Pith. sign in

REVIEW 3 major objections 3 minor 2 cited by

QiMeng-TensorOp: Automatically Generating High-Performance Tensor Operators with Hardware Primitives

T0 review · 3 major / 3 minor · reviewed 2026-08-15 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read This paper claims that an LLM steered by hardware hints and LLM-guided tree search can generate assembly-level tensor operators from a one-line prompt, outperforming expert-tuned vendor libraries on several platforms.

desk verdict A promising LLM-based pipeline for assembly-level tensor operators, with benchmark claims that currently rest on unstated precision and configuration details. read the letter →

arxiv 2505.06302 v1 pith:Q5GDKB3M submitted 2025-05-08 cs.LG cs.AI

Xuzhi Zhang , Shaohui Peng , Qirui Zhou , Yuanbo Wen , Qi Guo , Ruizhi Chen , Xinguo Zhu , Weiqiang Xiong
show 7 more authors
Haixin Chen Congying Ma Ke Gao Chen Zhao Yanjun Wu Yunji Chen Ling Li
This is my paper · ORCID
classification cs.LGcs.AI
keywords tensoroperatorgenerationhardwareprimitivesLLMcodeMonteCarlotreesearchauto-tuningRISC-VvectorextensionCUDACoreGEMMconvolution
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

QiMeng-TensorOp is a framework for turning a single user sentence—"generate a 1024×1024×1024 GEMM for the RISC-V C910"—into a kernel built from hardware primitives such as RISC-V vector instructions, ARM NEON, or CUDA Tensor Core intrinsics. The paper argues that generic optimization hints plus hardware factors extracted from manuals are enough to make an LLM write the low-level code it cannot normally produce, and that an LLM-guided Monte Carlo tree search then tunes the kernel to or beyond the performance of expert-tuned libraries. On the tested platforms the generated kernels reach up to 251% of OpenBLAS on RISC-V CPUs and 124% of cuBLAS on NVIDIA GPUs, while beating TVM and cutting development time by up to 200×. The load-bearing comparison is raw throughput against vendor baselines, so the speedup claims stand or fall on whether the measurements were made under identical precision and configuration.

What carries the argument

The machinery is a three-stage pipeline. First, Hardware Architecture Comprehending injects a generic description of five optimization techniques (tiling, reordering, vectorization, layout, pipeline) and their relation to four hardware factors (memory hierarchy, instructions, registers, streaming processors), then retrieves the target chip's factors from its manual. Second, Tensor Operator Generation has the LLM write a C or CUDA C++ sketch that handles tiling, reordering, and layout, and then—because LLMs write Python more reliably than assembly—write a Python script that emits the PACK and COMPUTE microkernels as assembly or PTX-level code. Third, Auto-Tuning runs an LLM-assisted Monte Carlo tree search over sketch parameters and instruction order, using the search history as in-context context for choosing the next tuning action. The load-bearing object is the Python-script bridge: it converts the LLM's strength at high-level code into correct low-level kernels.

What would settle it

Inspect the generated A100 kernel and the cuBLAS baseline configuration: reported throughput near 293 TFLOPS implies Tensor Core reduced-precision arithmetic, so if the cuBLAS row was measured at a different precision or with different tensor-core settings, the 1.24× ratio is not a like-for-like comparison. Re-running both at the same precision and recording the configuration would settle the claim.

Watch

Extended reading notes

Core claim

The paper's central claim is that a modern LLM, given only a one-line prompt describing an operator and a target processor, can be prompted into producing kernels written in the machine's own hardware primitives—RISC-V vector assembly, ARM NEON, or CUDA Tensor Core code—and that those kernels can be tuned automatically to match or beat hand-optimized vendor libraries. The reported evidence is kernel throughput on GEMM and convolution across RISC-V, ARM, and NVIDIA platforms: up to 2.51× OpenBLAS on RISC-V, up to 1.21× ACL on ARM, up to 1.24× cuBLAS and 3.89× cuDNN on NVIDIA GPUs, and up to 1.38× (GEMM) and 2.43× (Conv) over TVM. The paper also reports that the same framework outperforms a vanilla LLM prompt by up to 1291× and cuts the development time of a senior engineer from several days to under twenty minutes. The reason this matters is that manual or compiler-based optimization of tensor operators is the bottleneck to deploying neural workloads on new hardware, and the framework proposes to replace months of expert tuning with a prompt and a search loop.

Load-bearing premise

The speedup claims assume the generated kernels and the vendor libraries were benchmarked under identical precision, thread counts, compiler flags, and clock settings, since Table 1 reports only raw GFLOPS/TFLOPS.

Editorial extensions

If this is right

  • The pipeline replaces months of manual assembly tuning: a senior engineer's several-day effort for one GEMM is compressed to under twenty minutes per platform, with up to 200× cost reduction reported.
  • The benefit is largest where vendor libraries are weakest: RISC-V GEMMs reach 2.51× OpenBLAS, while mature ARM and NVIDIA libraries are merely matched or slightly exceeded (1.02–1.21× ACL, 0.98–1.24× cuBLAS).
  • Because the same prompts and pipeline cover GEMM and Conv on CPUs and GPUs, the method is operator- and platform-generic rather than a single handcrafted kernel.
  • The auto-tuning component improves even hand-written OpenBLAS C code, indicating that the LLM-guided MCTS search is a separable optimization layer, not just a code-generation trick.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Beyond the paper: the technique of asking the LLM to write a Python script that emits assembly, rather than writing assembly directly, is a general pattern—LLMs may be more reliable as code-generator generators than as low-level coders, and the same bridge could apply to other instruction sets.
  • Beyond the paper: if the speedups survive controlled benchmarking, the main practical consequence is that compiler backends and handwritten microkernels become optional: a prompt plus a manual and a search loop could substitute for much of the engineering in deployment on a new processor.
  • Beyond the paper: a direct test of generality would be applying the three-step pipeline to non-GEMM kernels such as attention, softmax, or layer norm under the same one-line prompts; the paper states this as future work but does not report results.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 3 minor

Summary. The paper proposes QiMeng-TensorOp, an LLM-based framework that generates hardware-primitive-level tensor operators (CPU assembly, CUDA Tensor Core kernels via CuTe/PTX) from a one-line user prompt. The framework has three stages: hardware architecture comprehension (optimization hints plus hardware factor extraction), tensor operator generation (C/CUDA sketch plus Python-script-generated assembly/CuTe kernels), and LLM-assisted MCTS auto-tuning. The authors evaluate on RISC-V, ARM, and NVIDIA GPUs with GPT-4o, DeepSeek-V3, Claude 3.5 Sonnet, and Llama-3.1-405B, comparing against vanilla prompts, CoT prompts, OpenBLAS, ACL, cuBLAS, cuDNN, and TVM. Headline claims are up to 1291× over vanilla prompting, 2.51× over OpenBLAS on RISC-V, 1.24× over cuBLAS on A100, and a 200× development-cost reduction relative to human engineers.

Significance. If the performance claims are correct, this would be a notable advance: it would demonstrate that an LLM with structured hints, few-shot examples, and MCTS-guided tuning can produce assembly-level or Tensor-Core-level kernels that match or exceed expert-tuned vendor libraries across diverse hardware, while dramatically reducing development cost. The framework is well-motivated, the system design is coherent, and the ablation studies (prompt types, component removal, search history) are a genuine strength. The paper also evaluates on multiple hardware platforms and multiple LLMs, which supports generality. However, the significance cannot be fully assessed because the central evaluation lacks the measurement precision, baseline configuration, and correctness criteria needed to verify the speedup ratios. The reported A100 numbers imply Tensor-Core reduced-precision execution, yet the precision and math mode of both the generated kernels and the cuBLAS baselines are never stated; this is load-bearing for the paper's core claim of outperforming vendor libraries.

major comments (3)
  1. [Section 4.2, Table 1 (A100 rows)] The A100 rows report 260–293 TFLOPS for QiMeng-TensorOp. The A100 FP32 non-tensor peak is roughly 19.5 TFLOPS, so these kernels must be executing in a Tensor-Core reduced-precision mode (FP16, BF16, or TF32). The paper never states the arithmetic precision or CUDA math mode used by either the generated kernels or the cuBLAS baseline. Without this information, the claim of '124% of cuBLAS' is not an apples-to-apples comparison, and the central speedup claim over cuBLAS is unverified.
  2. [Section 4.1 and Table 1 (CPU comparisons)] For the CPU evaluations, the paper does not report thread counts, compiler flags, CPU frequency scaling or governor settings, or the exact build/configuration of OpenBLAS, ACL, and TVM (e.g., whether RVV/NEON extensions were enabled, single-threaded versus multithreaded BLAS builds). Since the claimed 2.51× over OpenBLAS on K1 and 1.21× over ACL on A72 are head-to-head ratios, the absence of these configuration details makes the CPU speedups impossible to reproduce or fully validate from the manuscript.
  3. [Sections 3.2 and 3.3 (correctness criterion)] The method section states that generated sketches and kernels are 'jointly compiled and tested on the target hardware to obtain feedback' and that the MCTS simulation 'tests the tensor operator ... to obtain an initial performance value,' but no numerical correctness criterion is specified anywhere. A kernel that compiles, terminates, and runs quickly while returning incorrect results would pass the described test. The paper should state the reference implementation and error tolerance (e.g., maximum relative error against OpenBLAS/cuBLAS) used to accept or reject each generated operator, since the performance claims presume the generated kernels compute the target operation correctly.
minor comments (3)
  1. [Section 4.2, Figure 3] The Conv results are presented only as a figure with no numeric table, and the figure content is not described in the text; adding a table or explicit numeric values would make the Conv claims checkable.
  2. [Appendices] The text repeatedly refers to Appendices A, B, and C (additional results, MCTS pseudo-code, and a detailed showcase), but these appendices are not included in the submitted manuscript, so the reader cannot inspect the tuning algorithm or the claimed example generation.
  3. [Throughout] There are several typos and wording issues, e.g., 'a detaled' in the Section 3 overview caption, 'tensor operates' in the ablation discussion, and inconsistent use of 'vanilla prompt' versus 'vanilla LLMs' in the abstract; these should be cleaned up during revision.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: headline speedups are measured against external libraries (OpenBLAS, cuBLAS, TVM), not derived from the framework's own parameters or definitions.

full rationale

QiMeng-TensorOp's central claims are empirical benchmarks against external baselines. Section 4.2 states: 'On the RISC-V CPUs, QiMeng-TensorOp achieves up to 2.51× performance enhancement over OpenBLAS' and 'on NVIDIA GPUs ... achieves comparable or higher performance of cuBLAS and cuDNN in most dimensions (up to 1.24× for GEMM and 3.89× for Conv)'. These numbers are measured on target hardware after the Section 3.3 MCTS tuning loop, which 'Simulation tests the tensor operator of the newly expanded node to obtain an initial performance value' — i.e., a measured search result, not a quantity reconstructed from the method's own inputs. The comparison baselines (vanilla prompt, CoT, TVM, OpenBLAS, ACL, cuBLAS/cuDNN) are external to the framework, so no prediction is equivalent by construction to a fitted parameter. The authors' hardware hints and few-shot examples embed expert knowledge in the prompt, but this is prompt engineering, not a derivation of the measured speedups; the speedups still require execution on real hardware and comparison with independent libraries. The one related-work citation sharing an author (Bi et al. 2023, which includes co-author Qi Guo) appears only in a list of auto-compiler systems and is not used to justify the framework's central claim. The main threat to the headline numbers is not circularity but uncontrolled benchmark comparability: precision (FP32 vs FP16/BF16/TF32), thread counts, and library configurations are not reported, and the A100 values (~260–293 TFLOPS) cannot be strict FP32 GEMM, so the cuBLAS comparison may not be apples-to-apples. That is a correctness and validity concern, not a circularity concern. Accordingly no circular step is identified.

Assumptions & free parameters 3 free parameters · 3 assumptions · 0 invented entities

The central claim is empirical and system-level, so the axiom ledger is small. The main free parameters are autotuning choices, and the key assumptions concern LLM reliability and the comparability of the benchmarking setup. There are no new physical entities or mathematical postulates.

free parameters (3)
  • Tile sizes BM, BN, BK = Varies per platform and shape, e.g., adjusted in increments of 32
    Auto-Tuning adjusts matrix tiling sizes in the generated sketches through MCTS. These values are fitted to maximize observed performance on the target hardware and are not derived from a performance model.
  • Micro-kernel register blocking and pipeline stage counts = Not explicitly disclosed
    The Python scripts that print assembly kernels encode choices such as vector register allocation and load/compute/store interleaving. These are tuned by the search and influenced by few-shot examples, making them hand-selected or search-fitted parameters.
  • MCTS hyperparameters (UCB constant, expansion candidate count) = Not reported
    The MCTS algorithm has constants and action-space sizes that are chosen by the authors and affect tuning efficiency and final performance. No sensitivity analysis is provided.
assumptions (3)
  • domain assumption General-purpose LLMs are capable of producing correct assembly or Python scripts that generate assembly when given hardware hints and few-shot examples.
    The entire framework rests on this capability, supported only by the successful runs reported in Section 4. There is no formal guarantee or systematic error analysis beyond compile-and-run checks.
  • domain assumption The five optimization techniques (tiling, reordering, vectorization, layout, pipeline) and four hardware factors (memory hierarchy, instructions, vector/scalar registers, streaming processors) form a sufficient abstraction for high-performance tensor operator generation across the tested ISAs.
    Section 2 presents this taxonomy as complete, but no ablation shows whether, for example, removing the pipeline optimization would break the claimed performance on a given platform.
  • domain assumption A single compile-run-measure cycle on target hardware gives a stable and unbiased estimate of operator performance.
    Section 3.2 uses compile-and-run as the correctness and performance oracle, but there is no discussion of run-to-run variance, frequency scaling, thermal limiting, or measurement methodology.

how reviews work

0 comments
Cite this review

Pith. "Pith review of QiMeng-TensorOp: Automatically Generating High-Performance Tensor Operators with Hardware Primitives." pith.science (2026). https://pith.science/paper/Q5GDKB3M

@misc{pith2026250506302,
  author       = {Pith},
  title        = {Pith review of: QiMeng-TensorOp: Automatically Generating High-Performance Tensor Operators with Hardware Primitives},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/Q5GDKB3M}},
  note         = {Machine review of arXiv:2505.06302}
}
abstract

Computation-intensive tensor operators constitute over 90\% of the computations in Large Language Models (LLMs) and Deep Neural Networks.Automatically and efficiently generating high-performance tensor operators with hardware primitives is crucial for diverse and ever-evolving hardware architectures like RISC-V, ARM, and GPUs, as manually optimized implementation takes at least months and lacks portability.LLMs excel at generating high-level language codes, but they struggle to fully comprehend hardware characteristics and produce high-performance tensor operators. We introduce a tensor-operator auto-generation framework with a one-line user prompt (QiMeng-TensorOp), which enables LLMs to automatically exploit hardware characteristics to generate tensor operators with hardware primitives, and tune parameters for optimal performance across diverse hardware. Experimental results on various hardware platforms, SOTA LLMs, and typical tensor operators demonstrate that QiMeng-TensorOp effectively unleashes the computing capability of various hardware platforms, and automatically generates tensor operators of superior performance. Compared with vanilla LLMs, QiMeng-TensorOp achieves up to $1291 \times$ performance improvement. Even compared with human experts, QiMeng-TensorOp could reach $251 \%$ of OpenBLAS on RISC-V CPUs, and $124 \%$ of cuBLAS on NVIDIA GPUs. Additionally, QiMeng-TensorOp also significantly reduces development costs by $200 \times$ compared with human experts.

Figures

Figures reproduced from arXiv: 2505.06302 by the authors.

Figure 1
Figure 1. Comparison of tensor operator optimization paradigms [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. QiMeng-TensorOp overview. The proposed framework takes a user’s one-sentence description as input and generates high￾performance tensor operators using hardware primitives via three automatic steps. Step 1 activates LLMs’ comprehension of tensor operator optimization and extracts target hardware factors for subsequent generation. In Step 2, sketches and kernels are generated to form tensor operators. Sketch generati… view at source ↗
Figure 3
Figure 3. Conv operator performance comparison at the hardware-primitive-level to fully leverage hardware characteristics, thereby achieving higher performance. For instance, when the matrix dimension is 1024 × 4096 × 4096 on A76 CPU, our method performance is 1.31 × and 1.29 × better than TVM and ACL, respectively. 4.3 Ablation Study To analyze the effectiveness of each component in QiMeng￾TensorOp and its efficiency, we con… view at source ↗
Figures from the paper (2 more)
Figure 4
Figure 4. Figure 4: (a) Ablation results of QiMeng-TensorOp components for [PITH_FULL_IMAGE:figures/full_fig_p007_4.png]
Figure 5
Figure 5. Figure 5: (a) Development cost comparison on GEMM of size 1024 [PITH_FULL_IMAGE:figures/full_fig_p008_5.png]

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 2 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. Towards Automated Kernel Generation in the Era of LLMs

    cs.LG 2026-01 conditional novelty 4.0 of 10

    A structured survey of LLM-based and agentic approaches for GPU kernel generation, plus a catalog of datasets and benchmarks for the field.

  2. QiMeng: Fully Automated Hardware and Software Design for Processor Chip

    cs.AR 2025-06 conditional novelty 4.0 of 10

    QiMeng is a proposed three-layer architecture for automating processor hardware and software design, with several published components but no integrated implementation yet.

Reference graph

Works this paper leans on

49 extracted references · 39 canonical work pages · cited by 2 Pith papers

  1. [1]

    Precision-energy-throughput scal- ing of generic matrix multiplication and discrete convolu- tion kernels via linear projections

    [Anam et al., 2013] Ashraful Anam, Paul Whatmough, and Yiannis Andreopoulos. Precision-energy-throughput scal- ing of generic matrix multiplication and discrete convolu- tion kernels via linear projections. In The 11th IEEE Sym- posium on Embedded Systems for Real-time Multimedia , pages 21–30. IEEE,

    work page 2013

  2. [8]

    Nvidia A100 Tensor Core GPU: Performance and innovation

    [Choquette et al., 2021] Jack Choquette, Wishwesh Gandhi, and Olivier Giroux et al. Nvidia A100 Tensor Core GPU: Performance and innovation. IEEE Micro, 41(2):29–35,

    work page 2021

  3. [9]

    Claude 3.5 Sonnet

    [Claude3.5, 2024] Claude3.5. Claude 3.5 Sonnet. https: //www.anthropic.com/news/claude-3-5-sonnet,

    work page 2024

  4. [11]

    DeepSeek-V3 Technical Report

    [DeepSeek-AI et al., 2024] DeepSeek-AI, Aixin Liu, and Bing Xue et al. DeepSeek-V3 Technical Report

    work page 2024

  5. [12]

    Flexible Performant GEMM Kernels on GPUs

    [Faingnaert et al., 2021] Thomas Faingnaert, Tim Besard, and Bjorn De Sutter. Flexible Performant GEMM Kernels on GPUs. IEEE Transactions on Parallel and Distributed Systems, 33(9):2230–2248,

    work page 2021

  6. [13]

    Tensorir: An abstraction for automatic tensorized program optimization

    [Feng et al., 2023] Siyuan Feng, Bohan Hou, and Hongyi Jin et al. Tensorir: An abstraction for automatic tensorized program optimization. In Proceedings of the 28th ACM In- ternational Conference on Architectural Support for Pro- gramming Languages and Operating Systems, Volume 2 , pages 804–817,

    work page 2023

  7. [14]

    The Llama 3 Herd of Models

    [Grattafiori et al., 2024] Aaron Grattafiori, Abhima Dubey, and Abhinav Jauhri et al. The Llama 3 Herd of Models. ArXiv abs/2407.21783,

    arXiv 2024

  8. [15]

    Automatic generation of ARM NEON micro-kernels for matrix multiplication

    [Guillermo et al., 2024] Alae Guillermo, Mart ´ınez H ´ector, and Castell´o Adri´an et al. Automatic generation of ARM NEON micro-kernels for matrix multiplication. The Jour- nal of Supercomputing, pages 1–27,

    work page 2024

Show all 49 references
  1. [16]

    Textbooks Are All You Need

    [Gunasekar et al., 2023] Suriya Gunasekar, Yi Zhang, and Jyoti Aneja et al. Textbooks Are All You Need. ArXiv abs/2306.11644,

    2023 arXiv

  2. [17]

    Deep Residual Learning for Image Recognition

    [He et al., 2015] Kaiming He, Xiangyu Zhang, Shaoqing Ren, and Jian Sun. Deep Residual Learning for Image Recognition. ArXiv abs/1512.03385,

    2015 arXiv

  3. [20]

    In-datacenter performance analysis of a tensor processing unit

    [Jouppi et al., 2017] Norman P Jouppi, Cliff Young, and Nis- hant Patil et al. In-datacenter performance analysis of a tensor processing unit. In Proceedings of the 44th annual international symposium on computer architecture, pages 1–12,

    2017

  4. [22]

    Exploit- ing Intel® Advanced Matrix Extensions (AMX) for Large Language Model Inference

    [Kim et al., 2024] Hyungyo Kim, Gaohan Ye, Nachuan Wang, Amir Yazdanbakhsh, and Nam Sung Kim. Exploit- ing Intel® Advanced Matrix Extensions (AMX) for Large Language Model Inference. IEEE Computer Architecture Letters,

    2024

  5. [23]

    oneAPI Open-Source Math Library Interface

    [Krainiuk et al., 2021] Mariia Krainiuk, Mehdi Goli, and Vincent R Pascuzzi. oneAPI Open-Source Math Library Interface. In 2021 International Workshop on Perfor- mance, Portability and Productivity in HPC (P3HPC) , pages 22–32. IEEE,

    2021

  6. [24]

    Autotuning GEMM kernels for the Fermi GPU

    [Kurzak et al., 2012] Jakub Kurzak, Stanimire Tomov, and Jack Dongarra. Autotuning GEMM kernels for the Fermi GPU. IEEE Transactions on Parallel and Distributed Sys- tems, 23(11):2045–2057,

    2012

  7. [26]

    Cambricon: An instruction set architecture for neural networks

    [Liu et al., 2016] Shaoli Liu, Zidong Du, and Jinhua Tao et al. Cambricon: An instruction set architecture for neural networks. ACM SIGARCH Computer Architecture News, 44(3):393–405,

    2016

  8. [28]

    Introducing Llama 3.1: Our most capable models to date

    [Llama3.1, 2024] Llama3.1. Introducing Llama 3.1: Our most capable models to date. https://ai.meta.com/blog/ meta-llama-3-1/,

    2024

  9. [29]

    [Lu et al., 2022] Shuai Lu, Nan Duan, Hojae Han, Daya Guo, Seung won Hwang, and Alexey Svyatkovskiy

    Accessed: 2024-12-27. [Lu et al., 2022] Shuai Lu, Nan Duan, Hojae Han, Daya Guo, Seung won Hwang, and Alexey Svyatkovskiy. ReACC: A Retrieval-Augmented Code Completion Framework. ArXiv abs/2203.07722,

    2024 arXiv

  10. [30]

    NVIDIA Tensor Core Programmabil- ity, Performance & Precision

    [Markidis et al., 2018] Stefano Markidis, Der Chien, and Steven Wei et al. NVIDIA Tensor Core Programmabil- ity, Performance & Precision. In 2018 IEEE international parallel and distributed processing symposium workshops (IPDPSW), pages 522–531. IEEE,

    2018

  11. [31]

    CUBLAS LIBRARY user guide v12.1

    [NVIDIA, 2023] NVIDIA. CUBLAS LIBRARY user guide v12.1. https://docs.nvidia.com/cuda/archive/12.1.0,

    2023

  12. [32]

    [OpenAI, 2025] OpenAI

    Accessed: 2024-07-22. [OpenAI, 2025] OpenAI. GPT-4o. https://openai.com/index/ hello-gpt-4o/,

    2024

  13. [34]

    U-Net: Convolutional Networks for Biomedical Image Segmentation,

    [Ronneberger et al., 2015] Olaf Ronneberger, Philipp Fis- cher, and Thomas Brox. U-Net: Convolutional Networks for Biomedical Image Segmentation,

    2015

  14. [35]

    Code Llama: Open Foundation Models for Code

    [Rozi`ere et al., 2023] Baptiste Rozi `ere, Jonas Gehring, and Fabian Gloeckle et al. Code Llama: Open Foundation Models for Code. ArXiv, abs/2308.12950,

    2023 arXiv

  15. [36]

    Tensor program optimization with probabilistic pro- grams

    [Shao et al., 2022] Junru Shao, Xi Zhou, and Siyuan Feng et al. Tensor program optimization with probabilistic pro- grams. Advances in Neural Information Processing Sys- tems, 35:35783–35796,

    2022

  16. [37]

    Very Deep Convolutional Networks for Large-Scale Image Recognition

    [Simonyan and Zisserman, 2015] Karen Simonyan and An- drew Zisserman. Very Deep Convolutional Networks for Large-Scale Image Recognition. ArXiv abs/1409.1556 ,

    2015 arXiv

  17. [38]

    Efficient processing of deep neural net- works: A tutorial and survey

    [Sze et al., 2017] Vivienne Sze, Yu-Hsin Chen, and Tien- Ju Yang et al. Efficient processing of deep neural net- works: A tutorial and survey. Proceedings of the IEEE , 105(12):2295–2329,

    2017

  18. [39]

    Fast implementation of DGEMM on Fermi GPU

    [Tan et al., 2011] Guangming Tan, Linchuan Li, and Sean Triechle et al. Fast implementation of DGEMM on Fermi GPU. In Proceedings of 2011 International Con- ference for High Performance Computing, Networking, Storage and Analysis, pages 1–11,

    2011

  19. [41]

    Chain-of-Thought Prompting Elicits Rea- soning in Large Language Models

    [Wei et al., 2022] Jason Wei, Xuezhi Wang, and Dale Schu- urmans et al. Chain-of-Thought Prompting Elicits Rea- soning in Large Language Models. Advances in neural information processing systems, 35:24824–24837,

    2022

  20. [42]

    The storage hierarchy is not a hierarchy: Optimiz- ing caching on modern storage devices with orthus

    [Wu et al., 2021] Kan Wu, Zhihan Guo, and Guanzhou Hu et al. The storage hierarchy is not a hierarchy: Optimiz- ing caching on modern storage devices with orthus. In 19th USENIX Conference on File and Storage Technolo- gies (FAST 21), pages 307–323,

    2021

  21. [43]

    autoGEMM: Pushing the Limits of Irregular Matrix Mul- tiplication on Arm Architectures

    [Wu et al., 2024] Du Wu, Jintao Meng, and Wenxi Zhu et al. autoGEMM: Pushing the Limits of Irregular Matrix Mul- tiplication on Arm Architectures. In SC24: International Conference for High Performance Computing, Network- ing, Storage and Analysis, pages 1–15. IEEE,

    2024

  22. [44]

    Model-driven level 3 BLAS performance opti- mization on Loongson 3A processor

    [Xianyi et al., 2012] Zhang Xianyi, Wang Qian, and Zhang Yunquan. Model-driven level 3 BLAS performance opti- mization on Loongson 3A processor. In 2012 IEEE 18th international conference on parallel and distributed sys- tems, pages 684–691. IEEE,

    2012

  23. [45]

    Hasco: Towards agile hardware and software co-design for tensor computation

    [Xiao et al., 2021] Qingcheng Xiao, Size Zheng, and Bingzhe Wu et al. Hasco: Towards agile hardware and software co-design for tensor computation. In 2021 ACM/IEEE 48th Annual International Symposium on Computer Architecture (ISCA) , pages 1055–1068. IEEE,

    2021

  24. [46]

    Large Language Models Meet NL2Code: A Survey

    [Zan et al., 2022] Daoguang Zan, Bin Chen, and Fengji Zhang et al. Large Language Models Meet NL2Code: A Survey. In Annual Meeting of the Associa- tion for Computational Linguistics,

    2022

  25. [47]

    TLP: A Deep Learning-Based Cost Model for Tensor Pro- gram Tuning

    [Zhai et al., 2023] Yi Zhai, Yu Zhang, and Shuo Liu et al. TLP: A Deep Learning-Based Cost Model for Tensor Pro- gram Tuning. In Proceedings of the 28th ACM Interna- tional Conference on Architectural Support for Program- ming Languages and Operating Systems, Volume 2, pages 833–845,

    2023

  26. [48]

    Enabling Tensor Language Model to Assist in Generating High-Performance Tensor Programs for Deep Learning

    [Zhai et al., 2024] Yi Zhai, Sijia Yang, and Keyu Pan et al. Enabling Tensor Language Model to Assist in Generating High-Performance Tensor Programs for Deep Learning. In 18th USENIX Symposium on Operating Systems Design and Implementation (OSDI 24), pages 289–305,

    2024

  27. [49]

    Ansor: Generating High-Performance Ten- sor Programs for Deep Learning

    [Zheng et al., 2020] Lianmin Zheng, Chengfan Jia, and Min- min Sun et al. Ansor: Generating High-Performance Ten- sor Programs for Deep Learning. In 14th USENIX sym- posium on operating systems design and implementation (OSDI 20), pages 863–879, 2020

    2020

  28. [2011]

    LLaMA: Open and Efficient Foun- dation Language Models

    [Touvron et al., 2023] Hugo Touvron, Thibaut Lavril, and Gautier Izacard et al. LLaMA: Open and Efficient Foun- dation Language Models. ArXiv abs/2302.13971,

    2023 arXiv

  29. [2012]

    StarCoder: may the source be with you! ArXiv, abs/2305.06161,

    [Li et al., 2023] Raymond Li, Loubna Ben, and Yangtian Zi et al. StarCoder: may the source be with you! ArXiv, abs/2305.06161,

    2023 arXiv

  30. [2013]

    Multi-lingual Evaluation of Code Generation Models

    [Athiwaratkun et al., 2022] Ben Athiwaratkun, Sanjay Gouda, and Zijian Wang et al. Multi-lingual Evaluation of Code Generation Models. ArXiv abs/2210.14868,

    2022 arXiv

  31. [2015]

    A new golden age for computer architecture

    [Hennessy and Patterson, 2019] John Hennessy and David Patterson. A new golden age for computer architecture. Communications of the ACM, 62(2):48–60,

    2019

  32. [2016]

    High-Performance Tensor Learning Primitives Using GPU Tensor Cores

    [Liu et al., 2022] Xiao-Yang Liu, Zeliang Zhang, and Zhiyuan Wang et al. High-Performance Tensor Learning Primitives Using GPU Tensor Cores. IEEE Transactions on Computers, 72(6):1733–1746,

    2022

  33. [2017]

    High performance GPU code gener- ation for matrix-matrix multiplication using mlir: some early results

    [Katel et al., 2021] Navdeep Katel, Vivek Khandelwal, and Uday Bondhugula. High performance GPU code gener- ation for matrix-matrix multiplication using mlir: some early results. arXiv preprint arXiv:2108.13191,

    2021 arXiv

  34. [2018]

    Xuantie-910: A Commercial Multi- Core 12-Stage Pipeline Out-of-Order 64-bit High Per- formance RISC-V Processor with Vector Extension

    [Chen et al., 2020a] Chen Chen, Xiaoyan Xiang, and Chang Liu et al. Xuantie-910: A Commercial Multi- Core 12-Stage Pipeline Out-of-Order 64-bit High Per- formance RISC-V Processor with Vector Extension. In 2020 ACM/IEEE 47th Annual International Symposium on Computer Architect...

    2020

  35. [2019]

    Automatic Generation of Micro-kernels for Performance Portability of Matrix Multiplication on RISC-V Vector Processors

    [Igual et al., 2023] Francisco Igual, Luis Pi ˜nuel, and San- dra Catal´an et al. Automatic Generation of Micro-kernels for Performance Portability of Matrix Multiplication on RISC-V Vector Processors. In Proceedings of the SC’23 Workshops of The International Conference on Hi...

    2023

  36. [2020]

    Experiments and optimizations for TVM on RISC-V Architectures with P Extension

    [Chen et al., 2020b] Yi-Ru Chen, Hui-Hsin Liao, and Chia- Hsuan Chang et al. Experiments and optimizations for TVM on RISC-V Architectures with P Extension. In 2020 International Symposium on VLSI Design, Automation and Test (VLSI-DAT), pages 1–4,

    2020

  37. [2021]

    Heron: Automatically Constrained High-Performance Li- brary Generation for Deep Learning Accelerators

    [Bi et al., 2023] Jun Bi, Qi Guo, and Xiaqing Li et al. Heron: Automatically Constrained High-Performance Li- brary Generation for Deep Learning Accelerators. In Pro- ceedings of the 28th ACM International Conference on Ar- chitectural Support for Programming Languages and Op-...

    2023

  38. [2022]

    Program Synthesis with Large Lan- guage Models

    [Austin et al., 2021] Jacob Austin, Augustus Odena, and Maxwell Nyen et al. Program Synthesis with Large Lan- guage Models. ArXiv, abs/2108.07732,

    2021 arXiv

  39. [2023]

    Tackling the Matrix Multiplication Micro-Kernel Generation with Exo

    [Castell´o et al., 2024] Adri´an Castell ´o, Julian Bellavita, and Grace Dinh et al. Tackling the Matrix Multiplication Micro-Kernel Generation with Exo. In 2024 IEEE/ACM International Symposium on Code Generation and Opti- mization (CGO), pages 182–193. IEEE,

    2024

  40. [2024]

    [Dally et al., 2021] William J Dally, Stephen W Keckler, and David B Kirk

    Ac- cessed: 2024-12-27. [Dally et al., 2021] William J Dally, Stephen W Keckler, and David B Kirk. Evolution of the graphics processing unit (GPU). IEEE Micro, 41(6):42–51,

    2024

  41. [2025]

    [Ragan et al., 2013] Jonathan Ragan, Connelly Barnes, and Andrew Adams et al

    Accessed: 2024-12-27. [Ragan et al., 2013] Jonathan Ragan, Connelly Barnes, and Andrew Adams et al. Halide: a language and com- piler for optimizing parallelism, locality, and recomputa- tion in image processing pipelines. Acm Sigplan Notices, 48(6):519–530,

    2024

Pith tools

Reviewed August 15, 2026 · model on record in the stance chip above.