From: Marc Baaden <baaden@smplinux.de>
To: help-gsl@gnu.org
Cc: gsl-discuss@sources.redhat.com
Subject: [Help-gsl] questions about gsl_multimin_f*_minimizers (efficiency, drawbacks)
Date: Sun, 09 Nov 2003 17:51:00 -0000 [thread overview]
Message-ID: <200311081040.LAA15830@apex.ibpc.fr> (raw)
Hi,
I have some questions wrt the efficiency of the routines in gsl_multimin.
I have replaced a routine in an existing Fortran code (originally using
a Quasi-Newton minimizer (Harwell VA13A)) by a call to the gsl_multimin
routines, with the choice of either conjugate_pr, conjugate_fr,
steepest_descent, vector_bfgs or nm_simplex.
The original Harwell VA13A algorithm should be quite similar to vector_bfgs.
So I was rather surprised that there is quite a noticeable "performance"
difference, the Harwell code being roughly a factor of 1.5-2 faster.
(NB: I should say here, that I use the minimizer in an interactive procedure,
where you can follow the actual minimization on the screen. So I am not
giving quantitative timings but qualitative observations).
There is no big difference with the other fdf minimizers. NM_simplex is not
adapted for the problem.
I can see different reasons for this "slow" performance, and wonder whether
there is a workaround or trick to apply or some minimizer parameters to tweak.
- In the Harwell code, one can give a step size for each of the variables
to be minimized, whereas there is an overall step size in GSL.
That might make a difference eg for bfgs. Can that be implemented ?
Anybody got experience with this ?
- Concerning the function that I minimize, it is very difficult / inefficient
to separate function evaluation and derivative calculation. So at every call
to f, df or fdf both are evaluated. The function evaluation (which is
necessary for the
gradient calculation) is the bottleneck of the program (gprof: 80 % !!).
So if the number of times this routine is called could be minimized, then
this would probably give a significant speedup.
My impression is that depending on the GSL method, the function is evaluated
2-3 times more often than with the original Harwell code.
My guess is that because with Harwell, we calculated the Hessian once at
the beginning, and then update very rarely, it is efficient and needs less
function evaluations, whereas I maybe the GSL
routines re-calculate the Hessian more often. Can this be modified (eg
give a frequency for the calculation of the second derivatives) ?
- Another (general) problem in my case is that the parameters of the
parametric function vary over time (as I said the minimization is
interactive and the user can influence the function by changing its
parameters). This seems to be an intrinsic problem when using an
advanced fdf minimizer (other than steepest descent).
Are there other minimization methods (or workarounds) better adapted for
this case ?
Thanks in advance,
Marc Baaden
--
Dr. Marc Baaden - Institut de Biologie Physico-Chimique, Paris
mailto:baaden@smplinux.de - http://www.marc-baaden.de
FAX: +49 697912 39550 - Tel: +33 15841 5176 ou +33 609 843217
_______________________________________________
Help-gsl mailing list
Help-gsl@gnu.org
http://mail.gnu.org/mailman/listinfo/help-gsl
next reply other threads:[~2003-11-09 17:51 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-09 17:51 Marc Baaden [this message]
2003-11-09 18:23 ` Alan Aspuru-Guzik
2003-11-12 12:53 ` Brian Gough
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200311081040.LAA15830@apex.ibpc.fr \
--to=baaden@smplinux.de \
--cc=gsl-discuss@sources.redhat.com \
--cc=help-gsl@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).