Re: [Help-gsl] Possible leak in gsl_multifit_fdfsolver.
Hi, 2013/10/6 Eduardo Novaes Hering: In the end, when the gsl_multifit_fdfsolver should be freed, some trash is left in that address and I get the following, intermittent, extremely annoying error after I try to leave my data processing functions: malloc: *** error for object 0x100810cc0: incorrect checksum for freed object - object was probably modified after being freed. *** set a breakpoint in malloc_error_break to debug Program received signal SIGABRT, Aborted. 0x7fff88c1ad46 in __kill () if you see such a message, the first thing you should do is to analyze the problem with Valgrind - just install it and prepend the command you start your program with (including command line arguments) with valgrind , and look at the first error message. One possible cause of such an error would be that your function f writes to memory that you don't own. Cheers, Frank
Re: [Help-gsl] gsl performance
If there is a chance of a patch getting accepted I will certainly submit it if I have one. I took a look at the code in the multimin directory last night (the last problem affects other parts of the library but my example was about the multidimensional minimizer, so I figured I would start there). I might be wrong, but the way I see it, gsl has two design characteristics that by themselves do not cause much harm but, if combined, make it very hard to use stack arrays internally. 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). The other thing that seems to be common in the library is that it seems to never let the user handle the allocations. For example if I wanted to do this: gsl_multimin_fminimizer s; gsl_multimin_fminimizer_type T; gsl_multimin_fminimizer_type_init(T); gsl_multimin_fminimizer_init(s, T, n); I just could not do it because the library does not provide such init functions. The above has the advantage that it allows the caller to have objects in the stack. If ones wants arrays that are on the stack, this is necessary because: 1) Since the work is done across multiple function calls, the internal arrays need to live until the minimizer object dies, so the arrays need to be automatic variables inside the object. 2) If the internal arrays are automatic objects, they are allocated on the stack only if the object itself is allocated on the stack, so one really needs to have the option to allocate on the stack. The way I see it, there are two options to get around this, none of them having to break the API but rather extend it: 1) Provide functions that do all the work until convergence (or a user-specified maximum number of iterations) without creating an object. This gives the user less control, but they could always use the standard methods to control the iterations. This is what I do in my library, and by itself it provides a (small) performance improvement because you can skip the creation of objects. But most importantly for the present discussion, it allows the internal arrays to be automatic variables inside such function. 2) Provide additional init and finalize functions (or whatever we want to call them) to let the user handle the allocations (if she wants to) herself. I am not sure about which option I prefer. Gilberto On Sun, Oct 6, 2013 at 9:40 PM, Rhys Ulerich rhys.uler...@gmail.com wrote: Rhys, I did try to use views. They do not help because the gsl routines allocate vectors internally and there is not much that I can do about it... except for maybe hacking gsl and changing gsl_vector_alloc myself. If from hacking around you happen to restructure the API so that a clean workspace can be allocated for a given problem size and then passed in to avoid the problematic internal allocations, please pass along a patch. There's a lot of precedent in the library for having low-level compute kernels wrapped by convenience methods, and refactoring a kernel to match that pattern would be most welcome provided the existing APIs remain unbroken. - Rhys
Re: [Help-gsl] gsl performance
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
Re: [Help-gsl] gsl performance
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 sammasonwarwick...@gmail.comwrote: 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
[Help-gsl] Non-natural Akima end conditions
Anyone know how to achieve non-natural end conditions with the GSL akima routines? I am coding up some Blasius function fits where getting derivatives at the wall as correct as possible against values from the literature has a physically important meaning. - Rhys
