KEMBAR78
[dynamo] add torch.compiler.set_stance by williamwen42 · Pull Request #137504 · pytorch/pytorch · GitHub
Skip to content

Conversation

@williamwen42
Copy link
Member

@williamwen42 williamwen42 commented Oct 8, 2024

Stack from ghstack (oldest at bottom):

Attempt # 2 at #132926 to implement #123771.

Implement a new torch.compiler.set_stance function that can force torch.compile regions to run eagerly.

See added tests for usage examples.

cc @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @chenyang78 @kadeng @chauhang @amjames @rec

@pytorch-bot
Copy link

pytorch-bot bot commented Oct 8, 2024

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/137504

Note: Links to docs will display an error until the docs builds have been completed.

✅ No Failures

As of commit 6248c56 with merge base 370d66d (image):
💚 Looks good so far! There are no failures yet. 💚

This comment was automatically generated by Dr. CI and updates every 15 minutes.

Attempt #2 at #132926 to implement #123771.

Implement a new `torch.compiler.set_phase` function that can force `torch.compile` regions to run eagerly. Other options (such as "fail_on_recompile" and "eager_on_recompile") to be added in a followup PR.

See added tests for usage examples.

cc voznesenskym penguinwu EikanWang jgong5 Guobing-Chen XiaobingSuper zhuhaozhe blzheng wenzhe-nrv jiayisunx chenyang78 kadeng chauhang amjames rec

[ghstack-poisoned]
williamwen42 added a commit that referenced this pull request Oct 8, 2024
ghstack-source-id: 38943fa
Pull Request resolved: #137504
Attempt #2 at #132926 to implement #123771.

Implement a new `torch.compiler.set_phase` function that can force `torch.compile` regions to run eagerly. Other options (such as "fail_on_recompile" and "eager_on_recompile") to be added in a followup PR.

See added tests for usage examples.

cc voznesenskym penguinwu EikanWang jgong5 Guobing-Chen XiaobingSuper zhuhaozhe blzheng wenzhe-nrv jiayisunx chenyang78 kadeng chauhang amjames rec

[ghstack-poisoned]
williamwen42 added a commit that referenced this pull request Oct 9, 2024
ghstack-source-id: 681f724
Pull Request resolved: #137504
@jansel
Copy link
Contributor

jansel commented Oct 10, 2024

Also note that a version of eager_on_recompile already exists with torch._dynamo.run (maps to set_eval_frame(True)), so no need to recreate that.

Similarly, fail_on_recompile can be done by setting the backend to one that raises an error (without any changes to eval_frame.c).

Attempt #2 at #132926 to implement #123771.

Implement a new `torch.compiler.set_phase` function that can force `torch.compile` regions to run eagerly. Other options (such as "fail_on_recompile" and "eager_on_recompile") to be added in a followup PR.

See added tests for usage examples.

cc voznesenskym penguinwu EikanWang jgong5 Guobing-Chen XiaobingSuper zhuhaozhe blzheng wenzhe-nrv jiayisunx chenyang78 kadeng chauhang amjames rec

[ghstack-poisoned]
williamwen42 added a commit that referenced this pull request Oct 11, 2024
ghstack-source-id: f4973b1
Pull Request resolved: #137504
@williamwen42 williamwen42 changed the title [dynamo] add torch.compiler.set_phase [dynamo] add torch.compiler.set_stance Oct 11, 2024
Attempt #2 at #132926 to implement #123771.

Implement a new `torch.compiler.set_stance` function that can force `torch.compile` regions to run eagerly.

See added tests for usage examples.

cc voznesenskym penguinwu EikanWang jgong5 Guobing-Chen XiaobingSuper zhuhaozhe blzheng wenzhe-nrv jiayisunx chenyang78 kadeng chauhang amjames rec

[ghstack-poisoned]
williamwen42 added a commit that referenced this pull request Oct 12, 2024
ghstack-source-id: 208f915
Pull Request resolved: #137504
@ezyang
Copy link
Contributor

