GPU Kernel Scientist: An LLM-Driven Framework for Iterative Kernel Optimization

Martin Andrews; Sam Witteveen

REVIEW 4 major objections 6 minor 2 cited by

GPU Kernel Scientist: An LLM-Driven Framework for Iterative Kernel Optimization

T0 review · 4 major / 6 minor · reviewed 2026-08-06 · deepseek-v4-flash

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

Pith's one-line read Three LLM stages—selection, experiment design, kernel writing—iteratively improved an AMD MI300 GEMM kernel to 450 µs geometric mean, 1.9x faster than PyTorch, using only black-box timings.

desk verdict A transparent workshop-level demo with a plausible 450µs result, but the missing ablation leaves the autonomous-optimization claim unproven. read the letter →

arxiv 2506.20807 v2 pith:L5CQPOBT submitted 2025-06-25 cs.LG cs.AIcs.PFcs.SE

Martin Andrews , Sam Witteveen This is my paper

classification cs.LGcs.AIcs.PFcs.SE

keywords GPUkerneloptimizationlargelanguagemodelsevolutionarysearchHIPAMDMI300GEMMblack-boxbenchmarkingLLMagents

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 a closed, LLM-driven three-stage loop can act as a GPU kernel scientist, iteratively improving a nontrivial GEMM kernel on AMD's MI300 using only black-box end-to-end timing results. Starting from a naive HIP translation that ran in about 5000 µs, the loop produced kernels whose geometric-mean runtime over the 18 competition matrix sizes reached roughly 450 µs, about 1.9x faster than the PyTorch reference at 850 µs and about 4.3x slower than the 105 µs human winner. The claim matters because it suggests that frontier LLMs can compensate for scarce documentation, missing profilers, and limited human GPU expertise on newer hardware. The paper frames the result as a step toward democratizing high-performance kernel development rather than as a replacement for human experts.

What carries the argument

The load-bearing mechanism is the closed evolutionary loop itself: selection of promising parents by an LLM, generation of diverse experiment rubrics by a second LLM, implementation of kernel variants by a third LLM, and evaluation by a bench that returns only timings. The named components are the Evolutionary Selector, Experiment Designer, and Kernel Writer. The chain also rests on a human-LLM collaboration artifact, a 'findings' document that summarizes hardware quirks such as matrix-core memory layout, and on seed kernels—including one already using matrix cores—that give the loop a viable starting point. The loop is what converts sparse black-box feedback into directed code changes.

What would settle it

Run the identical three-stage loop on the same MI300 benchmark, starting only from the naive HIP translation and the PyTorch reference, with no matrix-core seed kernel, no curated findings document, and no human-assisted hardware probing; if the resulting geometric-mean time stays near the naive HIP baseline or fails to beat the PyTorch reference, the paper's attribution to the autonomous loop is refuted. A positive control—repeating the full scaffolded setup with the loop's selection and design stages replaced by random choices—would also isolate the LLM's contribution.

Watch

Extended reading notes

Core claim

The central discovery is that an evolutionary loop in which LLMs perform selection, experiment design, and code writing can navigate a poorly documented accelerator without profiling. In each cycle, an LLM Evolutionary Selector chooses a Base kernel and a Reference kernel from the population; an LLM Experiment Designer generates ten research avenues and five experiment plans, of which three are chosen for maximal innovation, maximal upside, and maximal guaranteed gain; and an LLM Kernel Writer implements each experiment as a HIP diff, which is compiled, checked for correctness, and timed by the competition platform. The only feedback signal is execution time. The best kernels produced by this process use rocWMMA matrix-core instructions with FP8 inputs, FP32 accumulation, BF16 output, shared-memory double buffering, LDS reuse for scaling, and multi-wave thread blocks. The authors report that the loop reached about 450 µs geometric-mean time on the 18 benchmark sizes, beating the PyTorch reference by about 1.9x, and they attribute the improvement to the loop's ability to bootstrap its own understanding of the hardware.

Load-bearing premise

The central claim depends on the 450 µs result measuring the autonomous LLM loop rather than the carefully prepared starting conditions, which included a seed kernel that already used the chip's matrix cores, curated documentation, and an LLM-written 'findings' document; the paper does not ablate these scaffolds.

Editorial extensions

If this is right

