Simd vector types

Evolution Pitches
51

I think you're discounting a lot here. Vector8<Int16> is the natural spelling for this type. It runs parallel to other collections like Array<Int16> and Set<Int16> . It is utterly unsurprising and requires no explanation to users.

Thinking of simd vectors as just another collection is almost always a mistake. This draft happens to have them conform to Collection, because it was convenient, but it's really not obvious that they should, since much of the Collection API is something of an attractive nuisance when applied to simd vectors, due to operations on slices being wildly less efficient than the type itself, and there being more efficient ways to do most of the operations that Collection provides, with no easy way to shoehorn them into the Collection API.

Additionally, the way you want to interact with them as much as possible is as abstract objects, not as things that you iterate or map over. That's how you get efficient code.

Because of this I'm very OK with these being visibly distinct from "other collections".

And you now want to provide a vectorized implementation. How do you do that? With my design, you'd say something like:

extension Collection where Element: VectorizableInteger4 {
  func sum() -> Element {
    var result = Vector4<Element>()
    ...
  }
}

A diversion: this is precisely the wrong way to vectorize such an operation--your "generic" implementation will not be close to optimal for element sizes smaller than what you originally wrote for, because you'll waste half or more of your bandwidth, and you're likely to end up with spilling on x86 for larger element sizes (though you may get away with it on arm64). You don't want Vector4<Element>. You want VectorMachineWidth<Element> or similar.

We can also do this with any of the designs discussed as something like Element.VectorMachineWidth. It's a little bit more cumbersome in the VecN.T design, but it's still only adding protocol and a few typedefs, rather than near-complete duplication of all the machinery. I am still unconvinced. I don't think that VectorN<T> is worse, but I also don't think that it's enough better to justify the added overhead.

To be honest, using generics should be the default position here, and I have not yet seen an adequate explanation for why we should deviate from that default.

That it requires fighting the language the whole way and writing almost 2x as much code is pretty convincing to me, but apparently not you.

5 Likes