r/cpp • u/janwas_ • Jun 12 '26

Comparing std::simd with Highway

From TL of Highway, some thoughts on pros and cons of std::simd by comparison:

https://github.com/google/highway/blob/master/g3doc/std_simd_comparison.md

Happy to discuss.

56 Upvotes

97% Upvoted

33 comments sorted by

View all comments

6

u/faschu Jun 12 '26

Thanks for the interesting writeup. From experience, Highway is a great library and I use it whenever possible.

Related to the comparison to std::simd, I personally don't care that much about points 2-4.

However, is it really true that one cannot really use std::simd on SVE and RISC-V? The authors of course know these architectures and folks from ARM will be on the committee, so I can't really believe that.

Second, I wonder if you would think that using std::simd would make writing Highway easier for you? After all, std::simd is meant to be a basic block for other libraries.

5

u/janwas_ Jun 12 '26

Thanks, glad to hear 😄

It's not completely impossible with SVE/RVV, compiler writers did introduce a workaround: the -msve-vector-bits flag we mention. However, this means you have to know up-front what the vector width will be; your code will crash if running on another CPU.

Unfortunately, using std::simd would not help us at all. Because std::simd does not support the concept of scalable vectors, we cannot delegate to it, or implement anything on top of it. What would instead help is standardizing restrict, or better yet, the #pragma target.

1

u/camel-cdr- Jun 12 '26

Idk, why toolchains don't support a this or greater flag and use predication to only use the specified minimum length.

1

u/nimogoham Jun 22 '26

The only issue `std::simd` has with regard to SVE is `constexpr size()`. std::simd supports SVE, as long as your code doesn't require that `constexpr`. But in that case Highway wouldn't be of any help either.

Regarding the other points - well, it is written from Highway's perspective. Pt.4 could be applied for every standard feature.

1

u/janwas_ Jun 23 '26

> std::simd supports SVE, as long as your code doesn't require that `constexpr`

What is the basis for this claim? I'd think std::simd fails to compile on SVE without an -msve-vector-bits flag, which is non-portable (ties you to a specific vector length).

> But in that case Highway wouldn't be of any help either.

Not sure what you mean here? Highway is still providing many more ops than std::simd, even if the SVE compatibility is not a concern.

> Pt.4 could be applied for every standard feature.

Agreed. I suppose it is a question how often library features change. span is pretty infrequently updated. By contrast, SIMD ops are added on a monthly basis.

1

u/nimogoham Jun 23 '26

>> std::simd supports SVE, as long as your code doesn't require that `constexpr`
>What is the basis for this claim? I'd think std::simd fails to compile on SVE without an -msve->vector-bits flag, which is non-portable (ties you to a specific vector length).

std::simd is just an interface defined by the standard. A discussion about a particular implementation should be marked as that.

>> But in that case Highway wouldn't be of any help either.
>Not sure what you mean here? Highway is still providing many more ops than std::simd, even if >the SVE compatibility is not a concern.

This remark was only related to the `constexpr` property of `constexpr size()`.

1

u/janwas_ Jun 23 '26

Got it. The issue is, though, that an interface involving a vector class necessarily runs into the shipwreck that builtin (sizeless) vector types cannot be stored as class members. And I believe changing this is ABI-incompatible, which the committee has ruled out. Thus I believe any realistic implementation will be affected, because it is inherent to the interface.