2016-02-08 18:54 GMT+01:00 Julian Taylor <jtaylor.deb...@googlemail.com>: > which version of glibm was used here? There are significant difference > in performance between versions. > Also the input ranges are very important for these functions, depending > on input the speed of these functions can vary by factors of 1000. > > glibm now includes vectorized versions of most math functions, does > openlibm have vectorized math? > Thats where most speed can be gained, a lot more than 25%.
glibc 2.22 was used running on archlinux. As far as I know openlibm does not include special vectorized functions. (for reference vectorized operations in glibc: https://sourceware.org/glibc/wiki/libmvec). 2016-02-08 23:32 GMT+01:00 Gregor Thalhammer <gregor.thalham...@gmail.com>: > Years ago I made the vectorized math functions from Intels Vector Math > Library (VML), part of MKL, available for numpy, see > https://github.com/geggo/uvml > Not particularly difficult, you not even have to change numpy. For some > cases (e.g., exp) I have seen speedups up to 5x-10x. Unfortunately MKL is > not free, and free vector math libraries like yeppp implement much fewer > functions or do not support the required strided memory layout. But to > improve performance, numexpr, numba or theano are much better. > > Gregor > > Thank you very much for the link! I did not know about numpy.set_numeric_ops. You are right, vectorized operations can push down calculation time per element by factors. The benchmarks done for the yeppp-project also indicate that (however far you would trust them: http://www.yeppp.info/benchmarks.html). But I would agree that this domain should be left to specialized tools like numexpr as fully exploiting the speedup depends on the expression, that should be calculated. It is not suitable as a standard for numpy. Still, I think it would be good to give the possibility to choose the libm numpy links against. And be it simply to allow to choose or guarantee a specific accuracy/performance on different platforms and systems. Maybe maintaining a de-facto libm in npy_math could be replaced with a dependency on e.g. openlibm. But such a decision would require a thorough benchmark/testing of the available solutions. Especially with respect to the accuracy-performance-tradeoff that was mentioned. Cheers Nils
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion