2018-03-09 2:06 GMT+01:00 Nathaniel Smith <n...@pobox.com>: > On Thu, Mar 8, 2018 at 1:52 AM, Gregor Thalhammer > <gregor.thalham...@gmail.com> wrote: > > > > Hi, > > > > long time ago I wrote a wrapper to to use optimised and parallelized math > > functions from Intels vector math library > > geggo/uvml: Provide vectorized math function (MKL) for numpy > > > > I found it useful to inject (some of) the fast methods into numpy via > > np.set_num_ops(), to gain more performance without changing my programs. > > > > While this original project is outdated, I can imagine that a centralised > > way to swap the implementation of math functions is useful. Therefor I > > suggest to keep np.set_num_ops(), but admittedly I do not understand all > the > > technical implications of the proposed change. > > The main part of the proposal is to merge the two libraries; the > question of whether to deprecate set_numeric_ops is a bit separate. > There's no technical obstacle to keeping it, except the usual issue of > having more cruft to maintain :-). > > It's usually true that any monkeypatching interface will be useful to > someone under some circumstances, but we usually don't consider this a > good enough reason on its own to add and maintain these kinds of > interfaces. And an unfortunate side-effect of these kinds of hacky > interfaces is that they can end up removing the pressure to solve > problems properly. In this case, better solutions would include: > > - Adding support for accelerated vector math libraries to NumPy > directly (e.g. MKL, yeppp) > > I just want to bring the Sleef <https://github.com/shibatch/sleef> library for vectorized math (C99) into the discussion. Recently a new version with a stabilized API has been provided by its authors. The library is now well documented http://sleef.org and available under the permissive boost license. A runtime CPU dispatcher is used for the different SIMD variants (SSE2, AVX, AVX2, FMA ...)
However, I never understand how a vectorized math library can be easily used with numpy arrays in all manners (strided arrays i.e.). > - Overriding the inner loops inside ufuncs like numpy.add that > np.ndarray.__add__ ultimately calls. This would speed up all addition > (whether or not it uses Python + syntax), would be a more general > solution (e.g. you could monkeypatch np.exp to use MKL's fast > vectorized exp), would let you skip reimplementing all the tricky > shared bits of the ufunc logic, etc. Conceptually it's not even very > hacky, because we allow you add new loops to existing ufuncs; making > it possible to replace existing loops wouldn't be a big stretch. (In > fact it's possible that we already allow this; I haven't checked.) > > So I still lean towards deprecating set_numeric_ops. It's not the most > crucial part of the proposal though; if it turns out to be too > controversial then I'll take it out. > > -n > > -- > Nathaniel J. Smith -- https://vorpus.org > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
