Skip to content

Define "portable" and elaborate design constraints #227

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
workingjubilee opened this issue Jan 17, 2022 · 0 comments · Fixed by #359
Closed

Define "portable" and elaborate design constraints #227

workingjubilee opened this issue Jan 17, 2022 · 0 comments · Fixed by #359
Labels
C-feature-request Category: a feature request, i.e. not implemented / a PR E-needs-docs Needs documentation added.

Comments

@workingjubilee
Copy link
Member

workingjubilee commented Jan 17, 2022

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:

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.

@workingjubilee workingjubilee added E-needs-docs Needs documentation added. C-feature-request Category: a feature request, i.e. not implemented / a PR labels Jan 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-feature-request Category: a feature request, i.e. not implemented / a PR E-needs-docs Needs documentation added.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant