You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I took a look at the generated code and I added comments for the varying bits. It seems that the varying parts are quite small and the same for each set of dimensions. I don't see any parts that have combinations between dtype and shape. I think the string concatenated code could be greatly reduced, or possibly eliminated if you were willing to manually build out a set of dimensional arrays.
It looks like you sometimes define stride and shape as arrays, and sometimes as a varying number of scalars (_shape0, _shape2...)
If you always dealt with shape and stride as arrays, you could write generic code to deal with these cases.
There is also the special case that get/set work differently for custom data types. This is used in things like ndarray-hash to implement sparse data types.
The other issue with using arrays for shape and stride is that it slows down array accesses. You could do everything at runtime, but the whole point of using code generation is for performance.
I might add a dynamic version of ndarray for supporting systems with CSP that block Function/eval, but this would also require figuring out a better solution for cwise.
@xieyuheng It's a package for component-wise operations on ndarrays: https://www.npmjs.com/package/cwise. It accepts operations as a function but parses and rewrites them as flat, cache-efficient loops.
I took a look at the generated code and I added comments for the varying bits. It seems that the varying parts are quite small and the same for each set of dimensions. I don't see any parts that have combinations between dtype and shape. I think the string concatenated code could be greatly reduced, or possibly eliminated if you were willing to manually build out a set of dimensional arrays.
It looks like you sometimes define stride and shape as arrays, and sometimes as a varying number of scalars (_shape0, _shape2...)
If you always dealt with shape and stride as arrays, you could write generic code to deal with these cases.
Am I missing something here?
The text was updated successfully, but these errors were encountered: