[Ipopt] IPOPT performance (and impact of BLAS library)

[Jon Herman]

Hello,

I am working on implementing IPOPT in a piece of software that has a 
need for very good performance. Unfortunately, it seems that right now 
my total run-time is about 80% in IPOPT (that number excludes the 
function evaluations, as well as any time setting up the problem, etc.). 
For me to put IPOPT to good use, I'm hoping to make it run more 
efficiently, and even out the workload between IPOPT and the function 
evaluations, preferably shifting the work to the function evaluations as 
much as possible.

Originally, I was using the BLAS/LAPACK that can be installed with 
IPOPT. In an attempt to improve performance, I switched to OpenBLAS. To 
my confusion, performance did not change at all. This is leading me to 
believe that something other than the BLAS library is dominating the 
cost. (I am certain I properly removed the old libraries when switching 
BLAS implementation) I'm not sure how to effectively narrow down where 
IPOPT is spending most of it's time, and how to subsequently improve 
that performance.

I've made sure to try the ma27, ma57, ma77, ma86, ma97, and mumps 
solvers. Performance varies among them, but 80% of the time spent in 
IPOPT is the best result I achieve (which is typically with ma27 or 
ma57, the other solvers are closer to 90%). I've also made sure to try 
problems as small as 500 variables and 400 constraints, to as large as 
110 000 variables and 80 000 constraints (and many points in between 
those extremes). Performance is very consistent across that range (for a 
given solver), again regardless of the BLAS library being used. I've 
been doing this using the quasi-Newton approximation for the Hessian, 
which I was hoping to get away with, but I suppose this may put a lot of 
work into IPOPT's side of the court. I'll also mention that I'm calling 
IPOPT through the PyIPOPT module (though I'm expecting this to create 
only a small, fixed overhead).

If you have any thoughts on why IPOPT might be hogging such a large 
fraction of my total run-time, and/or how I could improve this (or 
determining if this might be entirely unavoidable), I would greatly 
appreciate it! (and of course I'd be happy to provide additional 
information if that would be useful)

Best regards,

Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/ipopt/attachments/20140908/1e400776/attachment.html>