Activation Checkpointing Behavior with Branches

justin.yan: <p>Hi all!</p>
<p>I’m trying to understand how activation checkpointing does or does not affect the order of gradient propagation during the backward pass, and I hope someone can help me <img src="https://discuss.pytorch.org/images/emoji/apple/slight_smile.png?v=12" title=":slight_smile:" class="emoji" alt=":slight_smile:" loading="lazy" width="20" height="20"></p>
<p>To set up a contrived example:</p>
<pre><code class="lang-auto">class L1(nn.Module):
    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self.l = Linear(64, 8192)

    def forward(self, x: Float[torch.Tensor, "B 64"]):
        print("l1")
        return self.l(x)

class L2(nn.Module):
    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self.l = Linear(8192, 16)

    def forward(self, x: Float[torch.Tensor, "B 256"]):
        print("l2")
        return self.l(x)

class L3(nn.Module):
    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self.l = Linear(16, 1)

    def forward(self, x: Float[torch.Tensor, "B 16"]):
        print("l3")
        return self.l(x)

class Wrap(nn.Module):
    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self.l1 = L1()
        self.l2 = L2()
        self.l3 = L3()

    def forward(self, x: Float[torch.Tensor, "B 64"]):
        def forward_layers(x):
            y = self.l1(x)
            y = self.l2(y)
            y = self.l3(y)
            return y

        out = None
        for i in range(50):
            # y = checkpoint(forward_layers, x, use_reentrant=False)
            y = forward_layers(x)
            out = (out + y) if out is not None else y
        return out
