def process_element(a, b):
r = np.empty_like(a) . # what happens here? i would really want this to be a stack allocation, but the size is not known at compile time, so i guess not?
for i in len(a): # this is bad; len(a) is not a compile-time constant, so this loop will never be unrolled
r[i] = a[i] * b[i]
def process_array(arr):
output = np.empty_like(arr)
for i in range(len(arr)):
output[i] = process_element(arr[i], arr[i])
return output
--
You received this message because you are subscribed to the Google Groups "Numba Public Discussion - Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to numba-users+unsubscribe@continuum.io.
To post to this group, send email to numba...@continuum.io.
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/numba-users/c4033061-452a-45be-b8ea-c60648dfd013%40continuum.io.
For more options, visit https://groups.google.com/a/continuum.io/d/optout.
Hi Eelco,We've talked about stack allocation of small arrays, as we've also seen the need in ray-tracing like projects that we've done with Numba. We don't have a solution for this at the moment, and you correctly identify that more complex data structures are not handled well in Numba. This is something we want to improve, but I don't have an ETA for you.As for alternatives, Cython is the usual go-to for when you want compiled code, more complex data structures and to be callable from Python.
On Wed, Sep 6, 2017 at 3:52 AM, Eelco Hoogendoorn <hoogendo...@gmail.com> wrote:
I frequently find myself faced with arrays that are 'big' amonst some dimensions, but small (2, 3, 4) along some other dimensions. I think in an ideal world, we could inform numba that we would like to specialize our functions on the shape of our arrays along an axis, such that some array dimensions become compile-time constants; but in the absence of that, how do we efficiently deal with small vector sizes?The function below is obviously silly; there are easier ways to do an elementwise multiplication of an array; but you end up with similar patterns when for instance implementing a raytracer:
def process_element(a, b):
r = np.empty_like(a) . # what happens here? i would really want this to be a stack allocation, but the size is not known at compile time, so i guess not?
for i in len(a): # this is bad; len(a) is not a compile-time constant, so this loop will never be unrolled
r[i] = a[i] * b[i]
def process_array(arr):
output = np.empty_like(arr)
for i in range(len(arr)):
output[i] = process_element(arr[i], arr[i])
return outputStruct-arrays can help here I suppose; if we define a dtype([(np.int, 3)]), and make len==1 array of that, would numba stack-allocate that 'scalar'? And would it unroll loops over the length of that structure? Is there an idiomatic pattern of approaching this?And in general, is there a way to allocate array-like objects on the stack? Or should we always work with views to larger blocks of memory allocated on the heap? ( in the example above, make r an output arg).Most examples and compelling benchmarks of numba ive seen appear focussed on more straightforward array processing, and not on 'complex' datastructures. Am I simply asking too much of numba in trying to write something like a raytracer in it and expect to be competitive in terms of expressiveness and performance to existing high performance languages? Or can someone point me to a project that does tackle the concerns raised here?Regards,Eelco
--
You received this message because you are subscribed to the Google Groups "Numba Public Discussion - Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to numba-users...@continuum.io.
To unsubscribe from this group and stop receiving emails from it, send an email to numba-users+unsubscribe@continuum.io.
To post to this group, send email to numba...@continuum.io.
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/numba-users/59fe7257-f19d-41cb-853c-2cd5dc18ab66%40continuum.io.