<div dir="ltr"><div><div><div><div><div><div class="gmail_extra">Hi,<br><br><br><div class="gmail_quote">On Mon, Jun 17, 2013 at 5:03 PM, Julian Taylor <span dir="ltr"><<a href="mailto:jtaylor.debian@googlemail.com" target="_blank">jtaylor.debian@googlemail.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 class="im">On 17.06.2013 17:11, Frédéric Bastien wrote:<br>
> Hi,<br>
><br>
> I saw that recently Julian Taylor is doing many low level optimization<br>
> like using SSE instruction. I think it is great.<br>
><br>
> Last year, Mark Florisson released the minivect[1] project that he<br>
> worked on during is master thesis. minivect is a compiler for<br>
> element-wise expression that do some of the same low level optimization<br>
> that Julian is doing in NumPy right now.<br>
><br>
> Mark did minivect in a way that allow it to be reused by other project.<br>
> It is used now by Cython and Numba I think. I had plan to reuse it in<br>
> Theano, but I didn't got the time to integrate it up to now.<br>
><br>
> What about reusing it in NumPy? I think that some of Julian optimization<br>
> aren't in minivect (I didn't check to confirm). But from I heard,<br>
> minivect don't implement reduction and there is a pull request to<br>
> optimize this in NumPy.<br>
<br>
</div>Hi,<br>
what I vectorized is just the really easy cases of unit stride<br>
continuous operations, so the min/max reductions which is now in numpy<br>
is in essence pretty trivial.<br>
minivect goes much further in optimizing general strided access and<br>
broadcasting via loop optimizations (it seems to have a lot of overlap<br>
with the graphite loop optimizer available in GCC [0]) so my code is<br>
probably not of very much use to minivect.<br>
<br>
The most interesting part in minivect for numpy is probably the<br>
optimization of broadcasting loops which seem to be pretty inefficient<br>
in numpy [0].<br>
<br>
Concerning the rest I'm not sure how much of a bottleneck general<br>
strided operations really are in common numpy using code.<br>
<br>
<br>
I guess a similar discussion about adding an expression compiler to<br>
numpy has already happened when numexpr was released?<br>
If yes what was the outcome of that?<br></blockquote><div><br>I don't recall a discussion when numexpr was 
done as this is before I read this list. numexpr do optimization that 
can't be done by NumPy: fusing element-wise operation in one call. So I 
don't see how it could be done to reuse it in NumPy.<br><br>You 
call your optimization trivial, but I don't. In the git log of NumPy, 
the first commit is in 2001. It is the first time someone do this in 12 
years! Also, this give 1.5-8x speed up (from memory from your PR 
description). This is not negligible. But how much time did you spend on
 them? Also, some of them are processor dependent, how many people in 
this list already have done this? I suppose not many.<br><br>Yes, 
your optimization don't cover all cases that minivect do. I see 2 level 
of optimization. 1) The inner loop/contiguous cases, 2) the strided, 
broadcasted level. We don't need all optimization being done for them to
 be useful. Any of them are useful.<br><br>So what I think is that
 we could reuse/share that work. NumPy have c code generator. They could
 call minivect code generator for some of them when compiling NumPy. 
This will make optimization done to those code generator reused by more 
people. For example, when new processor are launched, we will need only 1
 place to change for many projects. Or for example, it the call to MKL 
vector library is done there, more people will benefit from it. Right 
now, only numexpr do it.<br><br><div>About the level 2 
optimization (strides, broadcast), I never read NumPy code that deal with that. Do someone  that know it have an idea if it would be possible to reuse minivect
 for this?<br></div><br>Frédéric<br></div></div></div></div></div></div></div></div></div>