Description
While we have discussed what "portable" means in the past and have something of an image of that, at least partly based on our preexisting design constraints informing us heavily on what "portability" means, it seems prudent to define it in as formal-ish a sense as possible... though somewhat more like elaborating tradeoffs. And where SIMD is concerned, "portability" also means "with performance".
This has been directly raised (and thus relevant side-conversation also appears in) at least these issues:
- Shl and Shr implementations should accept a (polymorphic?) scalar argument rather than a vector #225
It also is arguably the source of the entire now-infamous mask operation design challenge. This will be essential to our RFC, but is also important for user concerns, since some will have specific ideas already in mind.
Excerpted from Zulip conversation:
- workingjubilee:
I think portable-simd#225 has posed a fair question in that we want to like, kinda semi-formally define what we mean by "portable".
Or at least, explain all our constraints in a as concise a manner as possible. - calebzulawski:
Agreed.
We should probably formalize it somewhere, though I assume our answer is going to be something like "can be implemented reasonably on nearly all architectures and offers good performance for that particular operation as far as that architecture goes"
I think the point you made nails it, that just because there's an instruction it's not necessarily fast anyway - programmerjake:
i'd pick something like "provide all reasonable primitive operations that a simd programmer would want in a mostly architecture independent way"
- calebzulawski:
Yep. I think we should also specify that for some architectures there might be entirely different ways to organize algorithms that avoid particular operations, and that's considered an optimization, not a flaw of portability
"it will do exactly what you tell it, as best as it can" - miguelraz:
So, a compiler.