Pith. sign in

REVIEW 5 major objections 7 minor 45 references

HPCTransCompile: An AI Compiler Generated Dataset for High-Performance CUDA Transpilation and LLM Preliminary Exploration

T0 review · 5 major / 7 minor · reviewed 2026-08-07 · deepseek-v4-flash

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

Pith's one-line read Fine-tuning code models on compiler-generated CUDA-CPU pairs improves translated CPU kernels' speedup by an average of 43.8%.

desk verdict A promising pipeline for generating CUDA-CPU training data via TVM, but the headline speedup is undercut by questionable dataset correctness and inconsistent metric definitions. read the letter →

arxiv 2506.10401 v2 pith:RC4RRPX5 submitted 2025-06-12 cs.DC cs.AI

Jiaqi Lv , Xufeng He , Yanchen Liu , Xu Dai , Aocheng Shen , Yinghao Li , Jiachen Hao , Jianrong Ding
show 2 more authors
Yang Hu Shouyi Yin
This is my paper
classification cs.DCcs.AI
keywords CUDAtranspilationhigh-performancecomputingLLMfine-tuningTVMauto-schedulerperformanceportabilitycodegenerationdatasetHPCTransEvalKernelBench
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

This paper claims that the main obstacle to good CUDA-to-CPU translation by large language models is not model capability but the absence of high-quality training pairs, and that a compiler can supply those pairs automatically. Using the TVM compiler's auto-scheduler, the authors generate 20,000 matched high-performance CUDA and CPU C code pairs, strip the CPU code of compiler-library dependencies, and add graph-based augmentation to widen coverage. After LoRA fine-tuning on this dataset, three open code models produce CPU translations that are more often compilable and correct, with a 43.8% average improvement in CPU speedup ratio. The paper also releases HPCTransEval, a benchmark of 100 primitive operators, 100 computation graphs, and 10 model building blocks, as an architecture-independent test for CUDA transpilation.

What carries the argument

The generating mechanism is a modified TVM pipeline: TVM's auto-scheduler searches optimal scheduling configurations for each operator or computation graph, then emits a CUDA kernel and a CPU C kernel from the same computation description. The paper strips the CPU code of TVM library dependencies, labels each pair with hardware context and optimization strategy, and builds a source-code evaluation runtime using LLVM ORC JIT to compile and execute translated code in place of the reference kernel. Dataset diversity comes from a graph-based augmentation algorithm that expands operators into directed acyclic computation graphs through random connections, branch expansion, and path merging, while fine-tuning uses LoRA to update only a small fraction of model parameters.

What would settle it

Take a set of hand-verified CUDA kernels with independently computed outputs, run the fine-tuned models on them, and compare the translated CPU code against those independent outputs and against hand-optimized CPU references; if execute-pass rates or speedups fall to baseline once the compiler's output is no longer the oracle, the claimed gains would be an artifact of the evaluation.

Watch

Extended reading notes

Core claim

The central discovery is that compiler-generated high-performance code pairs provide enough training signal for LLMs to learn hardware-aware CUDA-to-CPU transpilation. On HPCTransEval Level 1, the strongest model's speedup ratio rises from 0.83 before fine-tuning to 2.35 after, with execute pass rising from 0.30 to 0.62; on KernelBench Level 1, the same model's execute pass rises from 0.28 to 0.51 and its speedup ratio from 2.90 to 6.75. The paper attributes the gains to clean, dependency-free code pairs and graph-based augmentation, which let fine-tuned models adopt compiler-style optimizations such as replacing per-thread Mersenne Twister construction with lightweight hash-based randomness and replacing GPU-style shared-memory and tiling patterns with cache-friendly CPU loops.

Load-bearing premise

The translations are judged correct when they match the output of the compiler-generated reference code, so the evaluation inherits whatever numerical behavior, including any bugs, the compiler itself has.

Editorial extensions

If this is right

  • If the central claim is right, LLM-based transpilation can be improved without manual kernel rewrites, by changing the training data rather than the architecture or prompt.
  • Compiler-generated pairs cover operator categories that are hard to curate by hand; the largest measured HPCTransEval gains are on layout-transform operators, reaching 225.9%, and compute-intensive operators, exceeding 340%.
  • Dataset size mostly affects execution speed rather than correctness: correctness plateaus around 5,000 training pairs while speedups continue to improve up to 20,000 pairs.
  • Gains concentrate at the operator and fused-kernel level; the paper reports that HPCTransEval's complex model building blocks do not execute correctly after fine-tuning, marking a clear boundary for current LLM transpilation ability.

