-
Notifications
You must be signed in to change notification settings - Fork 58
Ranges: Goals
Even though some algorithms like sort, remove or merge require quite complicated simd operations that I don’t see in our immediate future, we have to have a clear understanding on how we would like them to look.
There are two ways of structuring data: AoS (array of structs) and SoA (structs of arrays). For SIMD however using AoS is much worse since one would need to do complicated shuffles in order to extract fields. Which means we need to support SoA as a first class citizen - hense ZIP.
C++ developers are familiar with STL and we want to capitalize on that experience. However in some cases the STL interfaces will be extremely inefficient (for example - copy_if requires to know the output size in SIMD implementation), in which case we want to be very explicit about it and guarantee compilation breakage.
Alternative: we can sacrifice the consistency with STL in order to be internally consistent, for example since we need to know the output size for copy_if we can demand it for transform as well.
Even though we want simplicity by default, SIMD is mostly about efficiency, so we want to provide nobs to tweak things like unrolling, guarantee that the range length is divisible by the cardinality of the register etc. The specific tweaks are algorithm specific.
There are maybe some incentives to use different register width within the same algorithm. However it makes writing custom predicates much more complicated. Consider a trick with implementing is_space with a shuffle on sse4. We want to just be able to pass that to find without needing to deal with different wide cardinalities.
Theoretically using gather and scatter we could implement support for non contiguous ranges. However, we believe it to be a very niche use case and do not take it into account at the moment.
Though std::ranges found a great use out of smth like counted ranges, we do not yet see how to incorporate them efficiently.