If the claim holds, LLM agents can begin optimizing kernels for new or niche hardware before human experts and profiling toolchains exist.
The same three-stage loop transfers to other GPU families and kernel types, provided the external benchmark returns timing and correctness.
Adding profiler feedback and parallel evaluation, as the authors suggest, should tighten the gap toward human-level kernel times.
The loop's generated 'findings' document becomes reusable documentation that lowers the cost of the next optimization campaign on the same hardware.
The method complements rather than replaces auto-tuners such as OpenTuner and KernelTuner, which could fine-tune the kernels the loop discovers.

Reading between the lines

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

Editorial inference: the 450 µs figure likely overstates the pure autonomous loop, because the seed population included a kernel that already used matrix cores and a curated findings document; without an ablation removing these scaffolds, the marginal contribution of the loop itself is untested.
Editorial inference: a fair comparison would run the same loop on a documented architecture like CUDA with KernelBench-style tasks, where human baselines and profilers exist, isolating the scaffolding effect.
Editorial inference: the 105 µs human result suggests the loop found a strong local optimum but missed structural ideas humans use; feeding it profiler traces or letting it design its own microbenchmarks might be the fastest path to close the gap.

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.

Desk Editor's Note

read the letter

If you take away one thing: the 450µs number is a real effect, but it doesn't establish that the LLM loop discovered the optimization—the seed kernels and the LLM-written 'findings' doc may have done the hard part.

What's actually new: applying the LLM-as-evolutionary-operator idea to a nontrivial HIP GEMM kernel on AMD MI300 with only black-box timings and no profiling. The three-stage loop (evolutionary selector, experiment designer, kernel writer) is a clean composition, and the authors are transparent about the scaffold—they explicitly call the matrix-core seed a 'gift' and describe the findings document. They cite AlphaEvolve, Promptbreeder, and AI CUDA Engineer, so they're not overselling novelty.

What it does well: evaluation against an external competition leaderboard, so the runtime isn't measured by the system's own outputs. The result—450µs geometric mean vs. 850µs for PyTorch, 5000µs for a naive HIP translation, and 105µs for the human winner—is a 1.9x improvement over PyTorch, which is genuinely useful in a no-profiling setting. The appendix gives real examples of the LLM's reasoning and the prompt structure.

Where it's soft: the central claim is that the autonomous loop did the optimization, but there is no ablation that removes the seed kernels and the findings document. The final kernel retains exactly the rocWMMA MFMA structure from the 'gift' seed, with double buffering, multi-wave blocks, and LDS re-purposing. If the seed already encodes the winning algorithmic structure, the loop is tuning hyperparameters, not discovering the optimization. The paper also reports a single aggregate number—no variance, no per-configuration table—and no baseline like random mutation or a simpler search. The human-in-the-loop during initial hardware probing further muddies the 'LLM-only' label, though the authors are honest about that.

Who this is for: people working on LLM-driven code optimization, HPC tooling, or AMD ecosystems. It's a useful existence proof that a black-box timing loop can improve a kernel, and I'd cite it as related work. But it shouldn't be read as evidence that LLMs autonomously discover kernel optimizations from scratch.

Recommendation: send it to peer review at a workshop or short-paper venue, with a referee request for a cold-start ablation and variance reporting. The system is real; the evidence just needs to match the claim.

Referee Report

4 major / 6 minor

Summary. The paper proposes and evaluates "GPU Kernel Scientist," a three-stage LLM-driven framework (evolutionary selector, experiment designer, kernel writer) that iteratively optimizes a HIP GEMM kernel for the AMD MI300 using only end-to-end timing feedback from an external benchmark platform. The reported outcome is a geometric-mean runtime of roughly 450 microseconds, compared with about 850 microseconds for the PyTorch reference, about 5000 microseconds for a naive HIP translation, and about 105 microseconds for the human first-place competition entry. The paper also describes the bootstrapping process, including seed kernels, curated documentation, and an LLM-written "findings" document, and it includes qualitative observations about the LLM's ability to reason about poorly documented hardware without profiling tools.

Significance. If the reported result is correctly attributed to the autonomous loop, the paper would be a useful empirical demonstration that frontier LLMs can drive meaningful GPU kernel optimization under severe information constraints, with the additional strength that performance is measured by an external competition leaderboard rather than by the system's own outputs. The paper also gives credit for being transparent about the scaffolding: it explicitly describes the seed kernels, the curated documentation, and the LLM-assisted bootstrapping phase. The main value is therefore contingent on a clean separation between what the human-provided scaffolds contribute and what the automated loop contributes; that separation is currently not established.

major comments (4)

