Help on speed optimization

[Zhang David]

Hi guys,

I’m trying to speed up mosek for some performance critical optimization process. Right now, I’m using mosek fusion Python API.

I wonder what speed gains I may get if I switch to:

1. Python optimizer API

2. C optimizer API

Just some rough ballpark idea would be helpful for me to evaluate if the gains is worth the time effort. 

My problem size is ~1600.

Really appreciate! 

[Michal Adamaszek]

Almost impossible to answer in such generality.

First you can write the same model in Fusion in much more or much less efficient ways.

Second, whether it is worthwhile depends on what time it takes to model the problem compared to solving it. 

Fusion has to do some processing, so there is real work it performs. The passage from Python Optimizer API to C Optimizer API is much thinner, this layer just passes data backend forth.

Whichever one you use the time to set up the problem should be a small fraction of the time it takes to solve it. If that is not the case then something is out of proportion.

Michal

[Zhang David]

Hi Michal,

Thank you for the quick response! 

To provide more details, the problem setup is very close to this portfolio optimization w/ impact example here: https://docs.mosek.com/10.0/pythonfusion/case-studies-portfolio.html#market-impact-costs

Problem size is 1500 ids. 

It sounds to me that there *might* be meaningful speed gains from Python Fusion API to Python Optimizer API, but likely not much from Python Optimizer API to C Optimizer API. Is that roughly a correct take ? 

If we assume the optimization w/ impact is the exact problem, dim = 1500, what do you say the rough speed diff btw Python Fusion API and Python Optimizer API ? 

Appreciate the help! 

--
You received this message because you are subscribed to the Google Groups "mosek" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mosek+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mosek/a4bf2402-7514-431a-b48c-cd3415ea3802n%40googlegroups.com.

[Erling D. Andersen]

Unfortunately,  the 1500 does not provide much info.

I think your take is wrong since good Fusion code is not much slower than Optimizer API code. 

I would not expect a significant speedup unless you are doing something weird with Fusion.

[Michal Adamaszek]

For one of those standard models much of the work is probably spent before Fusion ie. in some numpy computations and preparing data. That you will also have to do for the Optimizer API model. The Fusion model itself is not very complex and most critical work (like mul(G,x)) is already very optimized internally. So the speedup by rewriting this in the Optimizer API should not be very significant.

Michal

[Zhang David]

Thank you Erling for the clarification ! 

Can we define what "good Fusion code" is? Something very similar to the examples (i.e. no redundant constraints / avoid numerical issues etc.) ?

To view this discussion on the web visit https://groups.google.com/d/msgid/mosek/04b43251-f49c-4063-b852-80ae03089342n%40googlegroups.com.

[Zhang David]

Thank you Michael - this is very helpful ! Really appreciate it ! 

To view this discussion on the web visit https://groups.google.com/d/msgid/mosek/d54ca783-213c-4ac5-b286-70ab9f275a1en%40googlegroups.com.

[Michal Adamaszek]

"no redundant constraints / avoid numerical issues etc.", good scaling -- this applies to any formulation of an optimization problem, whether Fusion API or otherwise.

I guess good Fusion code means reasonably well vectorized in a way that makes it compact and readable. Hopefully as in our examples. 

(For instance one could imagine a Fusion model where every scalar variable is declared as a separate variable object and then they are painfully stacked together for each operation etc. That would be against the spirit and also very inefficient).

Michal

[Zhang David]

Perfect! Thank you again for the clear explanation! 

To view this discussion on the web visit https://groups.google.com/d/msgid/mosek/a866235e-a2ca-4758-a283-04de888c7699n%40googlegroups.com.