Reading between the lines

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

  • The same pipeline should transfer to other backends the compiler supports, such as AMD GPUs or other accelerators, which would turn CUDA-to-platform portability largely into a data-generation problem.
  • Because correctness is judged against the compiler's own reference output, benchmark scores conflate 'translates the computation' with 'reproduces the compiler's numerical choices'; an independent numerical oracle would sharpen the claim.
  • The case-study shift from Mersenne Twister to a hash-based PRNG suggests fine-tuning teaches LLMs compiler-style micro-optimizations; a testable extension is to check whether such substitutions preserve statistical quality in dropout under adversarial seed patterns.
  • The small Level 3 gains suggest model-level translation bottlenecks are about API selection rather than kernel optimization, so adding graph-level pairs with explicit Torch-call choices could extend the method to whole networks.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

5 major / 7 minor

Summary. The paper proposes HPCTransCompile, a framework that uses the TVM compiler and auto-scheduler to generate paired high-performance CUDA and CPU C code, augmented by a graph-based construction method, and introduces HPCTransEval, a benchmark for CUDA-to-CPU transpilation. The authors fine-tune three open-source LLMs (Qwen2.5-Coder-14B, DeepSeek-Coder-V2-Lite, OpenCoder-8B) on 20k generated code pairs using LoRA, and report that fine-tuning improves compile rate, execute rate, and speedup ratio on both HPCTransEval and an extended KernelBench-C benchmark, with the abstract claiming an average speedup-ratio improvement of 43.8%.

Significance. If the generated dataset is semantically correct and the evaluation is sound, the framework is a useful contribution: it provides a scalable method to synthesize transpilation training data from an AI compiler, a new benchmark, and evidence that domain-specific fine-tuning can improve CUDA-to-CPU code quality. The inclusion of KernelBench-C as an external benchmark is a strength, and the paper's overall experimental design (clear before/after comparison, multiple models) is commendable. However, the paper's own Listing 3 shows a concrete indexing error in the dependency-free CPU code, the correctness validation in Section 3.6 is anchored to TVM's own outputs, and the headline average improvement is not defined and appears to use a nonstandard formula. These issues put the central claims of dataset quality and performance improvement into question.

major comments (5)
  1. [§3.3, Listing 3] Listing 3, presented as the 'CPU C code without TVM dependency', is semantically incorrect relative to Listing 2. The inner loop over i2 (0..8) writes compute[i1] = cosf(data[i1*9+i2]) each iteration, so only the last i2 value survives; the output is a reduction over i2 rather than the elementwise cosine shown in Listing 2 and Listing 1. If this listing is representative of the dependency-removal pass output, the 20k training labels in HPCTransData are systematically wrong. Because Section 3.6 validates LLM-generated code only against TVM's own expected results, a model that reproduces the same buggy reduction would pass the Execute Pass check. The authors must correct this example, provide an automated correctness check against an independent reference (e.g., PyTorch CPU or hand-written kernels) for at least a random subset of the dataset, and report how many pairs survive such a check.
  2. [Abstract and §5.2 / Table 4] The headline 'average improvement of 43.8%' in the abstract is not defined anywhere in the paper. The operator-type percentages in Section 5.2 (e.g., 15.5%, 69.9%, 225.9%, 131.5%, 340%) use the standard formula (after-before)/before; averaging these 15 values from Table 4 gives approximately 121%, not 43.8%. I can reproduce 43.8% only by averaging 1 - (before/after) over those same 15 entries. The paper must state the exact formula used for the headline number, report the baseline values, and present standard relative improvements in tables and text.
  3. [§4.2, Tables 2–4, Figures 3–5] No error bars, number of repeated runs, or statistical significance tests are reported for any compile, execute, or speedup metric. Execution time is inherently noisy, and the speedup claims (e.g., M1 Level 1 speedup ratio 2.90 to 6.75 in Table 2) are single-point estimates. The authors should report the mean/median across multiple runs with variance, and state how the execution time was measured (e.g., number of trials, warm-up, Turbo/boost settings). Without this, the speedup improvements cannot be reliably assessed.
  4. [§3.6, §4.1] The evaluation is partially circular: the expected results used to judge correctness come from TVM's own generated code, and HPCTransEval is composed of TVM-generated code, while the training data is also TVM-generated. This means the fine-tuned models may be rewarded for reproducing TVM's compilation artifacts and any TVM errors. The inclusion of KernelBench-C mitigates transfer concerns, but the correctness-validation circularity remains. The authors should validate correctness on a subset against an independent ground-truth implementation (e.g., PyTorch CPU or a manually verified reference) and report the agreement rate.
  5. [§3.3, §4.1, §6] The modified TVM passes and the generated dataset are not made available in sufficient detail: only a repository URL is given, with no commit hash, dataset download link, or description of the modified compilation passes. Because the central contribution is the dataset and benchmark derived from these modifications, and because Listing 3 raises a correctness question, the artifact must be released with versioning and enough implementation detail for the community to reproduce the dependency-removal step and the 20k pairs. The current reproducibility level is insufficient to verify the paper's claims.
