[SYCL][DOC] Update marray specification

[jle-quel]

Description

In response to feedback from @steffenlarsen on the specification implementation (#8647), several adjustments were made:

• Corrected missing operators identified in the specification (See 3rd commit: 3b35704)
• Removed unnecessary operators initially added (See 3rd commit: 3b35704)
• Applied formatting and reordering for improved readability (See 1st and 4th commit: ff1f4e3, 7147da4)

Question

Additionally, I question the need to explicitly delete operators, considering they are not automatically generated nor inherited from the generic marray. I propose an approach to only include the necessary operators for implementation (See 2nd commit: 300a22e).

If agreed, the part that stipulates to delete the operators and the deleted operators in the inline code would be removed. (Explaining why this PR is a Draft)

If not, this raises a question for future implementers: Is it necessary to explicitly delete all operators, or can the declarations be omitted?

[steffenlarsen]

Additionally, I question the need to explicitly delete operators, considering they are not automatically generated nor inherited from the generic marray. I propose an approach to only include the necessary operators for implementation (See 2nd commit: 300a22e).

You are right, they are not required to be explicitly defined, but I would argue that the benefit of defining them is that we express explicit intent. That is, by specifying that these operators are deleted, the user can easily see that we intentionally disallow them and it tells us that whoever wrote the extension thought about the operators and concluded that they should not be there and should not be added in the future.

[gmlueck]

I'm not opposed to this PR, but I think the entire section "Marray Complex Class Specialization" is not really necessary. The marray operators are available for any DataT that is a C++ Numeric Type. Since the complex type is a Numeric Type, they are automatically supported by marray.

I agree that we need some documentation about which operators are available. There is a proposal in the Khronos issue DB that the SYCL specification should have general wording saying that each marray operator is only available if the underlying DataT supports that operator (e.g. operator+ is only supported on marray<DataT> if operator+ is also supported on DataT). See Khronos issue 559, which requires access to the Khronos issue DB.

[jle-quel]

I understand your comment @gmlueck but do you believe that we should first fix the specification for what it already is?

This PR is not the one that introduces the Marray Complex Class Specialization but is opened
to fix and update some of the comments that have been previously made.

We could right after, open another PR that continues the conversation you started? (also asking your opinion @steffenlarsen )

PS: With the possible removal of the Marray Complex Class Specialization would that mean as well that the marray specialization implementation is not relevant anymore?

[gmlueck]

PS: With the possible removal of the Marray Complex Class Specialization would that mean as well that the marray specialization implementation is not relevant anymore?

This is a good question. It seems like the base definition of marray should work with any numerical type, which would include complex. Why do we need to implement any specialization? One reason might be performance. Are we implementing the specialization in order to optimize the complex case somehow? It seems like we should not need to specialize in order to have a correct implementation.

[jle-quel]

PS: With the possible removal of the Marray Complex Class Specialization would that mean as well that the marray specialization implementation is not relevant anymore?

This is a good question. It seems like the base definition of marray should work with any numerical type, which would include complex. Why do we need to implement any specialization? One reason might be performance. Are we implementing the specialization in order to optimize the complex case somehow? It seems like we should not need to specialize in order to have a correct implementation.

As you said, the base definition of marray supports any numerical type, thus including complex.
I ran the tests from the marray specialization PR without the specialization and all tests passes.

The specialization when first introduced, was here to add free functions that mimics the complex class.
In other words getter/setter API for real and imag as presented in the first reference to the specialization.

• [SYCL][Doc] Add SYCL marray complex extension proposal #6550
• [SYCL][DOC] Introduce sycl-marray-complex specialization proposal #8852

We already had a discussion on these free functions, and we came to the conclusion that this should not be added to the marray specialization (see #8852).

The specialization is now just here to delete the inapplicable operators not supported by complex but does not add any optimization in the specialization.

With your latest comment and looking at it with fresh eyes, makes me question the relevance of the specialization.

Any counter arguments on this @steffenlarsen ?

PS: The operators needed to be hidden friends, but the base marray definition now defines the operators this way.

[jle-quel]

Gentle ping to get your attention @gmlueck @steffenlarsen ☝️

[steffenlarsen]

Attention acquired! Sorry, I don't know how I missed both pings! 😬

I vaguely remember part of the reason for the specialization was to allow us to optimize the data layout of the complex marrays, i.e. instead of them being packed in pairs of imag/real, we could pack all imags in consecutive memory and reals in consecutive memory. That said, if there is no need for any special member functions, I don't see how the spec would disallow us specializing the marray class, as long as it has all the required members, as it should not be observable by the user. Even if we wanted special members, I would argue we could get away with something like:

namespace sycl {

template <typename DataT, std::size_t NumElements> class marray {
public:
  ...

  /* Available only when DataT is complex */
  void ext_oneapi_my_new_member();
};
}

That only goes for purely additive changes though. No excluding existing members!

With that in mind, I think we should go ahead with these changes and re-evaluate the need for the specialization when the SYCL 2020 specification issue is resolved. Preferably we would have a Github issue to track that, just so we don't lose it. 😉

[gmlueck]

I vaguely remember part of the reason for the specialization was to allow us to optimize the data layout of the complex marrays, i.e. instead of them being packed in pairs of imag/real, we could pack all imags in consecutive memory and reals in consecutive memory.

This is not allowed because the definition of marray specifically says that the layout is the same as storing an array of DataT elements:

https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#memory-layout-and-alignment.marray

Does our specialization change the layout?

[jle-quel]

Does our specialization change the layout?

It does not