Every time I write NEON code I wish the strongly typed vectors did not exist in GCC. vreinterpret_* stuff is useless and should just die.
It's sad to see Rust repeating this mistake. Burst doesn't.
=> More informations about this toot | More toots from zeux@mastodon.gamedev.place
and this is part of their portable SIMD stuff as well of course!
=> More informations about this toot | More toots from zeux@mastodon.gamedev.place
@zeux Genuine question to understand, would you want an untyped vector instead which can be used as f32/i32/u32 or even 16 or 8 bit? Basically, a "register" type? Then how do you convey to the compiler that e.g. it needs to use the sign-extending variant of some method or the zero-filling one? Or is it just that all intrinsics are standalone functions (not methods, c++ terminology) taking that untyped vector, and the semantic is exclusively in the function name (which I guess works)?
=> More informations about this toot | More toots from djee@mastodon.gamedev.place
@djee You have two ways to encode this information: in the type name or the intrinsic (function) name.
The latter is how Rust already works for the platform-specific intrinsic. So encoding this in type is completely redundant; you see that in NEON (same problem in C). SSE does this only between fp/int boundary which is less problematic in practice.
If your function names do not encode this, you do need the type. However if you need platform-specific intrinsics then you have redundancy again.
=> More informations about this toot | More toots from zeux@mastodon.gamedev.place
@djee I would personally advocate for explicit names regardless I think (even for portable SIMD). For example, and the post this is from goes into one instance of that, not all operations are natively supported by all targets; simd_gt is fine for signed ints on SSE but bad perf for unsigned. IMO it is easier to audit the code when types are explicit, and various transmutes are very common in integer SIMD code so the hypothetical ideal of "just type safe basic ops" doesn't play out.
=> More informations about this toot | More toots from zeux@mastodon.gamedev.place
@zeux Ok thanks for the explanation. Indeed the fact several operations are either more expensive or not available at all in some variants makes casting quite common. But as you said, this doesn't need to be encoded in the type. Makes sense.
=> More informations about this toot | More toots from djee@mastodon.gamedev.place This content has been proxied by September (ba2dc).Proxy Information
text/gemini