minor comments (7)
  1. [Abstract] The word 'improvemnet' is a typo for 'improvement'; the same issue appears in the abstract and in Section 4.2 ('libirary' for 'library').
  2. [§3 and Figure captions] The text says 'The framework is illustrated in Figure 2', but the framework is shown in Figure 1 and the Source Code Evaluation Runtime is shown in Figure 2; the cross-references are swapped.
  3. [§5.1] The sentence 'Even fused operations (Level 2) see a 50% increase in Compile Pass ... for M1' is contradicted by Table 2, which shows M1 Level 2 Compile Pass increasing from 0.42 to 0.51 (21.4%); the 50% figure corresponds to M3. Please correct the claim.
  4. [§5.2 and Figures 3–4] The phrases 'a 0.9x speedup' and similar are ambiguous: they could mean a speedup factor of 0.9 (a slowdown) or an improvement of 0.9×. Specify whether the reported values are speedup factors relative to PyTorch, and define the baseline per figure.
  5. [§4.1] HPCTransEval is described as containing 10 complex-model building blocks, but no quantitative results are reported for these blocks; Section 5.1 only states that none ran correctly. Please provide explicit numbers (e.g., compile/execute pass rates) or state why they were excluded from the tables.
  6. [§3.5] The search is configured with 'the number of measurement trials to 200' but there is no discussion of how sensitive the final schedule is to this choice or how TVM's measurement noise is handled; please clarify whether the 200 trials are per candidate or total.
  7. [§4.2] The evaluation metric 'Speedup Ratio' is defined as comparing to 'the original code supported by PyTorch or TVM', but the baseline is not pinned down per benchmark; for KernelBench-C, state explicitly that the baseline is e.g., PyTorch CPU inference, and for HPCTransEval, state the TVM-generated CPU reference.

Circularity Check

1 steps flagged · score 3.0 of 10

Partial circularity: HPCTransEval is drawn from the same TVM-generated pool as the training set, so the headline benchmark partly measures fit to the generator; external KernelBench results keep the central claim from being fully circular.

  1. fitted input called prediction [Section 4.1 (Datasets And Models) and Section 3.6 (Evaluation Process)]
    "HPCTransEval is a carefully curated set of representative primitive operators and fused computation graphs selected from CUDA-CPU code pairs generated based on TVM. ... We leverage our proposed framework to generate a dataset, HPCTransData, comprising 20k CUDA-CPU code pairs."

    The LoRA fine-tuning set (HPCTransData) and the HPCTransEval benchmark are both produced by the same TVM code-generation framework. Correctness and expected results are supplied by TVM's exported host/device runtime modules in the evaluation runtime. Therefore the HPCTransEval improvements (e.g., M1 Level-1 speedup ratio 0.83 to 2.35) largely measure how well the fine-tuned model reproduces TVM's scheduling and code-generation idioms on in-distribution inputs, rather than an independent ground-truth transpiration quality. This is a train/evaluation distribution overlap; it is partial circularity because KernelBench_c is external and manually written, providing independent evidence that the central claim is not wholly forced.

full rationale

