performance hints

[mlubin]

@joaquimg proposed a performance hint to tell the MOI wrapper to load the problem into the solver. I expect that we may decide that we want other performance hints as we start implementing things, so opening this for general discussion.

[joaquimg]

I posted this comment in jump-dev/CPLEX.jl#139

For Xpress there is a 10x speed and memory difference between adding variables 1 by 1 and adding them in a batch.
https://gist.github.com/joaquimg/5dbaf83e7555b94d79f4d01f8ed53119

[mlubin]

I expect we'll have to put a bit of work into efficiently moving the data from the JuMP Instance to the SolverInstance, but we can already create all of the variables at once with the current interface. Adding constraints one-by-one is potentially more of a performance issue.

[joaquimg]

Very similar result for constraints:
https://gist.github.com/joaquimg/68c67de76eea7adea0b9ab880c667dfc

[joaquimg]

What are you planning to do with instance?

Send everything to the solver as a VectorAffineFuntion in Nonpositives/Zeros?

Otherwise, I can only see the solver having to figure out when to add everything, and then load is very important. Moreover, load and SolverInstance become a bit complex, since they will have to do some bookkeeping.

Any ideas?

[mlubin]

Send everything to the solver as a VectorAffineFuntion in Nonpositives/Zeros?

No, we'll be providing the same constraints to the solver as the user provided to us.

We can try:

addconstraints!(::SolverInstance,::Vector{F},::Vector{S})

The solver can build a sparse matrix based on this and give all the constraints to the solver at once. We'd normally have to call this function three times, once for each of LessThan, GreaterThan, and EqualTo. That's better than 100,000 times for a problem with 100,000 constraints.

[joaquimg]

3 (actually once per Set + Function combination) times should be fine.
I like this proposal.

[mlubin]

This can also be used to pass in all bounds, integrality constraints, etc.

[joaquimg]

yep!

[mlubin]

Actually can we just overload the broadcast syntax to intercept addconstraint!.(...)?

[mlubin]

No, not really (JuliaLang/julia#22053 (comment)):

Overriding broadcast for particular functions should ordinarily not be done, and at most should be done as an optimization only. Because of fusion, it will never be possible to guarantee that broadcast(::typeof(f), ...) is called for a particular f.

Seems a bit flimsy.

[IssamT]

similarly to addconstraints!, deleteconstraints! would be useful too

[mlubin]

It's just called delete!. No objection to defining a method for deleting a vector of references.

[odow]

Closing because we don't seem to have needed this or made progress. We have all the plural methods, it's just up to JuMP to plumb them through.