Efficiency of MiniZinc + OR-tools compared to OR-tools alone #4374
-
I'd be interested to use MiniZinc for its in-browser experience & its support of many solvers, but at the same time I find OR-tools really efficient and I'd like to be sure that by choosing to use MiniZinc with OR-tools as a backend, I lose nothing compared to using OR-tools directly. So here are my questions: how efficient is the MiniZinc -> OR-tools translation? Do I have any benefit from coding things directly in OR-tools? If yes, can I, somehow, provide alternative instructions in MiniZinc, like one specialized for OR-tools and one for any generic backend? Is there a list of constraints that are known to be more efficient with or-tools directly compared to minizinc's translation? To give a more precise example, OR-tools has many functions like "NoOverlap2D", "circuits", "AddReservoirConstraint"… but is there always an equivalent MiniZinc constraint, and will it be compiled correctly to OR-tools? For instance, for NoOverlap2D, it seems like I want to use diffn, so if I use diffn, will OR-tools use the optimized NoOverlap2D code under the hood, or will it start from a more low-level set of instructions that it might have a harder time to optimize? Also, in the MiniZinc challenge, are OR-tools's performance obtained via a code written in MiniZinc, or directly via a code optimized for OR-tools? NB: Cross-posted in SO: https://stackoverflow.com/questions/78990695/efficiency-of-minizinc-or-tools-compared-to-or-tools-alone |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
answered in S.O. |
Beta Was this translation helpful? Give feedback.
answered in S.O.