Include canon_backend in the compilation cache key#3400
Draft
PTNobel wants to merge 1 commit into
Draft
Conversation
Re-solving a Problem with a different canon_backend silently reused the previously compiled canonicalization: Cache.make_key only keyed on (solver, gp, ignore_dpp, use_quad_obj), so get_problem_data treated the second solve as a cache hit and never constructed a solving chain with the requested backend. Fix: add canon_backend to Cache.make_key and its single call site in get_problem_data. The value is keyed as passed (None for the default), so the common None -> None re-solve still hits the cache, while None and an explicit backend are kept distinct (None enables auto-COO selection for large DPP problems, so they are not equivalent). Audited the other arguments construct_solving_chain consumes: solver, gp, ignore_dpp, and solver_opts['use_quad_obj'] were already in the key; verbose only affects logging; remaining solver_opts are forwarded to the solver at solve time and do not change canonicalization. enforce_dpp only gates raising DPPError versus warning for non-DPP problems and never changes the compiled chain, so it is left out of the key. Tests: TestCanonBackendCacheKey in test_backend_selection.py asserts a backend switch re-canonicalizes (via the cached chain's ConeMatrixStuffing.canon_backend) and that same-backend and default re-solves still reuse the cached chain object. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
Benchmarks that have stayed the same: |
Collaborator
Author
|
|
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
1 participant
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.
Description
Re-solving a Problem with a different canon_backend silently reused the
previously compiled canonicalization: Cache.make_key only keyed on
(solver, gp, ignore_dpp, use_quad_obj), so get_problem_data treated the
second solve as a cache hit and never constructed a solving chain with
the requested backend.
Fix: add canon_backend to Cache.make_key and its single call site in
get_problem_data. The value is keyed as passed (None for the default),
so the common None -> None re-solve still hits the cache, while None and
an explicit backend are kept distinct (None enables auto-COO selection
for large DPP problems, so they are not equivalent).
Audited the other arguments construct_solving_chain consumes: solver,
gp, ignore_dpp, and solver_opts['use_quad_obj'] were already in the key;
verbose only affects logging; remaining solver_opts are forwarded to the
solver at solve time and do not change canonicalization. enforce_dpp
only gates raising DPPError versus warning for non-DPP problems and
never changes the compiled chain, so it is left out of the key.
Tests: TestCanonBackendCacheKey in test_backend_selection.py asserts a
backend switch re-canonicalizes (via the cached chain's
ConeMatrixStuffing.canon_backend) and that same-backend and default
re-solves still reuse the cached chain object.
Found by an automated bug-hunting audit of master; each finding was reproduced against an independent oracle before fixing.
Type of change
Contribution checklist