ezyang commented Oct 12, 2024

I'm going to defer to @jansel on this since he has more opinions on the internal implementation details, but holler if you need me to unblock you

Attempt # 2 at #132926 to implement #123771.

Implement a new `torch.compiler.set_stance` function that can force `torch.compile` regions to run eagerly.

See added tests for usage examples.

cc voznesenskym penguinwu EikanWang jgong5 Guobing-Chen XiaobingSuper zhuhaozhe blzheng wenzhe-nrv jiayisunx chenyang78 kadeng chauhang amjames rec

[ghstack-poisoned]
@pytorchmergebot
Copy link
Collaborator

Merge started

Your change will be merged once all checks pass (ETA 0-4 Hours).

Learn more about merging in the wiki.

Questions? Feedback? Please reach out to the PyTorch DevX Team

Advanced Debugging
Check the merge workflow status
here

@pytorchmergebot
Copy link
Collaborator

The merge job was canceled or timed out. This most often happen if two merge requests were issued for the same PR, or if merge job was waiting for more than 6 hours for tests to finish. In later case, please do not hesitate to reissue the merge command
For more information see pytorch-bot wiki.

@williamwen42
Copy link
Member Author

@pytorchbot merge

@pytorchmergebot
Copy link
Collaborator

Merge started

Your change will be merged once all checks pass (ETA 0-4 Hours).

Learn more about merging in the wiki.

Questions? Feedback? Please reach out to the PyTorch DevX Team

Advanced Debugging
Check the merge workflow status
here

yf225 added a commit that referenced this pull request Oct 16, 2024
…to fallback to eager"

Dynamo stance is recently added in #137504. When Dynamo stance is "force_eager" (user explicitly wants to fall back to eager), we would like Compiled Autograd to fall back to eager as well. This will allow the Traceable FSDP2 use case to work since "eager forward + compiled autograd backward" is not supported for Traceable FSDP2.

In general, if user wants to do "eager forward + compiled autograd backward", they should explicitly run the forward in eager instead of applying compile and then set stance to "force_eager".




cc XilunWu H-Huang awgu kwen2501 wanchaol fegin fduwjj wz337 wconstab d4l3k c-p-i-o voznesenskym penguinwu EikanWang jgong5 Guobing-Chen XiaobingSuper zhuhaozhe blzheng wenzhe-nrv jiayisunx chenyang78 kadeng chauhang amjames rec xmfan

