> The npy_math functions are used if otherwise unavailable OR if someone > has at some point noticed that say glibc 2.4-2.10 has a bad quality > tan (or whatever) and added a special case hack that checks for those > particular library versions and uses our built-in version instead. > It's not the most convenient setup to maintain, so there's been some > discussion of trying openlibm instead [1], but AFAIK you're the first > person to find the time to actually sit down and try doing it :-). > > You should be able to tell what math library you're linked to by > running ldd (on linux) or otool (on OS X) against the .so / .dylib > files inside your built copy of numpy -- e.g. > > ldd numpy/core/umath.cpython-34m.so > > (exact filename and command will vary depending on python version and > platform). > > -n > > [1] > https://github.com/numpy/numpy/search?q=openlibm&type=Issues&utf8=%E2%9C%93 > > Ok, I with a little help from someone, at least I got it to work somehow. Apparently linking to openlibm is not a problem, MATHLIB=openlibm does the job. The resulting .so-files are linked to openlibm AND libm. I do not know why, maybe you would have to call gcc with -nostdlib and explicitly include everything you need. When running such a build of numpy, however, only the functions in libm are called.
What did the job was to export LD_PRELOAD=/usr/lib/libopenlibm.so. In that case the functions from openlibm are used. This works with any build of numpy and needs no rebuilding. Of course its hacky and not a solution but at the moment it seems by far the easiest way to use a different libm implementation. This does also work with intels libimf. It does not work with amdlibm as they use the prefix amd_ in function names which would require real changes to the build system. Very superficial benchmarks (see below) seem devastating for gnu libm. It seems that openlibm (compiled with gcc -mtune=native -O3) performs really well and intels libm implementation is the best (on my intel CPU). I did not check the accuracy of the functions, though. My own code uses a lot of trigonometric and complex functions (optics calculations). I'd guess it could go 25% faster by just using a better libm implementation. Therefore, I have an interest in getting sane linking to a defined libm implementation to work. Apparently openlibm seems quite a good choice for numpy, at least performance wise. However, I did not find any documentation or tests of the accuracy of its functions. A benchmarking and testing (for accuracy) code for libms would probably be a good starting point for a discussion. I could maybe help with that - but apparently not with any linking/building stuff (I just don't get it). Benchmark: gnu libm.so 3000 x sin(double[100000]): 6.68215647800389 s 3000 x log(double[100000]): 8.86350397899514 s 3000 x exp(double[100000]): 6.560557693999726 s openlibm.so 3000 x sin(double[100000]): 4.5058218560006935 s 3000 x log(double[100000]): 4.106520485998772 s 3000 x exp(double[100000]): 4.597905882001214 s Intel libimf.so 3000 x sin(double[100000]): 4.282402812998043 s 3000 x log(double[100000]): 4.008453270995233 s 3000 x exp(double[100000]): 3.301279639999848 s
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
