Extensive improvement over native optimization & exposed strategy controls

[pavelmk]

Hi there! [Meta-note: this is human-written, and everything below the dotted line is AI-written.] My name is Pavel, and I've used Gecode extensively in my consulting work (abseil.ai) in operations scheduling across robotics and factories. I work for an AI lab now and had about $400 of GPT6 credits for personal use, so I was curious with all the recent advancements in frontier math how well the AI (specifically Codex with /goal mode) could optimize Gecode performance, and ran it overnight on that use case. It was quite successful! Here are the results (a combination of several strategic and algorithmic improvements):

Best of auto/configured, selected separately for size and speed:

Problem	Confirmed size: before → after	Size increase	Speedup at original maximum
Knapsack	33 → 2,304	69.82×	36,613×
Assignment	17 → 64	3.76×	165×
Facility location	8 → 54	6.75×	244×
Bin packing	17 → 47	2.76×	1,808×
Production planning	11 → 28	2.55×	114×
Routing	21 → 21	1×	0.994×
Weighted queens	23 → 23	1×	1.001×

(here's the HTML version: https://pavelmk.github.io/gecode-optimization-benchmarks/ , and here is the benchmark suite: https://github.com/pavelmk/gecode-optimization-benchmarks/ )

Because of the substantial performance improvements, I wanted to make this available to the community, however I'm also aware that this is an enormous change to drop into an open-source project, and candidly I've overwhelmingly trusted GPT6 to perform code review, though I was sure to include here an extensive test suite. I'm confident in its correctness, but not that it successfully followed all stylistic cues and project philosophy.

Aesthetically, I think there are substantial questions arising now regarding the meaning and value of AI-vs-human-written code, the erosion of codebase understanding (e.g. https://www.seangoedecke.com/in-defense-of-not-understanding-your-codebase/), purpose of code as a pedagogical tool vs. a performance-maximizing project, etc. So, I will welcome guidance from this maintainer community whether any of these changes warrant incorporation, or what that interaction should look lie with this project.

If you'd like to incorporate this in a modified form, I'm happy to take any feedback which I will forward to my agent :). And thank you for all of your work over the years!

Best,
Pavel

(PS, I published a corresponding MiniZinc IDE revision with the configuration options built-in: https://github.com/pavelmk/MiniZincIDE )

---

[Machine-written below this point]

Add optional optimization APIs and adaptive native solving

Introduce Gecode::Optimize with explicit result guarantees, reusable optimization workflows and automatic selection of native algorithms.

• Optimization APIs: owning sparse models, C/Python bindings, starts and LP/MPS exchange. HiGHS supplies LP/MILP and bounded continuous weighted-square QP, with persistent sessions, ordered objectives, scenarios, repair and solution pools.
• Exact preprocessing: integer presolve/postsolve, independent-component solving and identical-column symmetry, with original-coordinate witness reconstruction.
• Knapsack acceleration: exact dynamic programming using rolling value rows and packed traceback, with resource caps and native-search fallback.
• Stronger search: checked LP deductions, verified cover cuts, DFS/best-bound frontiers, reliability branching and bounded binary Hamming neighborhoods.
• Adaptive execution: structural strategy selection without problem-family labels; optional sequential racing retains valid incumbents and bounds within shared time, node and cancellation budgets.
• MiniZinc integration: 21 native driver controls for strategies, algorithms, budgets and diagnostics. Objective reconstruction allows eligible flattened knapsacks to reach the DP path.

Racing may increase CPU work or solve time through exploration and restarting, but can identify a substantially better strategy for the remaining solve.

Performance measured on seeded instances with one thread and a ten-second solve budget against the project’s pre-algorithm runtime. Sizes are confirmed sampled results. Speedups use recorded median solve time, excluding startup; most improved timings have only one run per instance. These are observed combined-policy ratios, not guaranteed speedups or isolated evidence for racing.

[CervEdin]

This is not my project but

+45,226 -1,140
Lines changed: 45226 additions & 1140 deletions

in one giant commit...

idk. If I was the maintainer I would flat out reject this on the basis that it's not possible to review it

[zayenz]

Hi @pavelmk Thanks for the interest in improving Gecode, but as you probably suspect this is not really a size of PR that we can review, and also there are several things that are unlikely that we would want in Gecode proper (hybridization in partiuclar feels like it should probably live in another project).

We are currently working on several interesting future directions that include portfolio solving, and I will ask my agents to refer to this branch and see if anything interesting can be applied. If so, we will credit you there.