Re: [Help-gsl] gsl performance

[Simon Zehnder]

Hi Gilbaerto,

congrats on your performance results! 

A first guess of the worse performance of the gsl library would be exception 
throwing. The GSL is made for 'users' and this means, that a user has to be 
informed about the kind of exception he encounters. This can be left out if you 
have your own code and you know your own code. If something goes wrong, you 
know where to look in your code where the error occurred and what could be the 
reasons. A 'user' just using a library could be helpless when he encounters and 
error and does not know where it occurred. So checking and error catching could 
be a reason, that makes the gsl less performant but more appropriate for 'easy' 
usage. 

I use a lot the C++ linear algebra library Armadillo. This library has for 
example two different element accessors: One, '()' which makes checkings and 
the second 'at()' with no checkings. Performance increases sometimes 
tremendously when using the 'at()' method. 

Best

Simon


On Oct 6, 2013, at 12:44 AM, onefire <address@hidden> wrote:

> Hi all,
> 
> I am creating a personal library for my C++ projects and to evaluate its
> performance I decided to compare it to gsl and, to my surprise, my library
> is much faster than gsl in many cases. For example, my Nelder-Mead
> implementation can be 5 or 10 faster for some functions.
> 
> This has been bothering me a lot because:
> 1) My tests are correct, and I checked the results against output from
> Scipy and Octave.
> 2) I am certainly not smarter than the many people who worked on gsl over
> the years.
> 3) I think I know how to use gsl "properly".
> 
> Sorry I do not have an example, but my library is not polished enough for
> me to publish it yet.
> 
> What I am really intrigued about  is that I googled around and it seems
> that many people noticed (before me) that many gsl implementations are
> inefficient. I also found some posts on the mailing lists with things like
> "gsl is much slower than Matlab" and responses like "gsl is not meant to be
> the fastest".
> 
> These things lead me to believe that gsl is "slow" by design, If this is
> the case, can someone explain to me why this is so?
> 
> Gilberto
> 
> PS: Much of the gain with C++ comes from better inlining, which can be
> specially important with things like function optimization (it is hard, if
> not impossible, to inline when there is a funcyion pointer passed around).
> This is why std::sort can be much faster than lqsort. However, I am
> confident that it is possible to write faster implementations (in C) than
> some of the ones in gsl.