-
Notifications
You must be signed in to change notification settings - Fork 360
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
Per sample grad correctness util #532
Conversation
@psolikov has updated the pull request. You must reimport the pull request before landing. |
@facebook-github-bot has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
@psolikov has updated the pull request. You must reimport the pull request before landing. |
@facebook-github-bot has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot for the amazing work!
It would be really great, if you can also update the relevant tutorial to mention this util exists and how to use it (https://github.com/pytorch/opacus/blob/main/tutorials/guide_to_grad_sampler.ipynb)
As for the test errors, you can ignore all the coveralls. The rest - your unit tests are failing because functorch tests is run on the nightly pytorch - see an example how we handle it
Summary: Pull Request resolved: pytorch#520 sr stands for sampling rate, which is now legacy code. Now, it's just sample_rate = 1 / len(data_loader). This has been fixed in the example, by setting batch size to be 60000 * 0.004 = 240 (thanks to https://github.com/ffuuugor for the clarification). On another note, when running with DP, the following error is thrown ``` AttributeError: Can't pickle local object 'wrap_collate_with_empty.<locals>.collate' ``` For now, a temporary fix (based on IBM/Project_CodeNet#21 (comment)) is to make num_workers=0 in the dataset loaders. This commit does that. Reviewed By: ffuuugor Differential Revision: D40253037 fbshipit-source-id: 99984f8963a4efea6829d109bb81acff0e587c93
Summary: *The investigation part for this PR was done by alexandresablayrolles, thanks for figuring out the reason the tests were failing* ## Background Current implementation of functorch-based per sample gradients fails on modules which have both trainable non-recursive parameters and standard submodules, e.g. below ``` class LinearWithExtraParam(nn.Module): def __init__(self, in_features: int, out_features: int, hidden_dim: int = 8): super().__init__() self.fc = nn.Linear(in_features, hidden_dim) self.extra_param = nn.Parameter(torch.randn(hidden_dim, out_features)) def forward(self, x): x = self.fc(x) x = x.matmul(self.extra_param) return x ``` The reason is - functorch hook actually computes gradients for recursive submodules too. The problem is, normal hooks are also attached to these submodules. GradSampleModule then sees two grad_sample tensors, thinks it needs to accumulate and adds them up together ## Solution(s) There are essentially two ways we can fix this: either make functorch compute per sample gradients for non-recursive parameters only or don't attach normal hooks to submodules where the parent module is handled by functorch. This diff implements the latter option (reasoning below), for demo purposes the former option can be seen in pytorch#531 For the pure code perspective the former option (let's call it "non-recursive functorch") is more appealing to me. It better fits the existing paradigm and matches normal hooks behaviour - all of the existing code only deals with the immediate non-recursive parameters. However, it doesn't make much sense from the efficiency perspective. "non-recursive functorch" would do all the work to compute per-sample gradients for its submodules, only for them to be filtered out at the very last stage. Alternative option (a.k.a. "functorch for subtrees") does involve a bit more convoluted This has a noticeable effect on performance. Below is the results of MNIST benchmarks with different configurations. I've tested this with different configurations, because at the end of the day, the impact on performance depends on how deep are subtrees * Standard model- our model from MNIST example, standard layers only (2 conv + 2 linear). No overhead expected, functorch doesn't kick in * Mid-level model - leaf nodes (two linear layers) have one extra param and are computed with functorch. Overhead: 2x Linear hook * Extreme model - root model have one extra param and needs to be handled by functorch. Overhead: 2x linear hook + 2x conv hook | Mode | non-recursive functorch | functorch for subtrees | |:-----------------------:|:------------------------:|:-----------------------:| | Standard model (CPU) | 138s | 136s | | Standard model (GPU) | 149s | 150s | | Mid-level model (CPU) | 157s | 150s | | Mid-level model (GPU) | 100s | 97s | | Extreme model (CPU) | 207s | 172s | | Extreme model (GPU) | 101s | 94s | Pull Request resolved: pytorch#510 Reviewed By: alexandresablayrolles Differential Revision: D39579487 Pulled By: ffuuugor fbshipit-source-id: 1b089bd04ab110174a1f2ebb371380eb2ce76054
@psolikov has updated the pull request. You must reimport the pull request before landing. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great, thanks for updating the PR and addressing the comments!
I still have some comments (see inline), but we're definitely getting closer to landing this. Thanks again for your work!
P.S: Some of the test fails look related to your changes, please double check
@psolikov has updated the pull request. You must reimport the pull request before landing. |
@psolikov has updated the pull request. You must reimport the pull request before landing. |
@psolikov has updated the pull request. You must reimport the pull request before landing. |
@psolikov has updated the pull request. You must reimport the pull request before landing. |
# Conflicts: # opacus/data_loader.py # opacus/tests/grad_samples/common.py # opacus/tests/grad_samples/conv1d_test.py # opacus/tests/grad_samples/conv2d_test.py # opacus/tests/grad_samples/embedding_test.py # opacus/tests/grad_samples/group_norm_test.py # opacus/tests/grad_samples/linear_test.py
@psolikov has updated the pull request. You must reimport the pull request before landing. |
@psolikov has updated the pull request. You must reimport the pull request before landing. |
@facebook-github-bot has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
@psolikov has updated the pull request. You must reimport the pull request before landing. |
@facebook-github-bot has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool! Thanks a lot for finalising the work!
@psolikov has updated the pull request. You must reimport the pull request before landing. |
@facebook-github-bot has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
Types of changes
Motivation and Context / Related issue
Implementation of the utility described in #484.
Refactored the code to avoid code duplicates.
How Has This Been Tested (if it applies)
Added the new utility as a test case for existing tests stored in
tests.grad_samples
.Checklist