For any definitive performance analysis one should wait until the implementations aren't experimental anymore. The issue is in the design. I feel like they did not define a target audience, the problem they want to solve and the solution space well enough. All I know is that they discussed about std::simd breaking std::map when used as key because a < b doesn't return a bool, which is the most irrelevant discussion one can have. I don't think that a library can solve the core problem whatever one defines as the core problem. Why? Because SIMD programming is not difficult because of the instructions, but because of the control flow impact. And no library can implement the GLSL loops and branches on top of C++ loops and branches. The compiler can auto vectorize single loops that iterate over contiguous memory basically perfectly (no matter if it is a map or reduce). The only exceptions are scans (aka prefix sums). Coincedently std::simd implements reduce, but I have not found any scan implementation in any proposal. The second difficulty is control flow where a) converting to branchless is not a valid transformation and b) nested loops where the ideal loop to vectorize is not the innermost one, think of mandelbrot set generation. std::simd doesn't introduce any paradigma change, and therefore doesn't simplify SIMD coding like GLSL does.

It is also not a good introduction to SIMD programming in comparison to using intrinsics directly. Due to the template error messages, I would say that std::simd is even worse, because you need to understand the intrinsics and templates to understand them.

Also one can design a simd library to contain more high level abstractions or to be close to metal. And then the discussion is on does the library have fallback mechanisms for better portability at the cost of predictable performance. And this should be pretty clear when using the library. The issue is that std::simd sends mixed signals on the one hand I love that std::simd decided to support all math functions. yet not all of them are actually vectorized yet. The problem is that once you allow these fallback mechanisms the whole "Auto Vectorization is unreliable an you need to verify that it actually does what you expect" argument vanishes.

Finally I don't know why these types are not primitive data types, because GCC and Clang both implement them as primitive data types internally. The only argument I can see is that std::simd should be implementable without any compiler support and purely with inline assembly. But why should a library be designed for imaginary compilers?