Proposal: Rename SIMD vectors

[ikskuh]

#7295 once again shows once again that most programmers associate the word vector with a linear algebra vector type and not with a SIMD vector.

I proposa a rename to SIMD array, but i'm open for other names. I'm pretty much happy with any name that is not vector, as it is more confusing than helping.

[zigazeljko]

For the type itself, we can simply use the name Simd (e.g. std.builtin.TypeInfo.Simd, std.meta.Simd).

[PetorSFZ]

Why not just call them SIMD registers? Would also give it some synergy with the register keyword in C, as I assume you can't take the reference to a SIMD register or store it in a struct anyway.

[SpexGuy]

I assume you can't take the reference to a SIMD register or store it in a struct anyway.

You can do this, it behaves more like __m128 from C. It can be stored in memory, and it's aligned to the appropriate alignment for fast access on your target platform. It's more like an array type but with support for parallel operations and more alignment.

[PetorSFZ]

I assume you can't take the reference to a SIMD register or store it in a struct anyway.

You can do this, it behaves more like __m128 from C. It can be stored in memory, and it's aligned to the appropriate alignment for fast access on your target platform. It's more like an array type but with support for parallel operations and more alignment.

Huh, that's sort of weird. I always thought that was one of the biggest mistakes with __m128. Unless you have many elements you are processing (i.e. an array) SIMD is basically pointless. And having an array of __m128 is just weird.

[ikskuh]

For the type itself, we can simply use the name Simd (e.g. std.builtin.TypeInfo.Simd, std.meta.Simd).

I think that would be the most fitting type. "It's a type that provides simultaneous operations on a range of data".

As @SpexGuy said, Simd types aren't Simd register equivalents and may be emulated if the hardware doesn't support it, but allows to express the intent to process the data in parallel if possible

[floooh]

Sorry for my drive by comment, but for game and graphics programmers, the name "vector" is associated with vector math (of length 2 to 4), and the std::vector<> type name doesn't make much sense. The name SIMD would imply to me that SIMD registers/instructions are always involved, but this shouldn't be the case(?)

Whether the code is actually translated to SIMD instructions should depend on the target platform and compiler options (for instance it should still be possible to compile to WASM without SIMD support).

It would be great IMHO, if Zig could offer the feature set of Clangs ext_vector_type C extension (the ext is important), this seems to enable math code that looks identical to shading languages like GLSL or HLSL (for instance swizzling, or multiplying with a scalar):

https://www.godbolt.org/z/zWGfcY5a4

The other thing that's needed to be "feature complete" is an ext_matrix_type which seamlessly works together with ext_vector_type vectors.

[SpexGuy]

The goal isn't so much to guarantee simd, but to encourage it. The semantics of other language constructs make it difficult or impossible to auto-vectorize code in most cases. Zig's Vector is trying to provide the optimizer with semantics that are more compatible to vectorization. It's not a hard guarantee that simd will be used, but the feature is designed in such a way that simd is usually the best way for the optimizer to implement it. However, the feature is defined in a way that does not strictly require hardware simd support. So if you are compiling to a platform that doesn't have simd instructions, the program will still compile and run correctly. Additionally, if you are for example doing a large number of by-element vector accesses on a platform with only SSE2, the optimizer may realize that simd would be less efficient than scalars, and decide to destructure the vector into multiple scalar values instead.