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
[DTensor] Used new placements for neg dim in redistribute
#113924
Conversation
[ghstack-poisoned]
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/113924
Note: Links to docs will display an error until the docs builds have been completed. ✅ You can merge normally! (1 Unrelated Failure)As of commit f2a382e with merge base 140c54e (): FLAKY - The following job failed but was likely due to flakiness present on trunk:
This comment was automatically generated by Dr. CI and updates every 15 minutes. |
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.
Have a few suggestions inlined, but in general this lgtm, stamp to unblock
if placement.is_partial(): | ||
raise RuntimeError( | ||
"Can not redistribute to _Partial, _Partial is for internal use only!" | ||
) | ||
elif isinstance(placement, Shard) and placement.dim < 0: | ||
# normalize shard dim to be positive | ||
placement.dim += self.ndim | ||
placements[i] = Shard(placement.dim + self.ndim) | ||
placements = tuple(placements) |
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.
nit: we can remove the tuple inside the Redistributed
Autograd function then? https://github.com/pytorch/pytorch/blob/main/torch/distributed/_tensor/redistribute.py#L190
We can also change the autograd function type annotation to align with tuple instead.
@@ -384,6 +384,10 @@ class DTensorSpec: | |||
# tensor meta will only be set during sharding propagation | |||
tensor_meta: Optional[TensorMeta] = None | |||
|
|||
def __post_init__(self): | |||
if not isinstance(self.placements, tuple): |
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.
Oh I think we don't need this check as the placements
here type are Tuple[Placement, ...]
so if we construct DTensorSpec with List[Placement] then mypy would error out iiuc.
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.
Do we have mypy enabled on all DTensor files? It seems to me we may prefer to have some runtime check, either as is now or to raise an error on a type other than tuple. I worry that static type checking might not prevent some silent errors at runtime if the user bypasses the static type check somehow.
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.
Oh my rationale was that DTensorSpec
is not a public API and only used for our internal development in pytorch, and since we enabled mypy check whenever we misuse it mypy would complain. But yeah a explicit runtime typecheck for safety also sounds good!
@@ -422,14 +422,16 @@ def redistribute( | |||
if placements is None: | |||
raise RuntimeError("placements is needed for redistribute!") | |||
|
|||
for placement in placements: | |||
placements = list(placements) |
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.
Another suggestion here is that maybe we can create a new list here instead of casting a potential tuple to list or modify the user passed in list, wdyt?
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 I understand correctly, calling list()
on an existing list creates a shallow copy. Shallow copy seems like the desired behavior since we only replace negative-dimension Shard
placements but not modify them in place, so we can reuse as much of the user's Placement
objects as possible? Let me know what you think.
>>> class A: # define some arbitrary class
>>> def __init__(self):
>>> self.a = 1
>>> l = [A(), A()]
>>> id(l)
140259468644864
>>> id(l[0])
140259469146912
>>> id(l[1])
140259469415216
>>> ll = list(l)
>>> id(ll)
140259468666560 <-- different
>>> id(ll[0])
140259469146912 <-- same
>>> id(ll[1])
140259469415216 <-- same
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.
Got it, yeah then we don't have concern that we modified the user passed in list, that convinced me!
[ghstack-poisoned]
Flaky unrelated failure: |
@pytorchbot merge -i |
Merge startedYour change will be merged while ignoring the following 1 checks: pull / linux-focal-py3_8-clang9-xla / test (xla, 1, 1, linux.12xlarge) Learn more about merging in the wiki. Questions? Feedback? Please reach out to the PyTorch DevX Team |
Pull Request resolved: #114134 Approved by: https://github.com/wanchaol ghstack dependencies: #113919, #113924
Pull Request resolved: #113925 Approved by: https://github.com/wanchaol ghstack dependencies: #113919, #113924, #114134
This is a replacement for #113922. I think we can still leave the check for negative shard dimension in `compute_local_shape_and_global_offset` and replace the normalization logic with an assert. This should provide us a stack trace to see which user-facing API did not normalize the dim as expected. Pull Request resolved: #114141 Approved by: https://github.com/wanchaol ghstack dependencies: #113919, #113924, #114134, #113925, #113930
**Overview** Generally, I think we can try to freeze as many of these classes used in DTensor sharding propagation as possible so that we can cache hashes. This PR targets hashing `DTensorSpec`, which turns out to be relatively expensive. **Details** It looks like `tensor_meta` is only updated in `_wrap_output_spec_tensor_meta`, which only runs if the propagation was not cached: https://github.com/pytorch/pytorch/blob/ae94c7e491e22f58d3df66571c1a568e51d70acd/torch/distributed/_tensor/sharding_prop.py#L137 https://github.com/pytorch/pytorch/blob/ae94c7e491e22f58d3df66571c1a568e51d70acd/torch/distributed/_tensor/sharding_prop.py#L153 In that case, I think we can cache the hash for the `DTensorSpec` and only update it when one of the hashed attributes changes, which we only really expect to happen for `tensor_meta`. To ensure correctness, we need that all hashed attributes are immutable. - `DeviceMesh` caches its hash: https://github.com/pytorch/pytorch/blob/a9134fa99a8986adf478a12db2ea5729d24554db/torch/distributed/_device_mesh.py#L181 - This PR makes each `Placement` a frozen `dataclass`, making them immutable (relying on the fact that they do not have references to any mutable objects). - `TensorMeta` is a `NamedTuple` of `torch.Size`, `Tuple[int, ...]`, and `torch.dtype`, so it is immutable: https://github.com/pytorch/pytorch/blob/9916d8a9eaaf2c05c131f2a2dbe9eabeeaa9dffc/torch/distributed/_tensor/placement_types.py#L369-L375 **Example** For some simple small GPT model: Before: 0.125 ms <img width="509" alt="Screenshot 2023-11-16 at 10 08 05 PM" src="https://github.com/pytorch/pytorch/assets/31054793/10e59401-f635-431f-80b5-1b48df3a706e"> After: 0.048 ms <img width="294" alt="Screenshot 2023-11-16 at 10 08 47 PM" src="https://github.com/pytorch/pytorch/assets/31054793/09a3b0b9-f68c-4afc-bca1-c29a4b01c2fb"> The overall Adam CPU step time decreases from 7.647 ms to 6.451 ms. Pull Request resolved: #113915 Approved by: https://github.com/wanchaol ghstack dependencies: #113919, #113924, #114134, #113925, #113930, #114141
This is a nit change to save one `isinstance` call for when `dim` is not `None` but the placement is not `Shard`. Pull Request resolved: #114140 Approved by: https://github.com/Skylion007, https://github.com/wanchaol ghstack dependencies: #113919, #113924, #114134, #113925, #113930, #114141, #113915
This is a forward fix for #113781. We lazily compute the hash so that we do not try to compute the hash on `SymInt`s (for the stride) during Dynamo tracing. Tested via: ``` python test/distributed/_tensor/test_dtensor_compile.py -k test_2d_fsdp_tp_ac_compile ``` Pull Request resolved: #114322 Approved by: https://github.com/wanchaol ghstack dependencies: #113919, #113924, #114134, #113925, #113930, #114141, #113915, #114140
Stack from ghstack (oldest at bottom):
isinstance
call inis_shard
#114140DTensorSpec
#113915distribute_tensor
#113930grad_placements
was tuple #113925from_local
#114134redistribute
#113924_Partial
,Replicate
frozen dataclasses #113919