</code></pre>
<p>What I observe is that if I pass this layer through a forward, trivial loss (sum), and then backward, the maximum memory consumption when I use checkpointing appears to remain constant regardless of how many branches I create (the size of the for loop), whereas when checkpointing is off, memory consumption increases linearly with the number parallel branches (as expected).</p>
<p>I’m basically trying to understand what it is in the backward pass that actually implements this, and whether this is intentional or if it’s just an artifact of how it happens to be implemented currently.</p>
<p>As a new user I only get two links, so I’ll post my refs here and reference them below:</p>
<ul>
<li>python_function.h: <a href="https://github.com/pytorch/pytorch/blob/7b280c31bac252c7741067a68b1675aefeb1da35/torch/csrc/autograd/python_function.h#L133" class="inline-onebox" rel="noopener nofollow ugc">pytorch/torch/csrc/autograd/python_function.h at 7b280c31bac252c7741067a68b1675aefeb1da35 · pytorch/pytorch · GitHub</a></li>
<li>engine.cpp: <a href="https://github.com/pytorch/pytorch/blob/main/torch/csrc/autograd/engine.cpp#L449-L454" class="inline-onebox" rel="noopener nofollow ugc">pytorch/torch/csrc/autograd/engine.cpp at main · pytorch/pytorch · GitHub</a></li>
<li>checkpoint.py: pytorch/blob/main/torch/utils/checkpoint.py#L1099</li>
</ul>
<p>I got as far as understanding:</p>
<ul>
<li>The saved_tensors_hook in the non-reentrant checkpoint (checkpoint.py) and that the unpack hook triggers the recomputation on access (checkpoint.py#L1125).</li>
<li>I couldn’t quite figure out how this hooks into the C++ autograd engine.  My best guess was that this object held the references to these tensors here (python_function.h), and there seem to be corresponding methods for executing the unpack.  I had a bit of trouble following the types so couldn’t quite figure out how exactly this hooked into the C++ autograd engine execute, but it seems like these are lazily unpacked when they’re needed(?)</li>
</ul>
<p>Assuming those are roughly “in the ballpark”, the question that I’m the most confused about is understanding the <em>order</em> in which the autograd engine goes through the graph.  The things that I <em>think</em> are the case:</p>
<ul>
<li>The autograd engine spins up one thread per device, but otherwise doesn’t do anything concurrently - e.g. for the 50 branches created by my for loop, if all of the tensors are on one device, will not be backprop-ed concurrently.</li>
<li>Torch does a topological sort by distance from the leaf nodes.</li>
<li>The starting set of nodes are populated with the “roots”.</li>
</ul>
<p>The observation that I made where using checkpointing means that I can increase the loop_size with minimal impact to memory suggests to me that what’s happening is that torch is backprop-ing through an entire branch (l3 → l2 → l1) before proceeding to another, so that the activations can be discarded.</p>
<p>I <em>think</em> the backprop ordering is constrained by the topological sort (all dependencies need to be satisfied), but that it’s otherwise controlled by this sequence number (engine.cpp).  However, I’m a bit lost on:</p>
<p>a. how/where this sequence number gets set to begin with, and<br>
b. how the recomputation during the unpack hook (checkpoint.py#L1124-L1125) is able to get added to the computational graph (and where the sequence number would be set to get it to the top(?) of the priority queue).  My understanding is that the non-reentrant checkpoint is specifically <em>not</em> invoking .backward() a second time, so would that mean it’s all part of the same GraphTask?</p>
<p>Am I on the right track here?  I feel like I’m close and would really appreciate some pointers to help me get over the hump!</p>

cris458carlo: <aside class="quote no-group quote-modified" data-username="justin.yan" data-post="1" data-topic="209127">
<div class="title">
<div class="quote-controls"></div>
<img loading="lazy" alt="" width="24" height="24" src="https://discuss.pytorch.org/letter_avatar_proxy/v4/letter/j/45deac/48.png" class="avatar"> justin.yan:</div>
<blockquote>
<p>I’m trying to understand how activation checkpointing does or does not affect the order of gradient propagation during the backward pass, and I hope someone can help me <img src="https://discuss.pytorch.org/images/emoji/apple/slight_smile.png?v=12" title=":slight_smile:" class="emoji" alt=":slight_smile:" loading="lazy" width="20" height="20"></p>
<p>To set up a contrived example:</p>
<pre><code class="lang-auto">class L1(nn.Module):
    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self.l = Linear(64, 8192)

    def forward(self, x: Float[torch.Tensor, "B 64"]):
        print("l1")
        return self.l(x)

class L2(nn.Module):
    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self.l = Linear(8192, 16)

    def forward(self, x: Float[torch.Tensor, "B 256"]):
        print("l2")
        return self.l(x)

class L3(nn.Module):
    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self.l = Linear(16, 1)

    def forward(self, x: Float[torch.Tensor, "B 16"]):
        print("l3")
        return self.l(x)

class Wrap(nn.Module):
    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self.l1 = L1()
        self.l2 = L2()
        self.l3 = L3()

    def forward(self, x: Float[torch.Tensor, "B 64"]):
        def forward_layers(x):
            y = self.l1(x)
            y = self.l2(y)
            y = self.l3(y)
            return y

        out = None
        for i in range(50):
            # y = checkpoint(forward_layers, x, use_reentrant=False)
            y = forward_layers(x)
            out = (out + y) if out is not None else y
        return out
</code></pre>
<p>What I observe is that if I pass this layer through a forward, trivial loss (sum), and then backward, the maximum memory consumption when I use checkpointing appears to remain constant regardless of how many branches I create (the size of the for loop), whereas when checkpointing is off, memory consumption increases linearly with the number parallel branches (as expected).</p>
<p>I’m basically trying to understand what it is in the backward pass that actually implements this, and whether this is intentional or if it’s just an artifact of how it happens to be implemented currently.</p>
<p>As a new user I only get two links, so I’ll post my refs here and reference them below:</p>
<p>I got as far as understanding:</p>
<ul>
<li>The saved_tensors_hook in the non-reentrant checkpoint (checkpoint.py) and that the unpack hook triggers the recomputation on access (checkpoint.py#L1125).</li>
<li>I couldn’t quite figure out how this hooks into the C++ autograd engine. My best guess was that this object held the references to these tensors here (python_function.h), and there seem to be corresponding methods for executing the unpack. I had a bit of trouble following the types so couldn’t quite figure out how exactly this hooked into the C++ autograd engine execute, but it seems like these are lazily unpacked when they’re needed(?)</li>
</ul>
<p>Assuming those are roughly “in the ballpark”, the question that I’m the most confused about is understanding the <em>order</em> in which the autograd engine goes through the graph. The things that I <em>think</em> are the case:</p>
<ul>
<li>The autograd engine spins up one thread per device, but otherwise doesn’t do anything concurrently - e.g. for the 50 branches created by my for loop, if all of the tensors are on one device, will not be backprop-ed concurrently.</li>
<li>Torch does a topological sort by distance from the leaf nodes.</li>
<li>The starting set of nodes are populated with the “roots”.</li>
</ul>
<p>The observation that I made where using checkpointing means that I can increase the loop_size with minimal impact to memory suggests to me that what’s happening is that torch is backprop-ing through an entire branch (l3 → l2 → l1) before proceeding to another, so that the activations can be discarded.</p>
<p>I <em>think</em> the backprop ordering is constrained by the topological sort (all dependencies need to be satisfied), but that it’s otherwise controlled by this sequence number (engine.cpp). However, I’m a bit lost on:</p>
<p>a. how/where this sequence number gets set to begin with, and<br>
b. how the recomputation during the unpack hook (checkpoint.py#L1124-L1125) is able to get added to the computational graph (and where the sequence number would be set to get it to the top(?) of the priority queue). My understanding is that the non-reentrant checkpoint is specifically <em>not</em> invoking .backward() a second time, so would that mean it’s all part of the same GraphTask?</p>
<p>Am I on the right track here? I feel like I’m close and would really appreciate some pointers to help me get over the hump!</p>
</blockquote>
</aside>
<p>Hello,</p>
<p>You are deep into understanding how activation checkpointing affects memory usage and gradient computation in PyTorch. I’ll provide some insights and clarification on the key points related to checkpointing, the backward pass, and the order of gradient propagation.</p>
<p>Thanks for sharing this type of information.</p>
<p>Best regards!<br>
<a href="https://www.maxim-timeclock.com" rel="noopener nofollow ugc">Maxim Time Clock features</a></p>