The paper's central derivation is not fully circular: fine-tuning on TVM-generated CUDA-CPU pairs is also evaluated on the external KernelBench_c, where Table 2 shows genuine improvements (e.g., M1 Level-1 Execute Pass 0.28 to 0.51 and speedup ratio 2.90 to 6.75), and the manual CUDA code for KernelBench_c is independent of the training generator. However, the HPCTransEval benchmark is explicitly selected from TVM-generated CUDA-CPU code pairs, so the headline HPCTransEval results are partly self-referential: the model is fitted to the same generator's distribution and then 'predicted' on that same distribution. This is not a mathematical equivalence by construction, but it is a statistically forced component of the evaluation. Separately, the paper's own Listing 3 (Section 3.3) shows dependency-free CPU code that writes compute[i1] = cosf(data[i1*9+i2]) inside the inner i2 loop, overwriting each output nine times and never producing 323 of 324 elements; if this listing is representative of the dataset labels, the correctness ground truth itself is suspect. That is a correctness risk rather than a circularity step, but it compounds the self-referential evaluation concern. The reported 43.8% average improvement is also not directly reproducible from the tables as a single aggregate, which adds ambiguity but is not circularity. Overall, the core claim has independent external support, so the circularity score is low rather than severe.

Assumptions & free parameters 5 free parameters · 4 assumptions · 2 invented entities

The central claim relies on the fidelity of TVM-generated code, on the representativeness of the chosen operators and graphs, and on the evaluation metrics. The paper does not introduce speculative physical entities; it introduces a dataset and a benchmark. Free parameters are mostly standard hyperparameters, but the random graph construction parameters and the error margin for correctness are left unspecified.

free parameters (5)
  • LoRA rank and alpha = rank=8, alpha=16
    Chosen by the authors, not varied. These affect performance but are not the central claim.
  • Number of training epochs = 5
    Chosen by the authors, not varied. Could influence results.
  • Training dataset size = 20k
    The dataset size is a design choice, and the paper claims it yields convergence (Figure 5).
  • TVM search trial count = 200
    Number of measurement trials for auto-scheduler; affects the quality of generated code.
  • Random graph construction parameters = N_max, D_max, P_op
    These are algorithm parameters (max nodes, max depth, probability of operator selection) that are not specified in the text, but affect dataset diversity.
assumptions (4)
  • domain assumption TVM's auto-scheduler produces code that is correct and representative of high-performance code.
    The entire dataset is generated assuming TVM's scheduling and codegen are reliable (Section 3.5).
  • domain assumption CUDA-to-CPU transpilation is a useful proxy for general CUDA ecosystem compatibility.
    The paper only evaluates CPU as target, and assumes this generalizes to AMD GPUs or TPUs (Section 1).
  • domain assumption Compile Pass, Execute Pass, and Speedup Ratio are sufficient for evaluating transpilation quality.
    The evaluation defines quality through these three metrics, which may not capture numerical fidelity or robustness.
  • domain assumption The 'expected results within a reasonable error margin' is a valid correctness check.
    The Execute Pass allows an unspecified error margin, which is not defined in the paper (Section 4.2).
invented entities (2)
  • TVM-free CPU C device code independent evidence
    purpose: Removing TVM library dependencies from generated CPU code to make the dataset suitable for LLM training.
    The paper describes modifications to TVM compilation passes to produce clean CPU C code (Section 3.3, Listing 3). The entity is a transformed code format, not a speculative construct, and its validity can be checked by inspecting the released code.
  • HPCTransEval benchmark independent evidence
    purpose: New benchmark for LLM CUDA transpilation.
    The benchmark is described as a set of 100 operators, 100 graphs, and 10 model building blocks. It is a concrete artifact that can be used independently.

how reviews work

0 comments
Cite this review

Pith. "Pith review of HPCTransCompile: An AI Compiler Generated Dataset for High-Performance CUDA Transpilation and LLM Preliminary Exploration." pith.science (2026). https://pith.science/paper/RC4RRPX5

@misc{pith2026250610401,
  author       = {Pith},
  title        = {Pith review of: HPCTransCompile: An AI Compiler Generated Dataset for High-Performance CUDA Transpilation and LLM Preliminary Exploration},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/RC4RRPX5}},
  note         = {Machine review of arXiv:2506.10401}
}
read the original abstract

