[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Help-gsl] gsl performance
From: |
Simon Zehnder |
Subject: |
Re: [Help-gsl] gsl performance |
Date: |
Sun, 6 Oct 2013 11:09:24 +0200 |
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.
- [Help-gsl] gsl performance, onefire, 2013/10/06
- Re: [Help-gsl] gsl performance,
Simon Zehnder <=
- Re: [Help-gsl] gsl performance, onefire, 2013/10/06
- Re: [Help-gsl] gsl performance, Simon Zehnder, 2013/10/06
- Re: [Help-gsl] gsl performance, onefire, 2013/10/06
- Re: [Help-gsl] gsl performance, Rhys Ulerich, 2013/10/06
- Re: [Help-gsl] gsl performance, onefire, 2013/10/07
- Re: [Help-gsl] gsl performance, Sam Mason, 2013/10/07
- Re: [Help-gsl] gsl performance, onefire, 2013/10/07
- Re: [Help-gsl] gsl performance, Sam Mason, 2013/10/08
- Re: [Help-gsl] gsl performance, onefire, 2013/10/08