<?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>Unified-Memory on Sanketh's Blog</title><link>https://sankethbk.github.io/blog/tags/unified-memory/</link><description>Recent content in Unified-Memory 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/unified-memory/index.xml" rel="self" type="application/rss+xml"/><item><title>CUDA Unified Memory: One Pointer, Two Processors</title><link>https://sankethbk.github.io/blog/posts/gpu/2026-09-04-1-cuda-unified-memory/</link><pubDate>Fri, 04 Sep 2026 00:00:00 +0000</pubDate><guid>https://sankethbk.github.io/blog/posts/gpu/2026-09-04-1-cuda-unified-memory/</guid><description>&lt;h1 id="cuda-unified-memory-one-pointer-two-processors"&gt;CUDA Unified Memory: One Pointer, Two Processors&lt;/h1&gt;
&lt;p&gt;The &lt;a href="https://sankethbk.github.io/blog/gpu/2026-09-02-2-cuda-streams"&gt;previous note&lt;/a&gt; covered explicit CUDA streams and how to overlap host-device transfers with computation. This note covers &lt;strong&gt;Unified Memory&lt;/strong&gt;, an alternative to explicit &lt;code&gt;cudaMalloc&lt;/code&gt; / &lt;code&gt;cudaMemcpy&lt;/code&gt; / &lt;code&gt;cudaFree&lt;/code&gt;. It lets both CPU and GPU use a single pointer, at the cost of some performance complexity under the hood.&lt;/p&gt;
&lt;p&gt;Unified Memory is seductive: it removes the need to think about host and device pointers separately. But it does not remove the physical reality that CPU and GPU memory are separate. Understanding when it helps and when it hurts is essential.&lt;/p&gt;</description></item></channel></rss>