<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Performance on Sanketh's Blog</title><link>https://sankethbk.github.io/blog/tags/performance/</link><description>Recent content in Performance on Sanketh's Blog</description><generator>Hugo -- 0.166.0</generator><language>en-us</language><lastBuildDate>Fri, 04 Sep 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://sankethbk.github.io/blog/tags/performance/index.xml" rel="self" type="application/rss+xml"/><item><title>CUDA Profiling and Performance Measurement</title><link>https://sankethbk.github.io/blog/posts/gpu/2026-09-04-2-cuda-profiling/</link><pubDate>Fri, 04 Sep 2026 00:00:00 +0000</pubDate><guid>https://sankethbk.github.io/blog/posts/gpu/2026-09-04-2-cuda-profiling/</guid><description>&lt;h1 id="cuda-profiling-and-performance-measurement"&gt;CUDA Profiling and Performance Measurement&lt;/h1&gt;
&lt;p&gt;The notes up to this point covered what makes CUDA kernels fast in theory: coalescing, tiling, occupancy, and asynchronous execution. This note covers how to &lt;strong&gt;measure&lt;/strong&gt; whether a kernel is actually fast and how to find the bottleneck when it is not.&lt;/p&gt;
&lt;p&gt;Profiling is what separates guessing from optimization. Without it, you can apply every best practice and still be slower than a simpler implementation.&lt;/p&gt;</description></item><item><title>CUDA Streams and Host/Device Overlap</title><link>https://sankethbk.github.io/blog/posts/gpu/2026-09-02-2-cuda-streams/</link><pubDate>Wed, 02 Sep 2026 00:00:00 +0000</pubDate><guid>https://sankethbk.github.io/blog/posts/gpu/2026-09-02-2-cuda-streams/</guid><description>&lt;h1 id="cuda-streams-and-hostdevice-overlap"&gt;CUDA Streams and Host/Device Overlap&lt;/h1&gt;
&lt;p&gt;The &lt;a href="https://sankethbk.github.io/blog/gpu/2026-09-02-1-cuda-reduction"&gt;previous note&lt;/a&gt; covered reduction, the first parallel algorithm on the GPU side. This note moves to the &lt;strong&gt;host-device boundary&lt;/strong&gt;: how to keep the GPU busy while the CPU prepares the next batch of data, and how to overlap data movement with computation.&lt;/p&gt;
&lt;p&gt;So far, every kernel launch and every &lt;code&gt;cudaMemcpy&lt;/code&gt; has been synchronous. The host waits, the GPU works, the host waits again. CUDA &lt;strong&gt;streams&lt;/strong&gt; let you break that pattern.&lt;/p&gt;</description></item><item><title>CUDA Occupancy: Filling the SM to Hide Latency</title><link>https://sankethbk.github.io/blog/posts/gpu/2026-09-01-2-cuda-occupancy/</link><pubDate>Tue, 01 Sep 2026 00:00:00 +0000</pubDate><guid>https://sankethbk.github.io/blog/posts/gpu/2026-09-01-2-cuda-occupancy/</guid><description>&lt;h1 id="cuda-occupancy-filling-the-sm-to-hide-latency"&gt;CUDA Occupancy: Filling the SM to Hide Latency&lt;/h1&gt;
&lt;p&gt;The &lt;a href="https://sankethbk.github.io/blog/gpu/2026-09-01-1-cuda-shared-memory-tiling"&gt;previous note&lt;/a&gt; showed how to use shared memory to fix uncoalesced access patterns. This note covers &lt;strong&gt;occupancy&lt;/strong&gt;: how many warps can live on an SM at the same time, and why that number determines whether the GPU can hide memory latency.&lt;/p&gt;
&lt;p&gt;Occupancy is the first CUDA performance topic that is not about memory access at all. It is about keeping the warp schedulers busy.&lt;/p&gt;</description></item><item><title>CUDA Shared Memory Tiling</title><link>https://sankethbk.github.io/blog/posts/gpu/2026-09-01-1-cuda-shared-memory-tiling/</link><pubDate>Tue, 01 Sep 2026 00:00:00 +0000</pubDate><guid>https://sankethbk.github.io/blog/posts/gpu/2026-09-01-1-cuda-shared-memory-tiling/</guid><description>&lt;h1 id="cuda-shared-memory-tiling"&gt;CUDA Shared Memory Tiling&lt;/h1&gt;
&lt;p&gt;The &lt;a href="https://sankethbk.github.io/blog/gpu/2026-08-30-3-cuda-memory-coalescing"&gt;previous note&lt;/a&gt; showed that coalesced memory access is the key to memory-bound kernel performance. But some algorithms naturally want uncoalesced access patterns. The fix is &lt;strong&gt;shared-memory tiling&lt;/strong&gt;: load data into fast on-chip SRAM in a coalesced way, rearrange it there, then write it back to global memory in a coalesced way.&lt;/p&gt;
&lt;p&gt;This note explains the tiling pattern, why &lt;code&gt;__syncthreads()&lt;/code&gt; is essential, the bank-conflict problem, and how to choose tile sizes.&lt;/p&gt;</description></item><item><title>CUDA Memory Coalescing: Why Access Patterns Matter</title><link>https://sankethbk.github.io/blog/posts/gpu/2026-08-30-3-cuda-memory-coalescing/</link><pubDate>Sun, 30 Aug 2026 00:00:00 +0000</pubDate><guid>https://sankethbk.github.io/blog/posts/gpu/2026-08-30-3-cuda-memory-coalescing/</guid><description>&lt;h1 id="cuda-memory-coalescing-why-access-patterns-matter"&gt;CUDA Memory Coalescing: Why Access Patterns Matter&lt;/h1&gt;
&lt;p&gt;The &lt;a href="https://sankethbk.github.io/blog/gpu/2026-08-30-2-cuda-programming-model"&gt;previous note&lt;/a&gt; showed how to write and launch a CUDA kernel. This note answers the first performance question: why does the same kernel sometimes run 5× or 10× slower just because of how threads read memory?&lt;/p&gt;
&lt;p&gt;The answer is &lt;strong&gt;memory coalescing&lt;/strong&gt;. Because GPU memory is optimized for bandwidth over latency, the hardware rewards access patterns where threads in a warp read or write contiguous addresses together. If they do not, the GPU wastes bandwidth and cycles fetching data that most threads ignore.&lt;/p&gt;</description></item></channel></rss>