[ghstack-poisoned]
pytorchmergebot pushed a commit that referenced this pull request Oct 17, 2024
… to eager (#138113)

Dynamo stance is recently added in #137504. When Dynamo stance is "force_eager" (user explicitly wants to fall back to eager), we would like Compiled Autograd to fall back to eager as well. This will allow the Traceable FSDP2 use case to work since "eager forward + compiled autograd backward" is not supported for Traceable FSDP2.

In general, if user wants to do "eager forward + compiled autograd backward", they should explicitly run the forward in eager instead of applying compile and then set stance to "force_eager".

Pull Request resolved: #138113
Approved by: https://github.com/xmfan
ghstack dependencies: #138105
@ezyang
Copy link
Contributor

ezyang commented Oct 17, 2024

Are we going to get the non-context manager directly mutating version of the API?

@williamwen42
Copy link
Member Author

@ezyang it's already implemented in this PR, although I overlooked adding a test and including it as a usage example. I can add this in a followup.

yf225 added a commit that referenced this pull request Oct 17, 2024
… decide whether to fallback to eager"

Dynamo stance is recently added in #137504. When Dynamo stance is "force_eager" (user explicitly wants to fall back to eager), we would like Compiled Autograd to fall back to eager as well. This will allow the Traceable FSDP2 use case to work since "eager forward + compiled autograd backward" is not supported for Traceable FSDP2.

In general, if user wants to do "eager forward + compiled autograd backward", they should explicitly run the forward in eager instead of applying compile and then set stance to "force_eager".




cc XilunWu H-Huang awgu kwen2501 wanchaol fegin fduwjj wz337 wconstab d4l3k c-p-i-o voznesenskym penguinwu EikanWang jgong5 Guobing-Chen XiaobingSuper zhuhaozhe blzheng wenzhe-nrv jiayisunx chenyang78 kadeng chauhang amjames rec xmfan

[ghstack-poisoned]
yf225 added a commit that referenced this pull request Oct 17, 2024
…to fallback to eager"

Dynamo stance is recently added in #137504. When Dynamo stance is "force_eager" (user explicitly wants to fall back to eager), we would like Compiled Autograd to fall back to eager as well. This will allow the Traceable FSDP2 use case to work since "eager forward + compiled autograd backward" is not supported for Traceable FSDP2.

In general, if user wants to do "eager forward + compiled autograd backward", they should explicitly run the forward in eager instead of applying compile and then set stance to "force_eager".




cc XilunWu H-Huang awgu kwen2501 wanchaol fegin fduwjj wz337 wconstab d4l3k c-p-i-o voznesenskym penguinwu EikanWang jgong5 Guobing-Chen XiaobingSuper zhuhaozhe blzheng wenzhe-nrv jiayisunx chenyang78 kadeng chauhang amjames rec xmfan

[ghstack-poisoned]
@yf225
Copy link
Contributor

yf225 commented Oct 17, 2024

@williamwen42 also I've started using the direct-mutating API: https://github.com/pytorch/pytorch/pull/138113/files and it's awesome :)

yf225 added a commit that referenced this pull request Oct 17, 2024
… decide whether to fallback to eager"

Dynamo stance is recently added in #137504. When Dynamo stance is "force_eager" (user explicitly wants to fall back to eager), we would like Compiled Autograd to fall back to eager as well. This will allow the Traceable FSDP2 use case to work since "eager forward + compiled autograd backward" is not supported for Traceable FSDP2.

In general, if user wants to do "eager forward + compiled autograd backward", they should explicitly run the forward in eager instead of applying compile and then set stance to "force_eager".




cc XilunWu H-Huang awgu kwen2501 wanchaol fegin fduwjj wz337 wconstab d4l3k c-p-i-o voznesenskym penguinwu EikanWang jgong5 Guobing-Chen XiaobingSuper zhuhaozhe blzheng wenzhe-nrv jiayisunx chenyang78 kadeng chauhang amjames rec xmfan

[ghstack-poisoned]
yf225 added a commit that referenced this pull request Oct 17, 2024
…to fallback to eager"

Dynamo stance is recently added in #137504. When Dynamo stance is "force_eager" (user explicitly wants to fall back to eager), we would like Compiled Autograd to fall back to eager as well. This will allow the Traceable FSDP2 use case to work since "eager forward + compiled autograd backward" is not supported for Traceable FSDP2.

In general, if user wants to do "eager forward + compiled autograd backward", they should explicitly run the forward in eager instead of applying compile and then set stance to "force_eager".




cc XilunWu H-Huang awgu kwen2501 wanchaol fegin fduwjj wz337 wconstab d4l3k c-p-i-o voznesenskym penguinwu EikanWang jgong5 Guobing-Chen XiaobingSuper zhuhaozhe blzheng wenzhe-nrv jiayisunx chenyang78 kadeng chauhang amjames rec xmfan

[ghstack-poisoned]
yf225 added a commit that referenced this pull request Oct 17, 2024
… decide whether to fallback to eager"

Dynamo stance is recently added in #137504. When Dynamo stance is "force_eager" (user explicitly wants to fall back to eager), we would like Compiled Autograd to fall back to eager as well. This will allow the Traceable FSDP2 use case to work since "eager forward + compiled autograd backward" is not supported for Traceable FSDP2.

In general, if user wants to do "eager forward + compiled autograd backward", they should explicitly run the forward in eager instead of applying compile and then set stance to "force_eager".