[§4.5, Table 1] The central attribution claim is not supported by the presented experiments. Section 3 states that the seed population includes a matrix-core HIP kernel described as a 'gift' to the LLM, and Section 4.3 states that the LLM produced a 'findings' document with pseudocode for a high-performance kernel that is then provided to the Kernel Writer. Appendix A.3 shows that the final kernel retains exactly that structure: rocWMMA MFMA 32x32x16 fragments, double-buffered LDS, multi-wave thread blocks, and LDS re-purposing for scale caching. Because no ablation removes this scaffold, the observed improvement from roughly 5000 to 450 microseconds cannot be attributed to the autonomous LLM loop rather than to a well-chosen seed and prompt package. This gap is load-bearing because the paper's novelty claim depends on the loop being the source of the optimization.
[§3 and §4.3] The headline result is a single aggregate number. Table 1 reports the geometric-mean runtime as approximately 450 microseconds with no variance, no number of repetitions, and no per-shape benchmark table, despite the text saying the leaderboard used 18 specific matrix sizes. Without the raw timings, the reader cannot assess whether the result is stable, whether it is driven by a few favorable shapes, or whether the comparison to the PyTorch and naive-HIP baselines is apples-to-apples. At minimum, the authors should provide the 18 per-shape timings, the measurement protocol, and the standard deviation or range.
[§5.1] The labels 'LLM-only' in Table 1 and the claim in Section 4.3 that all 'clever' steps originated from the LLM are contradicted in part by the paper's own description. The human authors chose to include a matrix-core HIP kernel as a seed, curated AMD and CUDA documentation, initiated the 'findings' document, and intervened during the hardware-probing phase. The paper should define precisely which components of the pipeline were fully autonomous, which were human-authored, and which were human-assisted LLM output, and then either soften the 'LLM-only' characterization or provide an ablation that isolates the loop.
The generalizability claim is currently supported by only one kernel, one hardware platform, and one run of the pipeline. Section 5.1 and the abstract frame the framework as broadly applicable to other hardware and kernels, but no evidence is given about sensitivity to the initial seed population, the choice of LLM, or the curated documentation. Acknowledging this as a limitation in Section 5.1 is helpful, but the paper should either add a second kernel or a repeated-run result, or explicitly restrict the conclusion to the demonstrated single case.

minor comments (6)

[§4.2] The phrase 'no choice by to use' should read 'no choice but to use'.
[§4.4] The phrase 'beyond those of the the individual LLMs' contains a duplicated 'the'.
[Table 1] The approximate values in Table 1 should be accompanied by a note specifying the number of benchmark runs, the hardware configuration, and whether the PyTorch and naive-HIP numbers were obtained through the same submission interface.
[§2] The comparison with AI CUDA Engineer would be stronger if it cited specific quantitative differences, such as kernel complexity or benchmark conditions, rather than only the qualitative observations about the number or difficulty of tasks.
[Appendix A.4] The supplementary link should be described as a persistent artifact, and the supplementary materials should include the exact prompt templates, the complete seed kernels, and the full raw benchmark table to allow reproduction.
[References] Some reference URLs, particularly the AMD Developer Challenge link, appear as informal or third-party URLs; the authors should provide the canonical competition pages or archived citations.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the paper's central performance claim is measured against an external benchmark platform, and the LLM's self-generated hypotheses and findings are part of the proposed method rather than a definitional shortcut.

full rationale

The paper's central claim is that an LLM-driven three-stage loop can iteratively optimize a HIP GEMM kernel, reaching roughly 450 microseconds on an external AMD Developer Challenge benchmark. This performance number is not derived from the framework's own outputs by construction; it is measured externally by the competition platform over 18 matrix sizes. The framework does use the LLM's own generated 'findings' document and self-selected experiments as context for later iterations, but this is the method under test, not a circular definition: the final runtime is an independent external observation. The seed kernels, including the matrix-core kernel described as a 'gift to the LLM', and the lack of a cold-start ablation are legitimate attribution concerns, but they concern whether the autonomous-loop claim is fully supported, not whether the result is equivalent to its inputs by definition. The paper does not invoke self-citations as load-bearing evidence, and no equation or fitted parameter is renamed as a prediction. The evaluation is self-contained against an external benchmark, so the appropriate finding is no significant circularity.

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

