Documentation for oneAPI data management backend primitives

[Vika-F]

ndview, ndarray and related primitives are documented.

---

PR completeness and readability

• I have reviewed my changes thoroughly before submitting this pull request.
• I have commented my code, particularly in hard-to-understand areas.
• I have updated the documentation to reflect the changes or created a separate PR with update and provided its number in the description, if necessary.
• Git commit message contains an appropriate signed-off-by string (see CONTRIBUTING.md for details).
• I have added a respective label(s) to PR if I have a permission for that.
• I have resolved any merge conflicts that might occur with the base branch.

[david-cortes-intel]

Would be helpful if we could merge this PR first:
#3004

So that we could then check that this one isn't introducing new warnings that might be masked by previous ones in the CI logs.

[david-cortes-intel]

How does it differ from sycl's own class?

[Vika-F]

I do not think sycl has own multidimensional data representations.

[david-cortes-intel]

But it does have a 1D marray. Lots of the usage for views is as 1D containers, so I was curious about their usage over sycl's.

[Vika-F]

I think besides of multidimensionality, our data structures are interoperable in the sense one can easily view the same data block as dal::table, dal::array, dal::backend::primitives::ndview, etc.

Also here we implement convenience functions like slice, transpose, to_host, etc.

With sycl own structures the amount of code inside oneDAL algorithmic kernels would be much bigger. Anyway we would need to wrap some common operations into functions. This class groups those common operations on the data together.

[david-cortes-intel]

Would be helpful to add a hint to prefer these custom classes instead of sycl's.

[Vika-F]

@rakshithgb-fujitsu, @keeranroth can you please provide the feedback?

[keeranroth]

The comments look good for the code that is present, so I've refrained from commenting on the code. But for my own information, is there a plan to make the views constexpr, or to have the layout separate from the data, so that the offsets into arrays / pointers / multi-dimensional arrays can be calculated at compile time? And does the implementation support arbitrary shapes and strides, e.g. having a layout of the shape (a, (b, c), d), which is a 3 dimensional object, where the second dimension is a 2-dimensional object. This is useful in terms of doing things like cache-blocking. Not for this code review, but it would be great to see functionality like this, if it doesn't already exist

[Vika-F]

@keeranroth

is there a plan to make the views constexpr, or to have the layout separate from the data, so that the offsets into arrays / pointers / multi-dimensional arrays can be calculated at compile time?

No, there are no such plans for now.
Currently in our code base the sizes of ndarrays are usually related to the sizes of input/output data tables which is run-time information and cannot be constexpr.

But I understand that it might be beneficial to have ndarrays of constexpr sizes to represent some data blocks used in intermediate computations.

And does the implementation support arbitrary shapes and strides ...?

I think it would be more correct to answer "no" to this question. Because:

• ndarray and ndview do not support strides at all. The layout of the data is defined only with the data's dimensions. For now we do not have the plans to support strided data layouts.
• the arbitrary shapes like (a, (b, c), d) are not supported also. For the purposes of caching we usually use regular (or parallel) loops creating ndviews that cache the respective data blocks on each iteration. It is allowed to create multiple ndviews pointing to different parts of the data table, for example.
  So, this (a, (b, c), d) structure might be emulated with loops + ndviews of lower dimension.

[keeranroth]

Looks good to me. Couldn't find anything obviously out of place