<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>CUDA | Prince Modi</title><link>https://princemodi.me/tag/cuda/</link><atom:link href="https://princemodi.me/tag/cuda/index.xml" rel="self" type="application/rss+xml"/><description>CUDA</description><generator>Hugo Blox Builder (https://hugoblox.com)</generator><language>en-us</language><lastBuildDate>Tue, 17 Mar 2026 00:00:00 +0000</lastBuildDate><image><url>https://princemodi.me/media/icon_hua5d2116872382d6405c4fb215e02fa8e_2300_512x512_fill_lanczos_center_3.png</url><title>CUDA</title><link>https://princemodi.me/tag/cuda/</link></image><item><title>Modern GPU DSLs: Performance and Portability</title><link>https://princemodi.me/post/flash-attention-dsl/</link><pubDate>Tue, 17 Mar 2026 00:00:00 +0000</pubDate><guid>https://princemodi.me/post/flash-attention-dsl/</guid><description>&lt;p>For my CSE 291P final project at UCSD, our team benchmarked how GPU domain-specific languages (DSLs) trade off performance, productivity, and portability. We implemented RMSNorm (memory-bound) and Flash Attention-2 (compute-bound) in four DSLs, Helion, Triton, Gluon, and CuTe, and ran them across four GPU generations: Tesla T4, RTX 4060 Ti, A100, and RTX 5090.&lt;/p>
&lt;h2 id="what-we-measured">What We Measured&lt;/h2>
&lt;p>Each DSL sits at a different point on the abstraction spectrum, from Helion (PyTorch-like, auto-tuned, compiles down to Triton) to CuTe (near-CUDA control over memory layouts, thread mapping, and MMA/copy atoms). We measured implementation complexity (lines of code, cyclomatic complexity), raw throughput (GB/s for RMSNorm, TFLOPS for Flash Attention), and how consistently each kernel&amp;rsquo;s hardware utilization held up when moved to a different GPU, using NVIDIA Nsight Compute profiles for compute and memory throughput.&lt;/p>
&lt;h2 id="what-we-found">What We Found&lt;/h2>
&lt;p>Implementation complexity scaled roughly exponentially as abstraction decreased, CuTe kernels needed an order of magnitude more code than Torch or Helion. Performance mostly tracked that same trend on the A100, with CuTe leading on both kernels, but with notable exceptions: Helion&amp;rsquo;s RMSNorm outperformed both Triton and Gluon by loading each row into SRAM once instead of twice, and CuTe&amp;rsquo;s Flash Attention advantage only showed up at longer context lengths.&lt;/p>
&lt;p>Portability told a different story. Triton and Gluon kernels tuned for the A100 lost significant memory throughput percentage when run on the T4, since their tile configurations were tuned for a GPU with more shared memory and stronger tensor cores. Helion, by contrast, held up more consistently across devices because its auto-tuner re-selects configurations per target rather than relying on one hand-tuned kernel, though at the cost of expensive tuning time.&lt;/p>
&lt;hr>
&lt;p>&lt;em>This was a course project for CSE 291P at UC San Diego, built with Hayden Prairie, Bhrugu Bharathi, Revant Mahajan, Cody Wang, Dario Wisznewer, and Rishabh Chittaranjan. I have the full report with additional figures and NCU analysis available on request, or check out the code at &lt;a href="https://github.com/prince-modi/gpu-kernel-dev" target="_blank" rel="noopener">github.com/prince-modi/gpu-kernel-dev&lt;/a>.&lt;/em>&lt;/p></description></item></channel></rss>