[Numpy-discussion] Introductory mail and GSoc Project "Vector math library integration"

[Daπid]

On 11 March 2015 at 16:51, Dp Docs <sdpan21 at gmail.com> wrote:

>
>
> On Wed, Mar 11, 2015 at 7:52 PM, Sturla Molden <sturla.molden at gmail.com>
> wrote:
> >
> ​Hi sturla,
> Thanks for suggestion.​
>
> > There are several vector math libraries NumPy could use, e.g. MKL/VML,
> > Apple Accelerate (vecLib), ACML, and probably others.
>
> ​Are these libraries fast enough in comparison to C maths libraries?​
>

These are the fastest beast out there, written in C, Assembly, and arcane
incantations.


> > There are at least two ways to proceed here. One is to only use vector
> > math when strides and alignment allow it.
> ​I didn't got it. can you explain in detail?​
>

One example, you can create a numpy 2D array using only the odd columns of
a matrix.

odd_matrix = full_matrix[::2, ::2]

This is just a view of the original data, so you save the time and the
memory of making a copy. The drawback is that you trash memory locality, as
the elements are not contiguous in memory. If the memory is guaranteed to
be contiguous, a compiler can apply extra optimisations, and this is what
vector libraries usually assume. What I think Sturla is suggesting with
"when strides and aligment allow it" is to use the fast version if the
array is contiguous, and fall back to the present implementation otherwise.
Another would be to make an optimally aligned copy, but that could eat up
whatever time we save from using the faster library, and other problems.

The difficulty with Numpy's strides is that they allow so many ways of
manipulating the data... (alternating elements, transpositions, different
precisions...).


> I think the actual problem is not "to choose which library to integrate",
> it is how to integrate these libraries? as I have seen the code base and
> been told the current implementation uses the c math library, Can we just
> use the current  implementation and whenever it is calling ​C Maths
> functions, we will replace by these above fast library functions?Then we
> have to modify the Numpy library (which usually get imported for maths
> operation) by using some if else conditions like first work with the faster
> one  and if it is not available the look for the Default one.
>

At the moment, we are linking to whichever LAPACK is avaliable at compile
time, so no need for a runtime check. I guess it could (should?) be the
same.


> Moreover, I have Another Doubt also. are we suppose to integrate just one
> fast library or more than one so that if one is not available, look for the
> second one and if second is not available then either go to default are
> look for the third one if available?
> Are we suppose to think like this: Let say "exp" is faster in sleef
> library so integrate sleef library for this operation and let say "sin" is
> faster in any other library, so integrate that library for sin operation? I
> mean, it may be possible that different operations are faster in different
> libraries So the implementation should be operation oriented or just
> integrate one complete library?​Thanks​
>

Which one is faster depends on the hardware, the version of the library,
and even the size of the problem:

http://s3.postimg.org/wz0eis1o3/single.png

I don't think you can reliably decide ahead of time which one should go for
each operation. But, on the other hand, whichever one you go for will
probably be fast enough for anyone using Python. Most of the work here is
adapting Numpy's machinery to dispatch a call to the vector library, once
that is ready, adding another one will hopefully be easier. At least, at
the moment Numpy can use one of several linear algebra packages (MKL,
ATLAS, CBLAS...) and they are added, I think, without too much pain (but
maybe I am just far away from the screams of whoever did it).


/David.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20150311/ad5bf501/attachment.html>