The rapid growth of deep learning has driven exponential increases in model parameters and computational demands. NVIDIA GPUs and their CUDA-based software ecosystem provide robust support for parallel computing, significantly alleviating computational bottlenecks. Meanwhile, due to the cultivation of user programming habits and the high performance of GPUs, the CUDA ecosystem has established a dominant position in the field of parallel software. This dominance requires other hardware platforms to support CUDA-based software with performance portability. However, translating CUDA code to other platforms poses significant challenges due to differences in parallel programming paradigms and hardware architectures. Existing approaches rely on language extensions, domain-specific languages (DSLs), or compilers but face limitations in workload coverage and generalizability. Moreover, these methods often incur substantial development costs. Recently, LLMs have demonstrated extraordinary potential in various vertical domains, especially in code-related tasks. However, the performance of existing LLMs in CUDA transpilation, particularly for high-performance code, remains suboptimal. To address these challenges, we propose a novel framework for generating high-performance CUDA and corresponding platform code pairs, leveraging AI compiler and automatic optimization technology. We further enhance the framework with a graph-based data augmentation method and introduce HPCTransEval, a benchmark for evaluating LLM performance on CUDA transpilation. We conduct experiments using CUDA-to-CPU transpilation as a case study on leading LLMs. The speedup ratio of the CPU operators has an average improvemnet of 43.8\%, highlighting the potential of LLMs to address compatibility challenges within the CUDA ecosystem. Our code is available at https://github.com/PJLAB-CHIP/HPCTransCompile.

Figures

Figures reproduced from arXiv: 2506.10401 by the authors.

