Hi, On 7 October 2013 18:22, onefire <onefire.mys...@gmail.com> 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