<div class="gmail_quote">On Wed, Dec 22, 2010 at 10:41 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;">
NumPy version 2.0.0.dev-147f817<br></blockquote><div><br></div><div>There's your problem, it looks like the PYTHONPATH isn't seeing your new build for some reason.  That build is off of this commit in the NumPy master branch:</div>
<div><br></div><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><a href="https://github.com/numpy/numpy/commit/147f817eefd5efa56fa26b03953a51d533cc27ec">https://github.com/numpy/numpy/commit/147f817eefd5efa56fa26b03953a51d533cc27ec</a></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 reason I think it might help is that with 'luf' is that it's<br>
> calculating the expression on smaller sized arrays, which possibly<br>
> just got buffered. If the memory allocator for the temporaries keeps<br>
> giving back the same addresses, all this will be in one of the<br>
> caches very close to the CPU. Unless this cache is still too slow to<br>
> feed the SSE instructions, there should be a speed benefit.  The<br>
> ufunc inner loops could also use the SSE prefetch instructions based<br>
> on the stride to give some strong hints about where the next memory<br>
> bytes to use will be.<br>
<br>
</div>Ah, okay.  However, Numexpr is not meant to accelerate calculations with<br>
small operands.  I suppose that this is where your new iterator makes<br>
more sense: accelerating operations where some of the operands are small<br>
(i.e. fit in cache) and have to be broadcasted to match the<br>
dimensionality of the others.<br></blockquote><div><br></div><div>It's not about small operands, but small chunks of the operands at a time, with temporary arrays for intermediate calculations.  It's the small chunks + temporaries which must fit in cache to get the benefit, not the whole array.  The numexpr front page explains this fairly well in the section "Why It Works":</div>
<div><br></div><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><a href="http://code.google.com/p/numexpr/#Why_It_Works">http://code.google.com/p/numexpr/#Why_It_Works</a></div><div><br></div><div>-Mark</div>
</div>