We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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
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:
broadcast_forward
.f
Broadcasted
Base.issingletontype
.args
Real
AbstractArray{<:Real}
Type
Symbol
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?
The text was updated successfully, but these errors were encountered:
Yes, I think this would be a good approach. I also would like to fill out more explicit gradients for broadcasting.
Sorry, something went wrong.
Does #1001 address this?
Successfully merging a pull request may close this issue.
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:.f
) wrapped in allBroadcasted
s are singleton (Base.issingletontype
) and.args
) wrapped in allBroadcasted
s areReal
,AbstractArray{<:Real}
, or non-differentiable (e.g.,Type
,Symbol
andVal
).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?
The text was updated successfully, but these errors were encountered: