-
Notifications
You must be signed in to change notification settings - Fork 3.4k
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
device property #1791
device property #1791
Conversation
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.
I like it read only :)
consider also my comment here
#1790 (comment)
for better code style and flexibility
self.device = torch.device('cuda', self.root_gpu) | ||
self._device = torch.device('cuda', self.root_gpu) |
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.
we could remove all of these calls in the trainer by overloading .to()
and .cuda()
in LightningModule and setting the device there.
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.
You also need to overload .cpu()
:)
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.
sorry, maybe i’m missiny something. The point of self.device is to have a readonly property to create tensors in memory directly.
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.
If we overload the the .to()
method like this for example:
def to(self, device):
self._device = device
return super().to(device)
Then we get the following benefits:
- self.device property will not break when LightningModule is used as nn.Module without Trainer
- When LightningModule is a nested LightningModule and user calls .to(), also the self.device properties of submodules get updated
- The Trainer code does not need to set the device, it calls .to anyway, so the code is in one place and is easier to maintain.
I see only benefits atm
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.
@justusschock also did it like this for metrics package
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.
so we need to overwrite the following methods:
.to(...)
.cpu()
.cuda()
or am I missing any? @awaelchli ^^
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.
yep, exactly, although I suspect cpu and cuda already call .to internally. Not sure, need to check. EDIT: nope they don't we need all three :)
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.
well it seems to me that ideally, we want to rise the whole template from metrics...
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.
probably not all. device.setter, dtype does not apply for LightningModule I think? I agree we should try to avoid code duplication.
@justusschock what do you think?
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.
I think, while we do this, we should think about introducing the same for dtype, since when I create a tensor in a function, it usually involves a certain dtype as well. Although I'm not sure, if this would be reflected by amp as well...
Codecov Report
@@ Coverage Diff @@
## master #1791 +/- ##
======================================
- Coverage 88% 88% -0%
======================================
Files 69 69
Lines 4316 4322 +6
======================================
+ Hits 3805 3809 +4
- Misses 511 513 +2 |
yeah, good catch. This is meant as read-only. the motivation is to support tensors on device directly. torch.rand(..., device=self.device) |
self.device = torch.device('cuda', self.root_gpu) | ||
self._device = torch.device('cuda', self.root_gpu) |
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.
sorry, maybe i’m missiny something. The point of self.device is to have a readonly property to create tensors in memory directly.
Great job! =) |
@awaelchli @justusschock I have just copy-pasted the basic template from Metrics as it contains all we need now and later we can just inherit it back... are you fine with this solution? |
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.
You probably need to rise the corresponding tests as well :)
Also I'd probably rename the Mixin to reflect which properties it provides to something like |
Co-authored-by: Justus Schock <12886177+justusschock@users.noreply.github.com>
seems to fail on unrelated doctest (I have not changed Trainer) |
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.
LGTM, just one question
pytorch_lightning/trainer/trainer.py
Outdated
@@ -529,6 +529,10 @@ def __init__( | |||
# Callback system | |||
self.on_init_end() | |||
|
|||
@property | |||
def device(self) -> Union[None, str, object]: |
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.
To me it is not clear, why the trainer should have such a property as well?
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.
it was there before, I just made it as read-only, but agree that it is strange
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.
I would remove it, it's not needed as far as I can tell, since now it has shifted over to the module
i love how this escalated haha |
it seems that there is API change in pt 1.5
but it is strange that the torch master uses the same https://github.com/pytorch/pytorch/blob/master/torch/nn/modules/module.py |
@Borda Just FYI: it doesn't use the same. There is an additional argument for formatting introduced... |
yes, but pt < 1.5 has only three output vars, right... |
What does this PR do?
Fixes #1790 (comment)
PR review
Anyone in the community is free to review the PR once the tests have passed.
If we didn't discuss your PR in Github issues there's a high chance it will not be merged.
Did you have fun?
Make sure you had fun coding 🙃