<div dir="ltr">On Wed, Jun 19, 2013 at 7:48 AM, Charles R Harris <span dir="ltr"><<a href="mailto:charlesr.harris@gmail.com" target="_blank">charlesr.harris@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><br><div class="gmail_quote"><div><div>On Wed, Jun 19, 2013 at 5:45 AM, Matthew Brett <span dir="ltr"><<a href="mailto:matthew.brett@gmail.com" target="_blank">matthew.brett@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<div><div><br>
On Wed, Jun 19, 2013 at 1:43 AM, Frédéric Bastien <<a href="mailto:nouiz@nouiz.org" target="_blank">nouiz@nouiz.org</a>> wrote:<br>
> Hi,<br>
><br>
><br>
> On Mon, Jun 17, 2013 at 5:03 PM, Julian Taylor<br>
> <<a href="mailto:jtaylor.debian@googlemail.com" target="_blank">jtaylor.debian@googlemail.com</a>> wrote:<br>
>><br>
>> 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>
>> 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>
><br>
><br>
> I don't recall a discussion when numexpr was done as this is before I read<br>
> this list. numexpr do optimization that can't be done by NumPy: fusing<br>
> element-wise operation in one call. So I don't see how it could be done to<br>
> reuse it in NumPy.<br>
><br>
> You call your optimization trivial, but I don't. In the git log of NumPy,<br>
> the first commit is in 2001. It is the first time someone do this in 12<br>
> years! Also, this give 1.5-8x speed up (from memory from your PR<br>
> description). This is not negligible. But how much time did you spend on<br>
> them? Also, some of them are processor dependent, how many people in this<br>
> 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<br>
> of optimization. 1) The inner loop/contiguous cases, 2) the strided,<br>
> broadcasted level. We don't need all optimization being done for them to be<br>
> useful. Any of them are useful.<br>
><br>
> So what I think is that we could reuse/share that work. NumPy have c code<br>
> generator. They could call minivect code generator for some of them when<br>
> compiling NumPy. This will make optimization done to those code generator<br>
> reused by more people. For example, when new processor are launched, we will<br>
> need only 1 place to change for many projects. Or for example, it the call<br>
> to MKL vector library is done there, more people will benefit from it. Right<br>
> now, only numexpr do it.<br>
><br>
> About the level 2 optimization (strides, broadcast), I never read NumPy code<br>
> that deal with that. Do someone that know it have an idea if it would be<br>
> possible to reuse minivect for this?<br>
<br>
</div></div>Would someone be able to guide some of the numpy C experts into a room<br>
to do some thinking / writing on this at the scipy conference?<br>
<br>
I completely agree that these kind of optimizations and code sharing<br>
seem likely to be very important for the future.<br>
<br>
I'm not at the conference, but if there's anything I can do to help,<br>
please someone let me know.<br></blockquote></div></div><div><br>Concerning the future development of numpy, I'd also suggest that we look at <a href="https://github.com/ContinuumIO/libdynd" target="_blank">libdynd</a>. It looks to me like it is reaching a level of maturity where it is worth trying to plan out a long term path to merger.<br>

</div></div></blockquote><div><br></div><div>I'm in Austin for SciPy, and will giving a talk on the dynd library on Thursday, please drop by if you can make it, I'm very interested in cross-pollination of ideas between numpy, libdynd, blaze, and other array programming projects. The Python exposure of dynd as it is now can transform data to/from numpy via views very easily, where the data is compatible, and I expect libdynd and numpy to live alongside each other for quite some time. One possible way things could work is to think of libdynd as a more rapidly changing "playground" for functionality that would be nice to have in numpy, without the guarantees of C-level ABI or API backwards compatibility that numpy has, at least before libdynd 1.0.</div>
<div><br></div><div style>Cheers,</div><div style>Mark</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div>
<br>Chuck<br></div><br></div>
<br>_______________________________________________<br>
NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@scipy.org" target="_blank">NumPy-Discussion@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/numpy-discussion" target="_blank">http://mail.scipy.org/mailman/listinfo/numpy-discussion</a><br>
<br></blockquote></div><br></div></div>