Ask Your Question

How do I set solver_parameter to make Gurobi use more than one processor?

asked 2017-05-29 06:29:29 -0500

Sébastien gravatar image

As suggested previously by Nathann Cohen, the method solver_parameter allows to do such a thing

sage: p = MixedIntegerLinearProgram(solver = "Gurobi")
sage: p.solver_parameter?

In the documentation that appears, it says:

Gurobi’s parameters should all be available through this method. Their list is available on Gurobi’s website

but this link is broken and leads us to instead. How do I set solver_parameter to make Gurobi use more than one processor?

edit retag flag offensive close merge delete

1 answer

Sort by » oldest newest most voted

answered 2017-06-06 13:45:40 -0500

mforets gravatar image

updated 2017-06-07 01:59:41 -0500

The list of available parameters for Gurobi 7.0 is available in this link. (true that Sage help should better point to the general doc, because the previous link changes among versions..)

The parameter that you are interested in seems to be Threads, which controls the number of threads to apply to parallel algorithms. Apparently Gurobi already uses, by default, all available ones (see in the Threads description, or here). In any case, there are also other parameters to control parallelism.

So for example we can do:

sage: p = MixedIntegerLinearProgram(solver="Gurobi")
sage: p.solver_parameter("Threads")     # query the actual value
sage: p.solver_parameter("Threads", 4)    # set a new value
sage: p.solver_parameter("Threads")    # query the new value

In Sage, the allowed solver parameters for the Gurobi backend are listed in the dictionary parameters_type in gurobi_backend.pyx. Be careful because since keywords may be added or removed from version to version of Gurobi, the dictionary is not necessarily up-to-date and may brake, but as Nathan explains in that file, it is a matter of changing the source code and recompiling sage! (make start)

edit flag offensive delete link more


It does not seem to work, the command p.solve() below uses only one thread:

sage: p
Mixed Integer Program  ( maximization, 180000 variables, 178940 constraints )
sage: p.get_backend()
<type 'sage.numerical.backends.gurobi_backend.GurobiBackend'>
sage: p.solver_parameter('Threads',8)
sage: %time p.solve()
CPU times: user 12.6 s, sys: 0 ns, total: 12.6 s
Wall time: 12.6 s

But, I just realized that the bottleneck of my problem is the creation of the object p because calling add_constraint hundreds of thousands of times takes much more time (some minutes) than the one call to p.solve() (some seconds).

Sébastien gravatar imageSébastien ( 2017-06-13 04:39:01 -0500 )edit

how do you know that the program is using only one thread? is it because the time doesn't change if you change the Thread parameter?

mforets gravatar imagemforets ( 2017-06-13 06:49:17 -0500 )edit

for the second issue, this experiment seems to indicate that it's more efficient to push constraints "directly in the backend" :

sage: p = MixedIntegerLinearProgram(solver='Gurobi')
sage: x = p.new_variable()
sage: timeit('p.add_constraint(x[0] + 0.2*x[1] <= 4)')
625 loops, best of 3: 53.1 µs per loop

sage: p = MixedIntegerLinearProgram(solver='Gurobi')
sage: pb = p.get_backend()
sage: pb.add_variables(2)
sage: timeit("pb.add_linear_constraint(zip(range(2), [1.0, 0.2]), None, 4.0)")
625 loops, best of 3: 21.1 µs per loop
mforets gravatar imagemforets ( 2017-06-13 08:52:24 -0500 )edit

I conclude Gurobi is not using all processors and using only one thread by looking at htop during the execution. Coin backend uses all processors (by looking at htop), but it is also much slower and just can't solve the above problem. In the end, I am quite impressed by what Gurobi can do with only one processor but I am still wondering if it can do even better:)

Sébastien gravatar imageSébastien ( 2017-06-13 15:48:21 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2017-05-29 06:29:29 -0500

Seen: 69 times

Last updated: Jun 07