MiniZinc in practice

[Ties Westendorp]

I've toyed around for a bit with MiniZinc and I must say I quite like the abstraction layer that it provides between a model and a specific solver. What I like a bit less is the time it takes to compile an instance before it is solved. I've only done limited testing, but the compilation time seemed to take a significant fraction of the total execution time. Nonetheless, the provided abstraction seems like a big enough benefit to potentially run MiniZinc as a micro-service in production.

My questions are:

- Does anyone have any experience with this?

- Is this at all advisable? (It seems like MiniZinc was not necessarily built for this purpose, but more so to compare different solvers.)

- Any tips on how to speed up compilation?

Thanks in advance for your reply. :)

[Evert van Dijken]

Which version do you use? Mac, Windows or Linux. And different levels of optimization? I have a very moderate PC and compilation takes only a few seconds. And it is the problem and your skills to model it which determine how fast the problem is eventually solved. The right solver helps and solving a smaller version of  the problem first to see how MiniZinc performs helps too. And the Linux version is the fastest. Any you can not complain when e.g. compilation takes 2 seconds  and solving 1 second.

Evert van Dijken

Op wo 9 mrt. 2022 01:23 schreef Ties Westendorp <tieswes...@gmail.com>:

--
You received this message because you are subscribed to the Google Groups "MiniZinc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to minizinc+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/minizinc/36123c64-a690-43fa-af77-3c8baa4154f7n%40googlegroups.com.

[Ties Westendorp]

Linux, using the Yuck local search solver. The problem I'm trying to solve is a scheduling problem with some very "non-local" constraints relating to collective agreements and legislature. Considering only a moderately sized instance, I need about 30 seconds to get a meaningful result at all. Granted, I haven't applied things like hot starting, but I do have some very good symmetry breaking constraints. For our application, thinking in terms of seconds/half minutes is already stretching what is going to be 'sellable', and so shaving off a few seconds is going to be worthwhile. My general question is a bit broader than that, though: is it at all advisable to run MiniZinc as a microservice? Does anyone have any experience with that?

[Ties Westendorp]

MiniZinc to FlatZinc converter, version 2.5.5, build 273041792

 Yuck 20210501 (yuck, cbls, int, set, restart)

[Max Ostrowski]

Just adding my two cents, coming from a slightly different but similar area.
Constraint- (and other) solvers are usually build with solving exponentially hard problems in mind. This means that they are optimized to solve problems "fast" that are otherwise not solvable in days using traditional algorithms.
Applying these techniques in microservices is quite a stretch, as usually some preprocessing is needed in these solvers to prepare the problem to be solvable in minutes and not days. Solving NP problems in a fraction of a second usually only works for easy problems that could also be solved with traditional algorithms.
Again, this is just my personal experience in the field and your mileage may vary. Good luck for your endeavor.
Max

Am 15.03.22 um 13:27 schrieb Ties Westendorp:

To view this discussion on the web visit https://groups.google.com/d/msgid/minizinc/e106fd2a-af80-409e-9f52-0ecd2b1144a2n%40googlegroups.com.

[Michael Marte]

Hi Ties,

this is Michael, the author of Yuck.

The MiniZinc to FlatZinc compiler is quite fast. Yuck's FlatZinc compiler is quite fast, too, so I guess that most time
is spent for solving the problem.

To find out what happens and how long the steps take, you can run minizinc with the -v option.

To speed up the search, you could try the -p option to run several solvers in parallel.

Performance of local-search solvers suffers from symmetry-breaking and other redundant constraints, so it's a good idea
to remove or mark them, see
https://www.minizinc.org/doc-2.5.5/en/lib-stdlib.html?highlight=symmetry_breaking_constraint#special-constraints.

Yuck does not yet support warm starts. I have some ideas how to implement it but I am lacking test data. If you could
provide some test data (that could be published as part of the test suite), that would be great.

If you need nore Yuck specific help and don't want to discuss the details of your problem in the public, you can
contact me via yuck-...@freenet.de.

Hope this helps,
Michael

[Ties Westendorp]

@Max, I largely agree. I think you're skipping over one of the added benefits of MiniZinc (and the reason for me considering using this methodology): abstraction. Being able to abstract out the solver makes modelling in MiniZinc quite attractive, but I guess I'm interested in how practical this assumption really is. Essentially, since the performance in practice is actually very dependent of the specific choice of solver, is MiniZinc really just for comparing solvers? I.e., once you know which solver you're going to use, would you still use MiniZinc at all or would you just integrate that solver more directly into your flow?

@Michael, thanks for your reply and advice. I'll take a look at some metrics and compare it with parallelized solving when I get the time. I was actually curious on how symmetry-breaking would interplay with local-search, I should have seen "not well" coming as reply.. I don't really have good test data to share right now sadly, only some randomly generated data. Warm starting would be a great feature to have; besides being able to speed up the search, I think the fact that the given warm start serves as a performance bound really adds to the practical applicability of the optimization method. "It can only get better" is a great guarantee to have.