Very different execution times localy vs online

[Marc Roig Vilamala]

Hello,

I was trying to execute the attached code. 

Initially, I developed it through the online platform (https://play.minizinc.dev/). There, the optimal solution is found quickly, taking around half a second. This is using the Gecode 6.3.0 solver.

However, when I try to run it locally, even after several minutes, I am not getting a solution. Locally, I am running it on an Ubuntu 22.04.5 machine. I have installed version 2.9.4 of Minizinc using:

snap install minizinc --classic

To run the solver, I am using the following command:

minizinc --solver gecode new_film_scheduling.mzn

I have also tested a more trivial version of the problem by reducing the number of actors, and that does give me a solution almost instantly, both online and locally.

Am I doing something wrong? Is there any reason why the online version is so much faster than locally?

Thank you!

[Mikael Zayenz Lagerkvist]

Hi,

I'm not sure about why it differs on the playground and locally, but
it seems like the problem has quite some variability in solving time,
which is not unreasonable for combinatorial problems.

With that said, using or-tools with 10 threads and free search your
model solved in about 100 ms in multiple runs when I tried it locally.

Cheers,
Mikael

> --
> 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 visit https://groups.google.com/d/msgid/minizinc/f46a09f6-a676-494a-a394-3631b016421fn%40googlegroups.com.



--
Mikael Zayenz Lagerkvist

[Laurent Perron]

Indeed. The model is trivial for local search

Starting search at 0.01s with 16 workers.
11 full problem subsolvers: [core, default_lp, lb_tree_search, max_lp_sym, no_lp, objective_lb_search, probing, pseudo_costs, quick_restart, quick_restart_no_lp, reduced_costs]
5 first solution subsolvers: [fj(2), fs_random, fs_random_no_lp, fs_random_quick_restart_no_lp]
11 interleaved subsolvers: [feasibility_pump, graph_arc_lns, graph_cst_lns, graph_dec_lns, graph_var_lns, lb_relax_lns, ls, ls_lin, rins/rens, rnd_cst_lns, rnd_var_lns]
3 helper subsolvers: [neighborhood_helper, synchronization_agent, update_gap_integral]

#1       0.02s best:14    next:[11,13]    fj_restart(batch:1 lin{mvs:81 evals:240} #w_updates:35 #perturb:0)
#2       0.02s best:13    next:[11,12]    ls_restart_decay(batch:1 lin{mvs:76 evals:515} #w_updates:34 #perturb:0)
#3       0.02s best:11    next:[]         ls_lin_restart_perturb(batch:1 lin{mvs:67 evals:258} #w_updates:42 #perturb:0)

Laurent Perron | Operations Research | lpe...@google.com | (33) 1 42 68 53 00

To view this discussion visit https://groups.google.com/d/msgid/minizinc/CAPKxCj6_gAskMSNOJcMvjXTkHPHizXqhR0UYv1sVuWmuPxZoeg%40mail.gmail.com.

[Marc Roig Vilamala]

Thank you both, it seems like the command line was defaulting to a single thread. When increasing the number of threads to 10 it also solves very quickly locally.