<div class="gmail_quote">On Mon, Jan 10, 2011 at 9:47 AM, Francesc Alted <span dir="ltr"><<a href="mailto:faltet@pytables.org">faltet@pytables.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><snip></div>
<br>
so, the new code is just < 5% slower.  I suppose that removing the<br>
NPY_ITER_ALIGNED flag would give us a bit more performance, but that's<br>
great as it is now.  How did you do that?  Your new_iter branch in NumPy<br>
already deals with unaligned data, right?<br></blockquote><div><br></div><div>Take a look at  lowlevel_strided_loops.c.src.  In this case, the buffering setup code calls PyArray_GetDTypeTransferFunction, which in turn calls PyArray_GetStridedCopyFn, which on an x86 platform returns _aligned_strided_to_contig_size8.  This function has a simple loop of copies using a npy_uint64 data type.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
> The new code also needs support for the reduce operation.  I didn't<br>
> look too closely at the code for that, but a nested iteration<br>
> pattern is probably appropriate.  If the inner loop is just allowed<br>
> to be one dimension, it could be done without actually creating the<br>
> inner iterator.<br>
<br>
</div>Well, if you can support reduce operations with your patch that would be<br>
extremely good news as I'm afraid that the current reduce code is a bit<br>
broken in Numexpr (at least, I vaguely remember seeing it working badly<br>
in some cases).<br></blockquote><div> </div><div>Cool, I'll take a look at some point.  I imagine with the most obvious implementation small reductions would perform poorly.</div><div><br></div><div>-Mark</div></div>