Re: [Help-gsl] gsl performance

[Sam Mason]

Hi,

On 7 October 2013 18:22, onefire <address@hidden> wrote:
> One, which I like, is that the routines give the user low-level control
> over their progress in the sense that you can create an object, manually
> iterate and observe their progress. I prefer this over having a single
> function that does the work until convergence (but see below).

Yes, everybody wants to terminate at different places—flat gradient,
max number of steps, some combination or other condition...  Having
this outside of the GSL makes sense.  You could let this be evaluated
by another callback, but then this would be three callbacks now?

Reading your earlier messages, implies that you want to perform many
minimizations (or other algorithms?).  Could you not just allocate one
minimizer (or one per thread) and "reset" it as needed? That way you
don't need to be free()ing/malloc()ing same "same" memory all the
time.  I guess it depends on whether the number of variables changes.

I tried this technique with the ODE solvers in the GSL and it gave me
about 5% overall performance improvement so I dropped it from my code,
it was a fiddle to maintain and the user would barely notice the
difference.  I was doing quite a lot of other things, so maybe if your
overall time is dominated by malloc/free it may help.

Not sure whether it would be worth trying a different memory
allocator.  There used to be faster ones available, but they could
well be folded into the standard libraries now.

Hope some of that is useful for you!

  Sam