Figure 1
Figure 1. Implementation of the proposed framework. [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. Source Code Evaluation Runtime. 4 EXPERIMENTAL SETUP In this section, we will introduce the dataset and model used in the experiments. Additionally, we provide a detailed description of the training details, including parameter configurations and training epochs during the model fine-tuning process. 4.1 Datasets And Models We leverage our proposed framework to generate a dataset, HPC￾TransData, comprising 20k CUDA-C… view at source ↗
Figure 3
Figure 3. Performance Comparison of Qwen2.5-Coder-14B, DeepSeek-Coder-V2-Lite, and OpenCoder-8B Models Before and [PITH_FULL_IMAGE:figures/full_fig_p008_3.png] view at source ↗
Figures from the paper (2 more)
Figure 4
Figure 4. Figure 4: Performance Comparison of Qwen2.5-Coder-14B, [PITH_FULL_IMAGE:figures/full_fig_p008_4.png]
Figure 5
Figure 5. Figure 5: Qwen2.5-Coder-14B execute pass and speedup fac [PITH_FULL_IMAGE:figures/full_fig_p010_5.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

45 extracted references · 31 canonical work pages

  1. [1]

    https://aws.amazon.com/pm/codewhisperer/, Amazon.2023

    Amazon codewhisperer home page. https://aws.amazon.com/pm/codewhisperer/, Amazon.2023

    work page 2023

  2. [2]

    https://github.com/ROCm/HIP, AMD.2016

    AMD HIP. https://github.com/ROCm/HIP, AMD.2016

    work page 2016

  3. [3]

    https://www.amd.com/en/products/software/rocm.html, AMD.2016

    AMD ROC m. https://www.amd.com/en/products/software/rocm.html, AMD.2016

    work page 2016

  4. [4]

    https://codegeex.cn/en-US/, CodeGeeX.2022

    Codegeex home page. https://codegeex.cn/en-US/, CodeGeeX.2022

    work page 2022

  5. [5]

    https://github.com/features/copilot, Github.2021

    Github copilot home page. https://github.com/features/copilot, Github.2021

    work page 2021

  6. [6]

    https://github.com/ROCm/HIPIFY, HIPIFY.2016

    HIPIFY github home page. https://github.com/ROCm/HIPIFY, HIPIFY.2016

    work page 2016

  7. [7]

    Intel. 2022. OneAPI Deep Neural Network Library (OneDNN). https://github. com/oneapi-src/oneDNN, Intel.2022

    work page 2022

  8. [8]

    https://llvm.org/docs/ORCv2.html, LLVM.2018

    LLVM ORC JIT documentation. https://llvm.org/docs/ORCv2.html, LLVM.2018

    work page 2018

Show all 45 references
  1. [9]

    https://www.khronos.org/sycl/, SYCL.2014

    SYCL home page. https://www.khronos.org/sycl/, SYCL.2014

    2014

  2. [10]

    S., Devanbu, P., and Barr, E

    Ahmed, T., Pai, K. S., Devanbu, P., and Barr, E. Automatic semantic augmenta- tion of language model prompts (for code summarization). In Proceedings of the HPCTransCompile: An AI Compiler Generated Dataset for High-Performance CUDA Transpilation and LLM Preliminary Exploratio...

    2024

  3. [11]

    claude 3.5 home page

    Anthropic. claude 3.5 home page. https://www.anthropic.com/claude

  4. [12]

    Chen, M., Tworek, J., Jun, H., Yuan, Q., Pinto, H. P. D. O., Kaplan, J., Edwards, H., Burda, Y., Joseph, N., Brockman, G., et al.Evaluating large language models trained on code. arXiv preprint arXiv:2107.03374 (2021)

    2021 arXiv

  5. [13]

    TVM: An automated end-to-end optimizing compiler for deep learning

    Chen, T., Moreau, T., Jiang, Z., Zheng, L., Y an, E., Shen, H., Cowan, M., W ang, L., Hu, Y., Ceze, L., et al. TVM: An automated end-to-end optimizing compiler for deep learning. In 13th USENIX Symposium on Operating Systems Design and Implementation (OSDI 18) (2018), pp. 578–594

    2018

  6. [14]

    Tree-to-tree neural networks for program translation

    Chen, X., Liu, C., and Song, D. Tree-to-tree neural networks for program translation. Advances in neural information processing systems 31 (2018)

    2018

  7. [15]

    Chen, Y., Wu, J., Ling, X., Li, C., Rui, Z., Luo, T., and Wu, Y.When large language models confront repository-level automatic program repair: How well they done? In Proceedings of the 2024 IEEE/ACM 46th International Conference on Software Engineering: Companion Proceedings (...

    2024

  8. [16]

    C., Trott, C

    Edwards, H. C., Trott, C. R., and Sunderland, D. Kokkos: Enabling manycore performance portability through polymorphic memory access patterns. Journal of parallel and distributed computing 74 , 12 (2014), 3202–3216

    2014

  9. [17]

    Longcoder: A long-range pre-trained language model for code completion

    Guo, D., Xu, C., Duan, N., Yin, J., and McAuley, J. Longcoder: A long-range pre-trained language model for code completion. In International Conference on Machine Learning (2023), PMLR, pp. 12098–12107

    2023

  10. [18]

    J., Shen, Y., Wallis, P., Allen-Zhu, Z., Li, Y., Wang, S., Wang, L., and Chen, W

    Hu, E. J., Shen, Y., Wallis, P., Allen-Zhu, Z., Li, Y., Wang, S., Wang, L., and Chen, W. Lora: Low-rank adaptation of large language models. arXiv preprint arXiv:2106.09685 (2021)

    2021 arXiv

  11. [19]

    K., Hao, J., Song, L., Xu, Y., Y ang, J., Liu, J., Zhang, C., Chai, L., et al

    Huang, S., Cheng, T., Liu, J. K., Hao, J., Song, L., Xu, Y., Y ang, J., Liu, J., Zhang, C., Chai, L., et al. Opencoder: The open cookbook for top-tier code large language models. arXiv preprint arXiv:2411.04905 (2024)

    2024 arXiv

  12. [20]

    Hui, B., Yang, J., Cui, Z., Yang, J., Liu, D., Zhang, L., Liu, T., Zhang, J., Yu, B., Lu, K., et al. Qwen2. 5-coder technical report. arXiv preprint arXiv:2409.12186 (2024)

    2024 arXiv

  13. [21]

    Cure: Code-aware neural machine transla- tion for automatic program repair

    Jiang, N., Lutellier, T., and Tan, L. Cure: Code-aware neural machine transla- tion for automatic program repair. In2021 IEEE/ACM 43rd International Conference on Software Engineering (ICSE) (2021), IEEE, pp. 1161–1173

    2021

  14. [22]

    Tpu v4: An optically reconfigurable supercomputer for machine learning with hardware support for embeddings

    Jouppi, N., Kurian, G., Li, S., Ma, P., Nagarajan, R., Nai, L., Patil, N., Subra- manian, S., Swing, A., Towles, B., et al. Tpu v4: An optically reconfigurable supercomputer for machine learning with hardware support for embeddings. In Proceedings of the 50th Annual Internatio...

    2023

  15. [23]

    B., Chess, B., Child, R., Gray, S., Radford, A., Wu, J., and Amodei, D

    Kaplan, J., McCandlish, S., Henighan, T., Brown, T. B., Chess, B., Child, R., Gray, S., Radford, A., Wu, J., and Amodei, D. Scaling laws for neural language models. CoRR abs/2001.08361 (2020)

    2020 arXiv

  16. [24]

    Khan, M. A. M., Bari, M. S., Do, X. L., Wang, W., Parvez, M. R., and Joty, S. xcodeeval: A large scale multilingual multitask benchmark for code under- standing, generation, translation and retrieval. arXiv preprint arXiv:2303.03004 (2023)

    2023 arXiv

  17. [25]

    Kulal, S., Pasupat, P., Chandra, K., Lee, M., Padon, O., Aiken, A., and Liang, P. S. Spoc: Search-based pseudocode to code. Advances in Neural Information Processing Systems 32 (2019)

    2019

  18. [26]

    Exploring scalability in c++ parallel stl implementations

    Laso, R., Krupitza, D., and Hunold, S. Exploring scalability in c++ parallel stl implementations. In Proceedings of the 53rd International Conference on Parallel Processing (2024), pp. 284–293

    2024

  19. [27]

    Decoupled weight decay regularization

    Loshchilov, I., and Hutter, F. Decoupled weight decay regularization. arXiv preprint arXiv:1711.05101 (2017)

    2017 arXiv

  20. [28]

    B., Cassano, F., Lamy-Poirier, J., Tazi, N., Tang, A., Pykhtar, D., Liu, J., Wei, Y., et al

    Lozhkov, A., Li, R., Allal, L. B., Cassano, F., Lamy-Poirier, J., Tazi, N., Tang, A., Pykhtar, D., Liu, J., Wei, Y., et al. Starcoder 2 and the stack v2: The next generation. arXiv preprint arXiv:2402.19173 (2024)

    2024 arXiv

  21. [29]

    arXiv preprint arXiv:2102.04664 (2021)

    Lu, S., Guo, D., Ren, S., Huang, J., Svyatkovskiy, A., Blanco, A., Clement, C., Drain, D., Jiang, D., Tang, D., et al.Codexglue: A machine learning benchmark dataset for code understanding and generation. arXiv preprint arXiv:2102.04664 (2021)

    2021 arXiv

  22. [30]

    S., Ivanov, I

    Moses, W. S., Ivanov, I. R., Domke, J., Endo, T., Doerfert, J., and Zinenko, O. High-performance gpu-to-cpu transpilation and optimization via high-level parallel constructs. In Proceedings of the 28th ACM SIGPLAN Annual Symposium on Principles and Practice of Parallel Program...

    2023

  23. [31]

    L., Hu, W., Ré, C., and Mirhoseini, A

    Ouyang, A., Guo, S., Arora, S., Zhang, A. L., Hu, W., Ré, C., and Mirhoseini, A. Kernelbench: Can llms write efficient gpu kernels?arXiv preprint arXiv:2502.10517 (2025)

    2025 arXiv

  24. [32]

    R., Krishna, R., Sankar, D., W assi, L

    Pan, R., Ibrahimzada, A. R., Krishna, R., Sankar, D., W assi, L. P., Merler, M., Sobolev, B., Pavuluri, R., Sinha, S., and Jabbarvand, R. Lost in translation: A study of bugs introduced by large language models while translating code. In Proceedings of the IEEE/ACM 46th Intern...

    2024

  25. [33]

    Halide: a language and compiler for optimizing parallelism, locality, and recomputation in image processing pipelines

    Ragan-Kelley, J., Barnes, C., Adams, A., Paris, S., Durand, F., and Amaras- inghe, S. Halide: a language and compiler for optimizing parallelism, locality, and recomputation in image processing pipelines. Acm Sigplan Notices 48 , 6 (2013), 519–530

    2013

  26. [34]

    CodeBLEU: a method for automatic evaluation of code synthesis

    Ren, S., Guo, D., Lu, S., Zhou, L., Liu, S., Tang, D., Sundaresan, N., Zhou, M., Blanco, A., and Ma, S. CodeBLEU: a method for automatic evaluation of code synthesis. arXiv preprint arXiv:2009.10297 (2020)

    2020 arXiv

  27. [35]

    Outrageously large neural networks: The sparsely-gated mixture-of- experts layer

    Shazeer, N., Mirhoseini, A., Maziarz, K., Davis, A., Le, Q., Hinton, G., and Dean, J. Outrageously large neural networks: The sparsely-gated mixture-of- experts layer. arXiv preprint arXiv:1701.06538 (2017)

    2017 arXiv

  28. [36]

    E., Gohara, D., and Shi, G

    Stone, J. E., Gohara, D., and Shi, G. OpenCL: A parallel programming standard for heterogeneous computing systems. Computing in Science & Engineering 12 , 3 (2010), 66–73

    2010

  29. [37]

    N., Kaiser, Ł., and Polosukhin, I

    Vaswani, A., Shazeer, N., Parmar, N., Uszkoreit, J., Jones, L., Gomez, A. N., Kaiser, Ł., and Polosukhin, I. Attention is all you need. Advances in neural information processing systems 30 (2017)

    2017

  30. [38]

    Transformers: State-of-the-art natural language processing

    Wolf, T., Debut, L., Sanh, V., Chaumond, J., Delangue, C., Moi, A., Cistac, P., Rault, T., Louf, R., Funtowicz, M., et al. Transformers: State-of-the-art natural language processing. In Proceedings of the 2020 conference on empirical methods in natural language processing: sys...

    2020

  31. [39]

    Enhancing heterogeneous computing through openmp and gpu graph

    Yu, C., Royuela, S., and Quiñones, E. Enhancing heterogeneous computing through openmp and gpu graph. InProceedings of the 53rd International Conference on Parallel Processing (2024), pp. 534–543

    2024

  32. [40]

    Codereval: A benchmark of pragmatic code generation with generative pre-trained models

    Yu, H., Shen, B., Ran, D., Zhang, J., Zhang, Q., Ma, Y., Liang, G., Li, Y., W ang, Q., and Xie, T. Codereval: A benchmark of pragmatic code generation with generative pre-trained models. In Proceedings of the 46th IEEE/ACM International Conference on Software Engineering (2024...

    2024

  33. [41]

    Cpm: A large-scale generative chinese pre-trained language model

    Zhang, Z., Han, X., Zhou, H., Ke, P., Gu, Y., Ye, D., Qin, Y., Su, Y., Ji, H., Guan, J., et al. Cpm: A large-scale generative chinese pre-trained language model. AI Open 2 (2021), 93–99

    2021

  34. [42]

    H., Haj-Ali, A., Wang, Y., Yang, J., Zhuo, D., Sen, K., et al

    Zheng, L., Jia, C., Sun, M., Wu, Z., Yu, C. H., Haj-Ali, A., Wang, Y., Yang, J., Zhuo, D., Sen, K., et al. Ansor: Generating high-performance tensor programs for deep learning. In 14th USENIX symposium on operating systems design and implementation (OSDI 20) (2020), pp. 863–879

    2020

  35. [43]

    In Proceedings of the 29th ACM SIGKDD Conference on Knowledge Discovery and Data Mining (2023), pp

    Zheng, Q., Xia, X., Zou, X., Dong, Y., Wang, S., Xue, Y., Shen, L., Wang, Z., W ang, A., Li, Y., et al.Codegeex: A pre-trained model for code generation with multilingual benchmarking on humaneval-x. In Proceedings of the 29th ACM SIGKDD Conference on Knowledge Discovery and D...

    2023

  36. [44]

    I., Han, Z., Paster, K., Pitis, S., Chan, H., and Ba, J

    Zhou, Y., Muresanu, A. I., Han, Z., Paster, K., Pitis, S., Chan, H., and Ba, J. Large language models are human-level prompt engineers. arXiv preprint arXiv:2211.01910 (2022)

    2022 arXiv

  37. [45]

    Deepseek-coder-v2: Breaking the barrier of closed-source models in code intelligence

    Zhu, Q., Guo, D., Shao, Z., Yang, D., Wang, P., Xu, R., Wu, Y., Li, Y., Gao, H., Ma, S., et al. Deepseek-coder-v2: Breaking the barrier of closed-source models in code intelligence. arXiv preprint arXiv:2406.11931 (2024)

    2024 arXiv

Pith tools

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