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

Caching computations in forward mode #192

Open
sethaxen opened this issue May 17, 2020 · 2 comments
Open

Caching computations in forward mode #192

sethaxen opened this issue May 17, 2020 · 2 comments
Labels
design Requires some design before changes are made performance Related to improving computational performance

Comments

@sethaxen
Copy link
Member

Suppose we have a function f: ℝᵐ → ℝⁿ that for some reason we want to differentiate in forward mode, which will require calling all frules m times. This seems wasteful, as the pushforwards often depend on intermediates of the primal function that don't change. In the current implementation of frules, where the output of the pushforward is computed at the same time as the output of the primal, these intermediates would need to be recomputed m times. An example is symmetric eigendecomposition, where the eigendecomposition really only needs to be computed once but will instead be computed m times.

I'm sure there are good reasons for implementing this way. One I can think of is that it's easier to support mutating rules. Are there others?

@willtebbutt
Copy link
Member

The reason for computing the primal and tangent together is for things like e.g. the frule for an ODE solver. In this case, you really don't want to spit out a closure from the frule because it would involve caching all of the intermediate state from the solve.

In terms of evaluation at multiple tangents, the plan is to enable pushing entire bases through at the same time.

@nickrobinson251 nickrobinson251 added the performance Related to improving computational performance label May 17, 2020
@oxinabox
Copy link
Member

To be clear we actually do support the core of JuliaDiff/ChainRulesCore.jl#92 already.
ForwardDiff2 even makes use of it.
Every frule that we have supports it.

I think the real question of JuliaDiff/ChainRulesCore.jl#92
is "Are there other frules that we have not written because we need to support it better some how"

@nickrobinson251 nickrobinson251 added the design Requires some design before changes are made label Aug 4, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
design Requires some design before changes are made performance Related to improving computational performance
Projects
None yet
Development

No branches or pull requests

4 participants