Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Correctly handle memory taken by objects in loops #1250

Merged
merged 3 commits into from
Feb 26, 2025

Conversation

PetroZarytskyi
Copy link
Collaborator

This PR addresses 2 issues:

  1. Currently, object adjoints copy the structure of the original variables (e.g. std::vector<...> _d_x(x);). However, if this happens in a loop, the structure of the adjoint _d_x might change every iteration. In the reverse pass, we will be left with whatever adjoint was left after the last iteration. This could lead to errors if, for example, the corresponding array had more elements on some previous iteration.
  2. When calling _reverse_forward functions, we store the result as a reference. The problem is that the result is stored as a local variable in the forward pass and cannot be used in the reverse mode. This was left unnoticed because the memory location of the local reference was not overwritten. However, when dealing with a local variable inside a loop, it's guaranteed to be overwritten on next iterations. The solution is to store the references on a tape.
    This PR also introduces a test for both issues. In theory, these issues could be considered and tested separately but each one breaks other tests when being introduced on its own. This happens because those tests are currently bugged but work under specific conditions.

Currently, object adjoints copy the structure of the original variables (e.g. ``std::vector<...> _d_x(x);``). However, if this happens in a loop, the structure of the adjoint ``_d_x`` might change every iteration. In the reverse pass, we will be left with whatever adjoint was left after the last iteration. This could lead to errors if, for example, the corresponding array had more elements on some previous iteration.
… in the reverse pass.

When calling ``_reverse_forward`` functions, we store the result as a reference. The problem is that the result is stored as a local variable in the forward pass and cannot be used in the reverse mode. This was left unnoticed because the memory location of the local reference was not overwritten. However, when dealing with a local variable inside a loop, it's guaranteed to be overwritten on next iterations. The solution is to store the references on a tape.
Copy link
Contributor

clang-tidy review says "All clean, LGTM! 👍"

Copy link

codecov bot commented Feb 25, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 94.67%. Comparing base (1a24e1b) to head (a3294e3).
Report is 3 commits behind head on master.

Additional details and impacted files

Impacted file tree graph

@@           Coverage Diff           @@
##           master    #1250   +/-   ##
=======================================
  Coverage   94.66%   94.67%           
=======================================
  Files          51       51           
  Lines        8910     8919    +9     
=======================================
+ Hits         8435     8444    +9     
  Misses        475      475           
Files with missing lines Coverage Δ
lib/Differentiator/ReverseModeVisitor.cpp 95.72% <100.00%> (+0.01%) ⬆️
Files with missing lines Coverage Δ
lib/Differentiator/ReverseModeVisitor.cpp 95.72% <100.00%> (+0.01%) ⬆️

Copy link
Contributor

clang-tidy review says "All clean, LGTM! 👍"

Copy link
Owner

@vgvassilev vgvassilev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@vgvassilev vgvassilev merged commit 0e3d04f into vgvassilev:master Feb 26, 2025
97 checks passed
@PetroZarytskyi PetroZarytskyi deleted the rev-ref branch February 26, 2025 13:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants