cyl_bessel_j performance

Hi, cyl_bessel_j is several times slower than jn from glibc for me. What do I do wrong? Bessel function from boost.math seems to be pretty good coded and optimized but in a runtime it baffles me.

cyl_bessel_j is several times slower than jn from glibc for me. What do I do wrong? Bessel function from boost.math seems to be pretty good coded and optimized but in a runtime it baffles me.
There are potentially several issue here: * Are you building with all optimizations on? If not it will be way way slower: remember the code is expanded inline in your program and not in a separate lib. * Are you calling cyl_bessel_j with the first parameter an integer type? This saves a few cycles over a floating-point argument call since the algorithm doesn't have to figure out whether the parameter is an integer or not. * I confess that's not a class of Math functions I've spent much time optimizing for speed. * There may be a few domains of the function that are deliberately slower in order to avoid the worst of the inaccuracies that the bessel functions can suffer from. Even given all of the above, they shouldn't be "several times slower", so if you have a specific test case I'll investigate what's wrong. HTH, John.

Thanks for your reply. Yes, fortunately my charges were completely unfounded. I was confused by gcc behaviour. When I compile with explicit -O2 the timing is roughly same. So, if I may, yet another question. I suppose math::tr1 bessels use math implementation, aren't they? John Maddock wrote:
cyl_bessel_j is several times slower than jn from glibc for me. What do I do wrong? Bessel function from boost.math seems to be pretty good coded and optimized but in a runtime it baffles me.
There are potentially several issue here:
* Are you building with all optimizations on? If not it will be way way slower: remember the code is expanded inline in your program and not in a separate lib. * Are you calling cyl_bessel_j with the first parameter an integer type? This saves a few cycles over a floating-point argument call since the algorithm doesn't have to figure out whether the parameter is an integer or not. * I confess that's not a class of Math functions I've spent much time optimizing for speed. * There may be a few domains of the function that are deliberately slower in order to avoid the worst of the inaccuracies that the bessel functions can suffer from.
Even given all of the above, they shouldn't be "several times slower", so if you have a specific test case I'll investigate what's wrong.
HTH, John.

Thanks for your reply. Yes, fortunately my charges were completely unfounded. I was confused by gcc behaviour. When I compile with explicit -O2 the timing is roughly same.
Whew :-)
So, if I may, yet another question. I suppose math::tr1 bessels use math implementation, aren't they?
Yes, it's they just use slightly different policies from the default to conform to C99's error handling requirements (ie no C++ exceptions get thrown). HTH, John.
participants (2)
-
John Maddock
-
Matwey V. Kornilov