Re: New Library Proposal: xvec/simd

From: Towner, Daniel (daniel.towner_at_[hidden])
Date: 2022-09-23 17:18:59

> I'd be interested in a SIMD library. Some thoughts below, in no particular order.

> Is there public source code and documentation available online? Note that www.intel.com and other Intel sites are not accessible in some regions, so I don't consider those public.

We would put it up at github.com/intel alongside our other open-source contributions. I can't test that myself to see if that is accessible in all regions, but I assume it is might be more accessible than our main website. It is currently undergoing internal review before being published.

> I'm interested whether the library integrates well with SIMD intrinsics.
> I imagine that the generic interface does not support some of the more exotic instructions, like horizontal arithmetics, data shuffling, cryptography, etc., so code that relies on these
> operations would need to use compiler intrinsics directly.

We have provided mechanisms to make it relatively easy to use intrinsics since there will always be a need to write at least some platform dependent code to get at the exotic instructions for special cases. The simplest mechanism (already proposed in std::simd) allows a simd<> value to be converted to and from builtin types so that an intrinsic can be called directly. It is more tricky to deal with a simd<> value which is bigger than the native type (e.g., a fixed_size_simd<float, 60> would be multiple AVX2 or AVX-512 registers), so we have provided a mechanism which breaks a large simd down into native-register pieces, calls a supplied intrinsic, and then glues the results back together again. The std::simd proposal doesn't have anything like that at the moment, but it would be interesting to see if that behaviour could be captured to allow intrinsics on other targets to work in the same way.

> The fact that the library is based on gcc vector extensions will be a problem for MSVC users. Are there any plans to tackle this? Not that supporting any particular compiler is a must for a Boost library, but MSVC still has a significant user base, and > Boost is known, among other things, for its portability. Supporting MSVC would be desirable.

We have tried to lean on the gcc/llvm compilers as much as possible to handle the SIMD for us since that allows us to reach a wide range of SIMD-capable targets without having to write reams of intrinsic-based code to deal with the details. It is a pity that MSVC doesn't implement those too. There are probably ways to handle MSVC too in the future, but for now we plan to devote our time to supporting gcc and llvm instead.

> On the topic of portability, what is the minimum C++ version requirement?

C++20 at the moment, because we use things like concepts to make it easier to write, and we provide overloads for functions from <bit>. With some more verbosity in the code we could support older standards.
 
> Are there any performance numbers and comparisons with other solutions? In particular, with code that directly uses compiler intrinsics.

Right from the start we have been very conscious of performance; there was no point in creating something that was slower than intrinsic-based alternatives, even if it did simplify the code. Our goal has always been that we should have comparable performance to intrinsic based solutions. I don't have numbers that I can share publicly yet, but performance isn't something that worries me. 

> Regarding inclusion in Boost, note that the library has to be licensed under the Boost Software License 1.0.

I don't think that will be a problem.

> Using googletest for tests might be problematic as we currently don't have it in pre-requisites, and I don't think there's infrastructure for installing it from an external source. 
> Unless this is resolved somehow, porting tests to one of the Boost solutions will probably be desired.

I suspected that would be the case. At the moment we use type parameterised tests: we list all the valid simd element types and all the valid sizes, and then gtest checks every combination against a suite of appropriate tests. So all simds would have basic operations checked  (constructors, indexing, permuting, etc), then simd<_Float16|float|double> would add in a floating-point test suite, simd<unsignedX> would add in shifts and rotates, and so on.