[tom_mellior]

Did you read to the end? The final results show that in the end the computation on the vectors with 8-bit elements is 4x as fast (per element) as the computation on the vectors with 32-bit elements.

EDIT ignore the following, I was mistaken: Infuriatingly the article doesn't benchmark signed 8-bit vectors. If the issue is due to the special aliasing properties of pointers to unsigned bytes, signed should just work really fast out of the box, without jumping through any hoops.

[slavik81]

The issue is due to the special properties of C character types, which include char, signed char and unsigned char. uint8_t and int8_t are not required to be character types, but they're typically implemented as typedefs of the char types, so they pick up the same properties. Here's the GCC bug discussing this problem: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66110

[tom_mellior]

Thanks. I misremembered C's rules as only unsigned char having this special property (as well as plain char if it's unsigned), but not signed char.

[BeeOnRope]

I think you are partly right.

My understanding is that the special aliasing rules apply only to `char` and `unsigned char` in C++, not to `signed char`. In C, however, I think it applies to all three.

AFAIK char is a distinct type from signed char and unsigned char, regardless of whether it is signed or not. In practice it will have the same representation as those but will not be the same type:

https://godbolt.org/z/D6ylkf

So `signed char` would seem to be a way to get a strongly typed char not subject to the aliasing rules (even if bare char is signed), but compilers don't take advantage as far as I can tell.

[slavik81]

Just to back you up, this post quotes both standards: https://stackoverflow.com/a/51228315/331041

[hoseja]

Did you? it clearly states these aliasing rules apply to character types[0].

[0] https://travisdowns.github.io/blog/2019/08/26/vector-inc.htm...