Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Efficient sub-cube access #80

Open
drdnichols opened this issue Nov 7, 2019 · 1 comment
Open

Efficient sub-cube access #80

drdnichols opened this issue Nov 7, 2019 · 1 comment

Comments

@drdnichols
Copy link

drdnichols commented Nov 7, 2019

I would like to have a fast sub-cube access to a raw buffer from the C++ array classes.
I note that for the whole cube looping over the elements is 2-3x slower than using get(Scalar *p).

The view logic isnt faster as it basically ends up going through the same point-by-point accessors.

I implemented a in function (in zfparray3.h) that has the signature
get(Scalar *p, uint sub_x, unit sub_y, uint sub_z, uint sub_nx, uint sub_ny, uint sub_nz )

This uses the same strategy as get(Scalar *p) and visits each block only one and gets all the juice out of that block. It is a similar speed to the full cube get().

From a style point of view it would be nicer to have a view::get(Scalar *p) interface.
I.e. "just get the uncompressed bytes for this view". However view doesn't really have access to all the cache representation inside the array class.

Does anyone have suggestions for the cleanest way to do this?

@lindstro
Copy link
Member

lindstro commented Nov 7, 2019

@drdnichols I agree that it makes sense to support this functionality. I would have to think a little about the semantics of view::get(), as some of the views maintain their own cache. But the core array API ought to be reflected in view also. In the end, I suspect that view would mostly be implemented in terms of your more general array::get() function, so an argument could be made that both are needed/useful. Let me take some time to think about how to best support this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants