<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Feb 28, 2014 at 5:52 AM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">performance should not be impacted as long as we stay on the stack, it<br>
just increases offset of a stack pointer a bit more.<br>
E.g. nditer and einsum use temporary stack arrays of this type for its<br>
initialization:<br>
op_axes_arrays[NPY_MAXARGS][NPY_MAXDIMS]; // both 32 currently<br>
The resulting nditer structure is then in heap space and dependent on<br>
the real amount of arguments it got.<br>
So I'm more worried about running out of stack space, though the limit<br>
is usually 8mb so taking 128kb for a short while should be ok.<br>
<div class="HOEnZb"><div class="h5"><br>
On 28.02.2014 13:32, Francesc Alted wrote:<br>
> Well, what numexpr is using is basically NpyIter_AdvancedNew:<br>
><br>
> <a href="https://github.com/pydata/numexpr/blob/master/numexpr/interpreter.cpp#L1178" target="_blank">https://github.com/pydata/numexpr/blob/master/numexpr/interpreter.cpp#L1178</a><br>
><br>
> and nothing else.  If NPY_MAXARGS could be increased just for that, and<br>
> without ABI breaking, then fine.  If not, we should have to wait until<br>
> 1.9 I am afraid.<br>
><br>
> On the other hand, increasing the temporary arrays in nditer from 32kb<br>
> to 128kb is a bit worrying, but probably we should do some benchmarks<br>
> and see how much performance would be compromised (if any).<br>
><br>
> Francesc<br>
><br>
> On 2/28/14, 1:09 PM, Julian Taylor wrote:<br>
>> hm increasing it for PyArrayMapIterObject would break the public ABI.<br>
>> While nobody should be using this part of the ABI its not appropriate<br>
>> for a bugfix release.<br>
>> Note that as it currently stands in numpy 1.9.dev we will break this ABI<br>
>> for the indexing improvements.<br>
>><br>
>> Though for nditer and some other functions we could change it if thats<br>
>> enough.<br>
>> It would bump some temporary arrays of nditer from 32kb to 128kb, I<br>
>> think that would still be fine, but getting to the point where we should<br>
>> move them onto the heap.<br></div></div></blockquote><div><br></div><div>These sort of changes can have subtle side effects and need lots of testing in a release cycle. Bugfix release cycles are kept short by restricting changes to those that look simple and safe.<br>
<br></div><div><snip><br><br></div><div>Chuck <br></div><br></div></div></div>