This is an applied systems paper, so the ledger records the empirical assumptions supporting the demonstration rather than mathematical postulates. The central claim depends on benchmark fidelity, the reliability of LLM self-generated hardware notes, and the attribution of the 450µs result to the autonomous loop rather than to the human-built seed kernels and prompts. There are no fitted constants and no invented physical entities.

assumptions (4)

domain assumption The AMD Developer Challenge benchmark platform reports stable, accurate end-to-end runtimes that serve as a valid optimization signal.
Sections 3.4 and 4.2 state the system uses only these timings because no profiling data exist; if timings are noisy or unrepresentative, every selection decision inherits that error.
domain assumption The LLM-generated 'findings' document, produced by probing compilation and execution errors, correctly describes MI300 matrix-core behavior and remains useful across iterations.
Section 3 and Appendix A.3 show that the knowledge base is written by the LLM for its own use; a wrong or incomplete finding would feed misleading instructions to the designer and writer stages.
domain assumption Gemini 2.5 Pro can generate syntactically and semantically correct HIP code when given known-working context, so that the test-evaluate-fix loop can close.
Section 3.3 calls this capability the heart of the process and notes that without it the whole system fails.
domain assumption The carefully chosen seed kernels, especially the Matrix-Core translation, provide a strong but not outcome-determining scaffold for the search.
Section 3 says the seed set included a Matrix-Core kernel described as a 'gift' to the LLM; if that scaffold already encodes most of the winning structure, the loop's contribution is overstated.

how reviews work

0 comments

Cite this review

Pith. "Pith review of GPU Kernel Scientist: An LLM-Driven Framework for Iterative Kernel Optimization." pith.science (2026). https://pith.science/paper/L5CQPOBT

@misc{pith2026250620807,
  author       = {Pith},
  title        = {Pith review of: GPU Kernel Scientist: An LLM-Driven Framework for Iterative Kernel Optimization},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/L5CQPOBT}},
  note         = {Machine review of arXiv:2506.20807}
}

read the original abstract

Optimizing GPU kernels for high performance is a complex task, often demanding deep architectural knowledge, extensive profiling, and iterative experimentation. This challenge is amplified when targeting newer or less-documented GPU architectures where traditional development aids are scarce. This paper introduces an LLM-powered "GPU Kernel Scientist," an automated methodology for iteratively refining accelerator kernels. Our methodology employs LLMs in a multi-stage, evolutionary process: (a) strategically selecting promising prior code versions as a basis for new iterations; (b) generating hypotheses for optimization experiments, based on existing code and assimilated knowledge from general GPU literature; and (c) autonomously implementing these experiments through code modification and subsequent submission to an external evaluation system, using only observed timing data as performance feedback. We detail how this approach navigates the challenges of the AMD MI300 target architecture and leverages LLMs to compensate for limited domain-specific human expertise. In addition to our results, we present the architectural design, operational workflow, and qualitative insights, highlighting the potential of LLM-driven agents to democratise and accelerate GPU kernel optimization, especially in resource-constrained or rapidly updating hardware environment.

Figures

Figures reproduced from arXiv: 2506.20807 by the authors.

**Figure 1.** GPU Kernel Scientist Process Our proposed solution to this problem is a “GPU Kernel Scientist” – an automated, iterative framework that can optimise kernels for non-CUDA hardware, with access only to end-to-end timing results. The core idea is to use frontier LLMs to create a cycle of code selection, experiment ideation, and code generation/modification based only on limited feedback from an online testing/benchma… view at source ↗

Discussion (0). Sign in 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

CANN Bench: Benchmarking Agent Generated Kernels against Real NPU and Algorithmic Limits
cs.AI 2026-07 conditional novelty 6.0 of 10

CANN Bench is an Ascend-NPU benchmark with 53 operators and 1,060 released test cases that scores agent-generated kernels on compilation, correctness, and hardware-anchored performance.
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.

Reference graph

Works this paper leans on

22 extracted references · 15 canonical work pages · cited by 2 Pith papers

[1]

AMD Instinct MI300 Instruction Set Architecture Reference Guide , 2024

AMD . AMD Instinct MI300 Instruction Set Architecture Reference Guide , 2024. URL https://www.amd.com/content/dam/amd/en/documents/instinct-tech-docs/instruction-set-architectures/amd-instinct-mi300-cdna3-instruction-set-architecture.pdf

work page 2024
[2]

AMD developer challenge, May 2025 a

AMD . AMD developer challenge, May 2025 a . URL https://www.datamonsters.com/amd-developer-challenge-2025

