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

Use forward-mode in broadcasting? #336

Closed
tkf opened this issue Sep 23, 2019 · 2 comments · May be fixed by #338
Closed

Use forward-mode in broadcasting? #336

tkf opened this issue Sep 23, 2019 · 2 comments · May be fixed by #338

Comments

@tkf
Copy link
Contributor

tkf commented Sep 23, 2019

It seems that the overhead of the way broadcastings are handled currently is quite large:

Would it make sense to use the ForwardDiff-based solution (broadcast_forward) provided that it can be handled by ForwardDiff? That is to say:

  • The function (.f) wrapped in all Broadcasteds are singleton (Base.issingletontype) and
  • All arguments (.args) wrapped in all Broadcasteds are Real, AbstractArray{<:Real}, or non-differentiable (e.g., Type, Symbol and Val).

Note that, with ForwardDiff-based approach, we can fuse all broadcastings and also call style-specific materialization method.

Is this a reasonable approach? Or would the performance improvements be implemented soon?

@MikeInnes
Copy link
Member

Yes, I think this would be a good approach. I also would like to fill out more explicit gradients for broadcasting.

@cossio
Copy link
Contributor

cossio commented Oct 1, 2021

Does #1001 address this?

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 a pull request may close this issue.

4 participants