"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."
I am not surprised by your results because, contrary to what my previous messages might suggest, I think that the main problem is not the allocations themselves but memory location. At least for certain problems, the machine is just much more efficient at accessing stack memory. Unfortunately, it seems that it is not trivial to implement the init functions that I suggested previously. This is because the minimizer has to accept different types of objects depending on the problem. The library currently uses void pointers, but that does not work if you need the objects to be known at compile-time. Here the lack of overloading in C really kills it (one would need many more names for types and functions, which could have a deep impact in the API. G On Mon, Oct 7, 2013 at 3:39 PM, Sam Mason <[email protected]>wrote: > Hi, > > On 7 October 2013 18:22, onefire <[email protected]> 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 >
