Incrementing vectors

Re:Incrementing vectors by heyiforgotmypwd on Tuesday August 27, 2019 @01:59AM (#20806706)

More-so than the compiler, it depends on the design goals that are implemented in width and speed of the processor's registers, SIMD vector and conventional integer units. For x86, one could readily guess un/signed ints (32 & 64-bit) would be fast; un/signed 8/16-bit math is unlikely to be as fast. That hypothesis is backed-up by this article's data.

[ Parent | on HN ]

Re:Incrementing vectors by tom_mellior on Tuesday August 27, 2019 @03:23AM (#20807031)

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.

[ Parent | on HN ]

Re:Incrementing vectors by slavik81 on Tuesday August 27, 2019 @03:50AM (#20807205)

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

[ Parent | on HN ]

Re:Incrementing vectors by tom_mellior on Tuesday August 27, 2019 @04:01AM (#20807253)

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.

[ Parent | on HN ]

Re:Incrementing vectors by BeeOnRope on Tuesday August 27, 2019 @11:37AM (#20810746)

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.

[ Parent | on HN ]

Re:Incrementing vectors by slavik81 on Tuesday August 27, 2019 @01:10PM (#20812063)

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

[ Parent | on HN ]

Re:Incrementing vectors by hoseja on Tuesday August 27, 2019 @03:48AM (#20807192)

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...

[ Parent | on HN ]