Open paugier opened 2 years ago
@hodgestar brought to my attention that this is already the contract of tp_iternext
(https://docs.python.org/3/c-api/typeobj.html#c.PyTypeObject.tp_iternext):
When the iterator is exhausted, it must return NULL; a StopIteration exception may or may not be set.
This should be also the contract in HPy. I would keep this issue open, because I think the next thigh we can try is to update piconumpy HPy to use tp_iternext
in this way and see how it changes the benchmark results.
Just a note: I guess tp_iternext
will be used for loops like for value in arr:
(microbench sum_loop) but not in the case of direct indexing of the array in the loop (microbench sum_loop_index, which is a very common pattern).
As long as the exception is never thrown at runtime, i.e., you check the terminating condition yourself preemptively without raising and catching the exception, it should be fine.
In https://github.com/hpyproject/hpy/issues/263, @steve-s discovered that the line
HPyErr_SetString(ctx, ctx->h_IndexError, "index out of range");
leads to a performance issue for code looping over a array defined with HPy (in practice a piconumpy array). If I understand well, he proposed a possible solution involving an extension of HPy API:It seems that this issue with
HPyErr_SetString(ctx, ctx->h_IndexError, "index out of range");
also applies totp_iter
(https://github.com/hpyproject/hpy/issues/263#issuecomment-988111355).Since https://github.com/hpyproject/hpy/issues/263 is too broad, I create this issue to discuss this specific proposition.
This addition could drastically improved the performance of low level Python code looping over an array defined with HPy (more than an order of magnitude speedup given the results described in https://github.com/hpyproject/hpy/issues/263).