cc XilunWu H-Huang awgu kwen2501 wanchaol fegin fduwjj wz337 wconstab d4l3k c-p-i-o voznesenskym penguinwu EikanWang jgong5 Guobing-Chen XiaobingSuper zhuhaozhe blzheng wenzhe-nrv jiayisunx chenyang78 kadeng chauhang amjames rec xmfan

[ghstack-poisoned]
yf225 added a commit that referenced this pull request Oct 17, 2024
…to fallback to eager"

Dynamo stance is recently added in #137504. When Dynamo stance is "force_eager" (user explicitly wants to fall back to eager), we would like Compiled Autograd to fall back to eager as well. This will allow the Traceable FSDP2 use case to work since "eager forward + compiled autograd backward" is not supported for Traceable FSDP2.

In general, if user wants to do "eager forward + compiled autograd backward", they should explicitly run the forward in eager instead of applying compile and then set stance to "force_eager".




cc XilunWu H-Huang awgu kwen2501 wanchaol fegin fduwjj wz337 wconstab d4l3k c-p-i-o voznesenskym penguinwu EikanWang jgong5 Guobing-Chen XiaobingSuper zhuhaozhe blzheng wenzhe-nrv jiayisunx chenyang78 kadeng chauhang amjames rec xmfan

[ghstack-poisoned]
yf225 added a commit that referenced this pull request Oct 17, 2024
… decide whether to fallback to eager"

Dynamo stance is recently added in #137504. When Dynamo stance is "force_eager" (user explicitly wants to fall back to eager), we would like Compiled Autograd to fall back to eager as well. This will allow the Traceable FSDP2 use case to work since "eager forward + compiled autograd backward" is not supported for Traceable FSDP2.

In general, if user wants to do "eager forward + compiled autograd backward", they should explicitly run the forward in eager instead of applying compile and then set stance to "force_eager".




cc XilunWu H-Huang awgu kwen2501 wanchaol fegin fduwjj wz337 wconstab d4l3k c-p-i-o voznesenskym penguinwu EikanWang jgong5 Guobing-Chen XiaobingSuper zhuhaozhe blzheng wenzhe-nrv jiayisunx chenyang78 kadeng chauhang amjames rec xmfan

[ghstack-poisoned]
yf225 added a commit that referenced this pull request Oct 17, 2024
…to fallback to eager"

Dynamo stance is recently added in #137504. When Dynamo stance is "force_eager" (user explicitly wants to fall back to eager), we would like Compiled Autograd to fall back to eager as well. This will allow the Traceable FSDP2 use case to work since "eager forward + compiled autograd backward" is not supported for Traceable FSDP2.

In general, if user wants to do "eager forward + compiled autograd backward", they should explicitly run the forward in eager instead of applying compile and then set stance to "force_eager".




cc XilunWu H-Huang awgu kwen2501 wanchaol fegin fduwjj wz337 wconstab d4l3k c-p-i-o voznesenskym penguinwu EikanWang jgong5 Guobing-Chen XiaobingSuper zhuhaozhe blzheng wenzhe-nrv jiayisunx chenyang78 kadeng chauhang amjames rec xmfan

[ghstack-poisoned]
pytorchmergebot pushed a commit that referenced this pull request Oct 18, 2024
… to eager (#138113)

Dynamo stance is recently added in #137504. When Dynamo stance is "force_eager" (user explicitly wants to fall back to eager), we would like Compiled Autograd to fall back to eager as well. This will allow the Traceable FSDP2 use case to work since "eager forward + compiled autograd backward" is not supported for Traceable FSDP2.

In general, if user wants to do "eager forward + compiled autograd backward", they should explicitly run the forward in eager instead of applying compile and then set stance to "force_eager".

Pull Request resolved: #138113
Approved by: https://github.com/xmfan
@github-actions github-actions bot deleted the gh/williamwen42/141/head branch November 17, 2024 02:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants