<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 11, 2015 at 11:20 PM, Dp Docs <span dir="ltr"><<a href="mailto:sdpan21@gmail.com" target="_blank">sdpan21@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span class=""><br><br>On Thu, Mar 12, 2015 at 2:01 AM, Daπid <<a href="mailto:davidmenhur@gmail.com" target="_blank">davidmenhur@gmail.com</a>> wrote:<br>><br>> On 11 March 2015 at 16:51, Dp Docs <<a href="mailto:sdpan21@gmail.com" target="_blank">sdpan21@gmail.com</a>> wrote:<br>>> On Wed, Mar 11, 2015 at 7:52 PM, Sturla Molden <<a href="mailto:sturla.molden@gmail.com" target="_blank">sturla.molden@gmail.com</a>> wrote:<br>>> ><br></span><span class="">>> > There are at least two ways to proceed here. One is to only use vector<br>>> > math when strides and alignment allow it.<br>>> I didn't got it. can you explain in detail?<br>><br>><br>> One example, you can create a numpy 2D array using only the odd columns of a matrix.<br>><br>> odd_matrix = full_matrix[::2, ::2]<br>><br>> 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 <div style="font-family:verdana,sans-serif;display:inline">​>​</div>memory locality, as the elements are not contiguous in memory. If the memory is guaranteed to be contiguous, a compiler can apply <div style="font-family:verdana,sans-serif;display:inline">​>​</div>extra optimisations, and this is what vector libraries usually assume. What I think Sturla is suggesting with "when strides and aligment <div style="font-family:verdana,sans-serif;display:inline">​>​</div>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 <div style="font-family:verdana,sans-serif;display:inline">​>​</div>make an optimally aligned copy, but that could eat up whatever time we save from using the faster library, and other problems.<br>><br>> The difficulty with Numpy's strides is that they allow so many ways of manipulating the data... (alternating elements, transpositions, different precisions...).<br>>  <br>>><br>>> 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 <div style="font-family:verdana,sans-serif;display:inline">​>>​</div>base and been told the current implementation uses the c math library, Can we just use the current  implementation and whenever it <div style="font-family:verdana,sans-serif;display:inline">​>>​</div>is calling C Maths functions, we will replace by these above fast library functions?Then we have to modify the Numpy library (which <div style="font-family:verdana,sans-serif;display:inline">​>>​</div>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 <div style="font-family:verdana,sans-serif;display:inline">​>>​</div>the look for the Default one.<br>><br>><br>> 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 <div style="font-family:verdana,sans-serif;display:inline">​>​</div>(should?) be the same.</span><div><div><font face="verdana, sans-serif">​I didn't understand this. I was asking about let say I have chosen one faster library, now I need to integrate this​ in </font><u style="font-family:verdana,sans-serif">some way </u>without changing the default functionality <font face="verdana, sans-serif">so that when Numpy will import "</font><span style="font-family:arial,sans-serif;color:rgb(0,0,0)">from numpy import *</span><font face="verdana, sans-serif">",it should be able to access the integrated libraries functions as well as default libraries </font><font face="verdana, sans-serif">functions, What should we be </font>that<u style="font-family:verdana,sans-serif"> some way</u><font face="verdana, sans-serif">?​ Even at the Compile, it need to decide that which Function it is going to use, right?</font></div></div></div></blockquote><div><br></div><div>Indeed, it should probably work similar to how BLAS/LAPACK functions are treated now. So you can support multiple libraries in numpy (pick only one to start with of course), but at compile time you'd pick the one to use. Then that library gets always called under the hood, i.e. no new public functions/objects in numpy but only improved performance of existing ones.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><font face="verdana, sans-serif"> It have been discussed above about integration of MKL libraries but when MKL is not available on the hardware Architecture, will the above library support as default library? if yes, then the Above discussed integration method may be the required one for integration in this project, right?</font></div><div><div style="font-family:verdana,sans-serif">Can you please tell me a bit more or provide some link related to that?​</div><div style="font-family:verdana,sans-serif">Availability of these faster Libraries depends on the Hardware Architectures etc. or availability of hardware Resources in a System? because if it is later one, this newly integrated library will support operations some time while sometimes not? </div></div></div></div></blockquote><div><br></div><div>Not HW resources I'd think. Looking at <a href="http://www.yeppp.info">http://www.yeppp.info</a>, it supports all commonly used cpus/instruction sets. <br>As long as the accuracy of the library is OK this should not be noticeable to users except for the difference in performance.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div style="font-family:verdana,sans-serif">I believe it's the first one but it is better to clear any type of confusion. For example, assuming availability of Hardware means later one,  let say if library A needed the A1 for it's support and A1 is busy then it will not be able to support the operation. Meanwhile, library B, needs Support of hardware type B1 , and it's not Busy then it will support these operations. What I want to say is Assuming the Availability of faster lib. means availability of hardware Resources in a System at a particular time when we want to do operation, it's totally unpredictable and Availability of these resources will be Random and even worse, if it take a bit extra time between compile and running, and that h/d resource have been allocated to other process in the meantime then it would be very problematic to use these operations. So this leads to think that Availability of lib. means type of h/d architecture whether it supports or not that lib. Since there are many kind of h/d architecture and it is not the case that one library support all these architectures (though it may be), So we need to integrate more than one lib. for providing support to all kind of architecture (in ideal case which will make it to be a very big project). <br><span style="font-family:arial,sans-serif">>  </span></div><span class="">>><br>>> 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? <br>>> 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<br>><br>><br>> Which one is faster depends on the hardware, the version of the library, and even the size of the problem:</span></div><span class=""><div>> <a href="http://s3.postimg.org/wz0eis1o3/single.png" target="_blank">http://s3.postimg.org/wz0eis1o3/single.png</a><br>></div><div>> 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 <div style="font-family:verdana,sans-serif;display:inline">​>​</div>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 <div style="font-family:verdana,sans-serif;display:inline">​>​</div>the vector library, once that is ready, adding another one will hopefully be easier. At least, at the moment Numpy can use one of <div style="font-family:verdana,sans-serif;display:inline">​>​</div>several linear algebra packages (MKL, ATLAS, CBLAS...) and they are added, I think, without too much pain (but maybe I am just far <div style="font-family:verdana,sans-serif;display:inline">​>​</div>away from the screams of whoever did it).<br>></div></span><div><div style="font-family:verdana,sans-serif">​​​So we are supposed to integrate just one of these libraries?(rest will use default if they didn't support) ​MKL seems to be good but as it have been discussed above that it's non-free and it have been integrated also, can you suggest any other library which at least approximate MKL in a better way? Though Eigen seems to be good, but it's seems to be worse in middle ranges. can you provide any link which provide comparative information about all available vector libraries(Free)?​​</div></div></div></div></blockquote><div><br></div><div>The idea on the GSoC page suggests <a href="http://www.yeppp.info/">http://www.yeppp.info/</a> or SLEEF (<a href="http://shibatch.sourceforge.net/">http://shibatch.sourceforge.net/</a>). Based on those websites I'm 99.9% sure that yeppp is a better bet. At least its benchmarks say that it's faster than MKL. As for the project, Julian (who'd likely be the main mentor) has already indicated when suggesting the idea that he has no interest in a non-free library: <a href="http://comments.gmane.org/gmane.comp.python.numeric.general/56933">http://comments.gmane.org/gmane.comp.python.numeric.general/56933</a>. So Yeppp + the build architecture to support multiple libraries later on would probably be a good target.<br><br></div><div>Cheers,<br></div><div>Ralf<br><br></div></div><br></div></div>