work page 2025
[3]

Amd matrix instruction calculator, 2025 b

AMD . Amd matrix instruction calculator, 2025 b . URL https://github.com/ROCm/amd_matrix_instruction_calculator

work page 2025
[4]

AMD rocWMMA library, 2025 c

AMD . AMD rocWMMA library, 2025 c . URL https://github.com/ROCm/rocWMMA

work page 2025
[5]

OpenTuner

Ansel, J., Kamil, S., Veeramachaneni, K., Ragan-Kelley, J., Bosboom, J., O'Reilly, U.-M., and Amarasinghe, S. OpenTuner . In Proceedings of the 23rd international conference on Parallel architectures and compilation, New York, NY, USA, August 2014. ACM

work page 2014
[6]

How to write a fast matrix multiplication from scratch with Tensor Cores , 8 2024

Armbruster, A. How to write a fast matrix multiplication from scratch with Tensor Cores , 8 2024. URL https://alexarmbr.github.io/2024/08/10/How-To-Write-A-Fast-Matrix-Multiplication-From-Scratch-With-Tensor-Cores.html

work page 2024
[7]

How to optimize a CUDA matmul kernel for cuBLAS -like performance: a worklog, 12 2022

Boehm, S. How to optimize a CUDA matmul kernel for cuBLAS -like performance: a worklog, 12 2022. URL https://siboehm.com/articles/22/CUDA-MMM

work page 2022
[8]

S., Michalewski, H., Osindero, S., and Rockt\" a schel, T

Fernando, C., Banarse, D. S., Michalewski, H., Osindero, S., and Rockt\" a schel, T. Promptbreeder: Self-referential self-improvement via prompt evolution. In Salakhutdinov, R., Kolter, Z., Heller, K., Weller, A., Oliver, N., Scarlett, J., and Berkenkamp, F. (eds.), Proceedings of the 41st International Conference on Machine Learning, volume 235 of Procee...

work page 2024

Show all 22 references

[9]

Holland, J. H. Adaptation in natural and artificial systems. Complex Adaptive Systems. Bradford Books, Cambridge, MA, 1975

1975
[10]

Koza, J. R. Genetic programming. Complex Adaptive Systems. Bradford Books, Cambridge, MA, December 1992

1992
[11]

T., Prasad, A., Sun, Q., Faldor, M., Tang, Y., and Ha, D

Lange, R. T., Prasad, A., Sun, Q., Faldor, M., Tang, Y., and Ha, D. The AI CUDA engineer: Agentic CUDA kernel discovery, optimization and composition. Technical report, Sakana AI , 02 2025. URL https://pub.sakana.ai/ai-cuda-engineer/paper/

2025
[12]

The AI scientist: Towards fully automated open-ended scientific discovery

Lu , C., Lu , C., Tjarko Lange , R., Foerster , J., Clune , J., and Ha , D. The AI scientist: Towards fully automated open-ended scientific discovery. arXiv e-prints, art. arXiv:2408.06292, August 2024. doi:10.48550/arXiv.2408.06292

2024 doi arXiv
[13]

and Clune, J

Mouret, J.-B. and Clune, J. Illuminating search spaces by mapping elites, 2015. URL https://arxiv.org/abs/1504.04909

2015 arXiv
[14]

Scalable parallel programming with CUDA

Nickolls, J., Buck, I., Garland, M., and Skadron, K. Scalable parallel programming with CUDA . In ACM SIGGRAPH 2008 classes , New York, NY, USA, August 2008. ACM

2008
[15]

Z., Shirobokov, S., Kozlovskii, B., Ruiz, F

Novikov, A., V\ u , N., Eisenberger, M., Dupont, E., Huang, P.-S., Wagner, A. Z., Shirobokov, S., Kozlovskii, B., Ruiz, F. J. R., Mehrabian, A., Kumar, M. P., See, A., Chaudhuri, S., Holland, G., Davies, A., Nowozin, S., Kohli, P., and Balog, M. AlphaEvolve : A coding agent fo...

2025
[16]

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?, 2025. URL https://arxiv.org/abs/2502.10517

2025 arXiv
[17]

P., Dupont, E., Ruiz, F

Romera-Paredes, B., Barekatain, M., Novikov, A., Balog, M., Kumar, M. P., Dupont, E., Ruiz, F. J. R., Ellenberg, J. S., Wang, P., Fawzi, O., Kohli, P., and Fawzi, A. Mathematical discoveries from program search with large language models. Nature, 625 0 (7995): 0 468--475, January 2024

