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

[Greg Horn]

My usual answer to increasing efficiency is using HSL (ma86/ma97) with
metis ordering and openmp. How expensive are your function evaluations?
What is your normal time per iteration, and how many iterations does it
take to solve? What sort of problem are you solving?

On Mon, Sep 8, 2014 at 10:53 PM, Jon Herman <jon.herman at colorado.edu> wrote:

>  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
>
> _______________________________________________
> Ipopt mailing list
> Ipopt at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/ipopt
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/ipopt/attachments/20140908/6821d45e/attachment.html>