Don't copy or retain C in the ChainRules rules when β = Zero() - #308
Merged
Merged
Conversation
Member
|
The main gain here comes from the |
Member
Author
|
Yes, the gain comes from |
Codecov Report✅ All modified and coverable lines are covered by tests.
... and 7 files with indirect coverage changes 🚀 New features to boost your workflow:
|
lkdvos
approved these changes
Sep 25, 2026
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A next thing I ran into while trying to reduce AD tape sizes used in implicit differentiation: the Chainrules implementations quite often track things they don't need to, leading to chained pullbacks carrying around more memory than they need to (at least for my specific use cases).
I'm not sure if the proposed fix here is the right way to go, but I thought I might as well attach it here as a suggested fix for the actual issue I'm reporting here.
Description
@tensorfills every new or temporary array withtensorcontract!(C, …, α, Zero())(likewisetensoradd!,tensortrace!). The rules then copyC, although withβ = Zero()its contentsare never read, and the pullback keeps the original
Calive until the reverse pass, since itpasses
Cto helpers that don't use it. Every@tensorcontraction on the tape thus holds adead array of the output's size.
Change
β === Zero(), write intosimilar(C)instead ofcopy(C). The kernels never read thedestination then, but the default and
StridedNativebackends touch it, which fails for anuninitialized non-isbits array, hence
zerovector!!(similar(C))in that case.Conly ifdβneeds it.NoTangent()rather thanZeroTangent()for a constantβ, so thattest_rruleaccepts
β = Zero().Effect
One enlarged-corner (issue surfaced in the context of PEPSKit.jl)
@tensorcontraction onArray{Float64}, differentiated with Zygote:"Memory held" is the live heap after a full GC with the pullback alive, minus that before the
forward pass. This lowers peak memory under AD; allocations and GC work are unchanged.
Reproducer
Tests
test/ad.jlgains aβ = Zero()test_rrulecase for each rule, and a check that anuninitialized
BigFloatCworks withβ = Zero().