2024
[18]

F., Arora, S., Singhal, A., Fu, D

Spector, B. F., Arora, S., Singhal, A., Fu, D. Y., and Ré, C. ThunderKittens : Simple, fast, and adorable AI kernels, 2024. URL https://arxiv.org/abs/2410.20399

2024 arXiv
[19]

T., and Cox, D

Tillet, P., Kung, H. T., and Cox, D. Triton: an intermediate language and compiler for tiled neural network computations. In Proceedings of the 3rd ACM SIGPLAN International Workshop on Machine Learning and Programming Languages , New York, NY, USA, June 2019. ACM

2019
[20]

Kernel tuner: A search-optimizing GPU code auto-tuner

van Werkhoven, B. Kernel tuner: A search-optimizing GPU code auto-tuner. Future Generation Computer Systems, 90: 0 347--358, 2019. doi:https://doi.org/10.1016/j.future.2018.08.004. URL https://www.sciencedirect.com/science/article/pii/S0167739X18313359

2019 doi
[21]

TileLang : A composable tiled programming model for AI systems, 2025

Wang, L., Cheng, Y., Shi, Y., Tang, Z., Mo, Z., Xie, W., Ma, L., Xia, Y., Xue, J., Yang, F., and Yang, Z. TileLang : A composable tiled programming model for AI systems, 2025. URL https://arxiv.org/abs/2504.17577

2025 arXiv
[22]

T., Lu, C., Hu, S., Lu, C., Foerster, J., Clune, J., and Ha, D

Yamada, Y., Lange, R. T., Lu, C., Hu, S., Lu, C., Foerster, J., Clune, J., and Ha, D. The AI scientist-v2: Workshop-level automated scientific discovery via agentic tree search, 2025. URL https://arxiv.org/abs/2504.08066

2025 arXiv

Pith tools

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

[1] [1]

AMD Instinct MI300 Instruction Set Architecture Reference Guide , 2024

AMD . AMD Instinct MI300 Instruction Set Architecture Reference Guide , 2024. URL https://www.amd.com/content/dam/amd/en/documents/instinct-tech-docs/instruction-set-architectures/amd-instinct-mi300-cdna3-instruction-set-architecture.pdf

work page 2024

[2] [2]

AMD developer challenge, May 2025 a

AMD . AMD developer challenge, May 2025 a . URL https://www.datamonsters.com/amd-developer-challenge-2025

work page 2025

[3] [3]

Amd matrix instruction calculator, 2025 b

AMD . Amd matrix instruction calculator, 2025 b . URL https://github.com/ROCm/amd_matrix_instruction_calculator

work page 2025

[4] [4]

AMD rocWMMA library, 2025 c

AMD . AMD rocWMMA library, 2025 c . URL https://github.com/ROCm/rocWMMA

work page 2025

[5] [5]

OpenTuner

Ansel, J., Kamil, S., Veeramachaneni, K., Ragan-Kelley, J., Bosboom, J., O'Reilly, U.-M., and Amarasinghe, S. OpenTuner . In Proceedings of the 23rd international conference on Parallel architectures and compilation, New York, NY, USA, August 2014. ACM

work page 2014

[6] [6]

How to write a fast matrix multiplication from scratch with Tensor Cores , 8 2024

Armbruster, A. How to write a fast matrix multiplication from scratch with Tensor Cores , 8 2024. URL https://alexarmbr.github.io/2024/08/10/How-To-Write-A-Fast-Matrix-Multiplication-From-Scratch-With-Tensor-Cores.html

work page 2024

[7] [7]

How to optimize a CUDA matmul kernel for cuBLAS -like performance: a worklog, 12 2022

Boehm, S. How to optimize a CUDA matmul kernel for cuBLAS -like performance: a worklog, 12 2022. URL https://siboehm.com/articles/22/CUDA-MMM

work page 2022

[8] [8]

S., Michalewski, H., Osindero, S., and Rockt\" a schel, T

Fernando, C., Banarse, D. S., Michalewski, H., Osindero, S., and Rockt\" a schel, T. Promptbreeder: Self-referential self-improvement via prompt evolution. In Salakhutdinov, R., Kolter, Z., Heller, K., Weller, A., Oliver, N., Scarlett, J., and Berkenkamp, F. (eds.), Proceedings of the 41st International Conference on Machine Learning, volume 235 of Procee...

work page 2024