Initializing temp_array as a view of another array
robertmaxton42 opened this issue · comments
It'd be nice if there was a way to reinterpret an array "in place" - for example, taking an array with a non-zero offset and building from it a view with zero offset (so that the new 'array' starts, presumably, with some number of padding zeroes) - without creating an entire new array and copying all the data over for the purpose. This can now be done with Thread.array(base=), but as far as I can tell there's no way to do in the planning stage, without access to the actual Thread object, and I'm not sure how it'd behave when called on a temporary array anyway.
So do you essentially want to create a view of a temporary array? What is the use case here? Because if the only difference is the offset, this view will be accessed in exactly the same way from a kernel.
Wait, really? I thought macros like load_idx took the offset into account, and have been writing with that assumption. Should I have been adding offset to all my indices?
Also, that aside, one of the big advantages of coding in Python - especially Jupyter/IPython, as I am - is the ability to just check your work every couple of lines, rather than having to compile something every time. Kernel calls diminish that some, but it's still possible to just ask for a printout of your test array as a sanity check. Thing is, there's no way to get at the padding/offset bytes from outside the kernel, so if your algorithm uses the padding area for temporary storage there's no way to see if it's recorded the right answers, meaning there's a big black box in the middle of your code that's hard to test.
(Granted, I could potentially fix that by changing my algorithm... but, well, in this case it'd probably mean duplicating my working array entirely, and that array is taking up a solid third of my on-GPU RAM as it is. >.>)
If I can reset the offset, I can 'peek' into the padding, and potentially I don't even need to copy my data back into the "center" if it's the last step that needs padding anyway, which saves on time too.
Except, of course, that you can't do that during a planned computation anyway, and outside that you can just use Thread.array. Nevermind. That being said, though, it's still rather error prone to manually keep track of offsets or shift large segments of overlapping memory; whenever possible I prefer to make the computer keep track for me.
Also, that aside, one of the big advantages of coding in Python - especially Jupyter/IPython, as I am - is the ability to just check your work every couple of lines, rather than having to compile something every time.
That actually bothers me a lot as well, and I have plans for a new API that will make writing and debugging computations easier. But that's a different story.
Wait, really? I thought macros like load_idx took the offset into account, and have been writing with that assumption.
They do, I misunderstood you. So you want two temporary arrays pointing at the same physical buffer at different offsets? Not sure how to organize it better...
That actually bothers me a lot as well, and I have plans for a new API that will make writing and debugging computations easier. But that's a different story.
Heh. Best of luck, then.
They do, I misunderstood you. So you want two temporary arrays pointing at the same physical buffer at different offsets? Not sure how to organize it better...
Pretty much, yeah. Ideally an equivalent to numpy's as_strided would be nice, for arbitrarily silly views, but I'd settle for a temp_array that worked like array itself does now.