Vec should be depreacated?

[TApplencourt]

Specification Version

SYCL 2020 (Revision 11)

Section Number(s)

Somewhere

Bug Description

• marray is the better version of vec?
• vec map directly to Opencl vector type
• • Vectorization between work-item. So marray.
• marray should have convert? Maybe marray should be keep simple.

[tdavidcl]

Hi,

I can give some perspective relative to use of sycl::vec in Shamrock, which we do employ throughout the code.

First off from the user perspective they are both useful and confusing. OFC most HPC physics software out there manipulate 3d data so the convenience of already having 3d vector type on hand + geometrical functions can not be understated. However, they :

• 1 lack flexibility (limited to power of 2 and n=3 is aliased to n=4),
• 2 can be confusing in their interactions with some other construct in SYCL since they are not a primitive type (kind of an hybrid between a primitive and array),
• 3 swizzling is not intuitive compared to shading languages (dang the .xyzw syntax of glsl is good),
• 4 could be thought as automatic vectorization tool (but does not cut it in practice),
• 5 have weird behavior related to performance in some implementation (DPC++ on Aurora get almost the bandwidth halved for vector types compared to raw float/doubles).

So I'm all in on deprecating them, but only if a migration path/alternative is outlined and the geometrical function are kept in the standard (speaking of which it would be great to include all of the standard geometrical functions available in glsl for people coming from the computer graphics community).

PS: I never really got the time to play with marray since it was not stable in implementations when I designed the core of Shamrock.