Problem with JuMP + Gurobi.jl

Specific Domains Optimization (Mathematical)
,
1

Hello,

In continuation of the thread : Poor time performance in modifying parameters of JuMP models when using Gurobi - #10 by odow

Here is a code that show the behavior (it emulates the behavior of a column generation algorithm).

module pbgrb

using JuMP
using Gurobi
using HiGHS

function sc_gurobi(nbconstraint::Int, nbcolums::Int, nbiter::Int)
    m = Model(Gurobi.Optimizer)
    set_silent(m)
    set_attribute(m, "Threads", 1)

    @objective(m, Min, 0)

    @constraint(m, constr[i=1:nbconstraint], 0 == 1)

    x = Vector{VariableRef}()

    for k in 1:nbiter
        optimize!(m)

        for i in 1:nbcolums
            push!(x, @variable(m, lower_bound=0, upper_bound=1))

            set_objective_coefficient(m, x[end], 1)

            for i in 1:nbconstraint
                set_normalized_coefficient(constr[i], x[end], 1)
            end
        end
    end
end

function sc_highs(nbconstraint::Int, nbcolums::Int, nbiter::Int)
    m = Model(HiGHS.Optimizer)
    set_silent(m)

    @objective(m, Min, 0)

    @constraint(m, constr[i=1:nbconstraint], 0 == 1)

    x = Vector{VariableRef}()

    for k in 1:nbiter
        optimize!(m)

        for i in 1:nbcolums
            push!(x, @variable(m, lower_bound = 0, upper_bound = 1))

            set_objective_coefficient(m, x[end], 1)

            for i in 1:nbconstraint
                set_normalized_coefficient(constr[i], x[end], 1)
            end
        end
    end
end

function main()
    start = time()
    sc_gurobi(100, 100, 20)
    println("Time Gurobi: ", time() - start)

    start = time()
    sc_highs(100, 100, 20)
    println("Time HiGHS: ", time() - start)
end

end # module pbgrb

On my computer, I obtain output such as

Time Gurobi: 11.41237497329712
Time HiGHS: 0.17132186889648438

I am using a macbook with M1 pro processor under macos 14.3.1, julia 1.10.1, JuMP 1.20.0, Gurobi.jl 1.2.1, HiGHS 1.9.0, Gurobi 11.0.1.

I am under the impression that I do follow the rules regarding the lazy update.

Thank you in advance,

Best regards,

Nicolas.

2

Hi @njozefow! Thanks for the code.
I can reproduce this. I will look into this as part of Gurobi.jl#516

1 Like
3

As a comment: is this a bottleneck in a real model? In what algorithm would you add many dense columns at each iteration?

4

Hello,

It happens to me in a column generation algorithm for a vehicle routing problem where the matrix is sparse. Still, there is an impact on the computational times. In my VRP application for medium size instances, using gurobi is 2-3 times slower than using HiGHS.

The example I provided is like that to increase the impact and because it was easier to implement.

Best regards,

5

So @torressa, the problematic method is:

It ends with _require_update(model) and calls _update_if_necessary(model) at the start, so we’re updating after every coefficient change.

1 Like
6

Indeed! I think we can bundle it in with the refactor PR Gurobi.jl#552 as there were other places were an update was not needed (this is probably the largest performance bottleneck though).

7

This should be fixed now with the new Gurobi.jl release: v1.2.3.

I am getting:

Time Gurobi: 0.29712510108947754
Time HiGHS: 0.27363109588623047
2 Likes
8

Hello

I also tested on my side and it works.

Thank you for the correction and all the work on the package.

Best regards,

N.

2 Likes