Faster evaluation - #79
Open
PBrdng wants to merge 4 commits into
Open
Conversation
Collaborator
Author
|
Note: I neither checked the new code nor the math behind it. This should be done before merging. |
Collaborator
Author
Since it's an internal function, I don't thinkw e want it to appear in the docs.
Collaborator
|
The math looks good to me! As before, we should expect the code to act incorrectly at singular psuedowitness set intersections, but this will not happen generically (i.e. see the #13). My own codex only found a few things, mostly related to parallelization:
|
Remove the `ntrackers` parameter and always create one tracker per Julia thread. Add `_snapshot_worker_fiber_stats` and `_merge_worker_fiber_stats!` to collect fiber-tracking counters from deep-copied monodromy workers and fold their deltas back into the original hypersurface after each solve. Add helper `_fiber_tracking_counters` and `_add_fiber_tracking_delta!` to `GradientCache`. Improve docstring on `fiber_tracking_stats` to document the aggregation behavior.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This PR was written by Codex.
This PR substantially accelerates repeated gradient and Hessian evaluations of routing functions associated with projected algebraic hypersurfaces.
The main improvements are:
Mathematical formulation
Let the square system defining a fiber point be
where$z=(s,u)$ , $p$ is the evaluation point, and $b$ is the slicing direction. Write
For each regular solution$z=z(p,b)$ , implicit differentiation gives
Thus, the forward sensitivities satisfy
The routing function depends on the first coordinate$s$ of every fiber solution.
Adjoint gradient evaluation
The previous implementation recovered derivatives of$s$ by solving the forward systems for every parameter direction. For the gradient, however, only the first component of each sensitivity vector is needed.
Let$e_1$ denote the first coordinate vector and introduce the adjoint variable $\lambda$ , defined by
For any parameter direction$q$ , we then have
In particular,
Therefore, the gradient contribution of one fiber point can be computed from the single transposed linear system
instead of solving one forward system for every component of$b$ . This reduces the number of linear right-hand sides required for a gradient evaluation from $k$ to $1$ .
Contracted Hessian evaluation
Differentiating the implicit system a second time gives
where
Here,$G_{zz}[z_{p_a},z_{b_b}]$ denotes the contraction of the second derivative of $G$ with the two first-order sensitivity vectors.
Consequently,
Only the first component of this vector enters the Hessian of the routing function. Using the same adjoint variable, we obtain
Hence, the required contribution is obtained directly as
The new implementation evaluates these scalar contractions directly. It no longer constructs the complete second-order sensitivity vectors$z_{p_ab_b}$ , nor does it solve $k^2$ additional linear systems for them.
The first-order sensitivities appearing in$R_{ab}$ are still computed together using the block linear system
After this solve, the Hessian entries are evaluated through the compiled contractions
Compiled derivative systems
The following symbolic expressions are now compiled once when the gradient cache is constructed:
This avoids repeatedly assembling large derivative tensors and contracting them in Julia during every routing-function evaluation.
The previous runtime representations of the full tensors$G_{zz}$ , $G_{zp}$ , $G_{zb}$ , and $G_{pb}$ , together with their temporary storage and tensor-unpacking logic, are no longer required.
Moving-fiber cache
Repeated evaluations during monodromy usually occur at nearby parameter values. The implementation now caches the most recently computed pseudo-witness fiber and transports it to the next parameter value instead of reconstructing every fiber from the original witness set.
Cache updates are transactional: a transported fiber replaces the cached fiber only after the tracking operation succeeds. If transport from the cached fiber fails, evaluation falls back to the original pseudo-witness construction.
The cache supports:
Taylor prediction
The first-order Taylor update for
RoutingGradientnow usesThis provides monodromy tracking with a meaningful local prediction for the routing gradient instead of reusing a zeroth-order approximation.
Parallel path tracking
Pseudo-witness transport now uses the available Julia threads. Mutable tracking state is copied for each tracker so that concurrently tracked paths do not share unsafe state.
Correctness
The optimized evaluator was checked against the known symbolic discriminant of the cubic test problem,
The pseudo-witness-set gradient and Hessian agree with the symbolic gradient and Hessian at multiple real and complex evaluation points.
The observed errors were below:
Performance
The benchmarks exclude object construction and report the median of five runs.
Avoidance example
This example has$k=4$ , degree $4$ , and uses 300 evaluations.
mainThe corresponding per-evaluation times are:
main3-RPR example
This example has$k=3$ , degree $12$ , and uses 100 evaluations.
mainThe corresponding per-evaluation times are:
mainThese measurements cover the repeated evaluator workload used by monodromy, rather than a complete end-to-end monodromy run.
Setup-time tradeoff
Compiling the additional adjoint and contracted derivative systems slightly increases
GradientCacheconstruction time:mainThe complete pseudo-witness-set setup for these examples takes approximately 30 seconds. The additional compilation cost is therefore below$1%$ of the total setup time.
The extra setup cost is recovered after approximately:
This tradeoff is negligible for monodromy computations, where the evaluator is called many times.