Skip to content

impl core::ops for core::simd #5

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
13 tasks done
Lokathor opened this issue Sep 27, 2020 · 5 comments · Fixed by #10
Closed
13 tasks done

impl core::ops for core::simd #5

Lokathor opened this issue Sep 27, 2020 · 5 comments · Fixed by #10
Labels
A-simd Area: SIMD. Put this on tracking issues to help with cross-repo issue organization C-tracking-issue Ongoing issue with checkboxes for partial progress and such

Comments

@Lokathor
Copy link
Contributor

Lokathor commented Sep 27, 2020

  • Add / AddAssign
  • BitAnd / BitAndAssign
  • BitOr / BitOrAssign
  • BitXor / BitXorAssign
  • Div / DivAssign
  • Index/IndexMut
  • Mul / MulAssign
  • Neg
  • Not
  • Rem / RemAssign
  • Shl / ShlAssign
  • Shr / ShrAssign
  • Sub / SubAssign

Most of these are self-explanitory.

  • Generally, vector op scalar should "auto-splat" the scalar value and then perform the op between the two vectors. This is just good quality of life / ergonomics.
  • I'd like if all types support bit ops (including Not), even though normally f32 / f64 don't support bit ops. I consider the lack of bit ops on the floating primitives to be a "not cool" part of core.
@Lokathor Lokathor added C-tracking-issue Ongoing issue with checkboxes for partial progress and such A-simd Area: SIMD. Put this on tracking issues to help with cross-repo issue organization labels Sep 27, 2020
@calebzulawski
Copy link
Member

It needs a rebase, but I have started on this in the feature/ops branch.

@calebzulawski
Copy link
Member

Also, I think we may want to consider implementing Index/IndexMut as well, which can just delegate to a slice.

@Lokathor
Copy link
Contributor Author

I feel like Index/IndexMut are enough of an accidental performance footgun that you should be forced to call AsRef and get a slice/array reference and index that way.

But i've said that before and people keep not thinking it's a big enough deal.

So... I mean I guess.

@calebzulawski
Copy link
Member

calebzulawski commented Sep 27, 2020

Ignoring SIMD specifics, from the Rust point of view, I think things that implement AsRef<[T]> generally implement either Deref or Index, since AsRef means "no cost". Maybe it's inappropriate to implement AsRef in the first place? It's really philosophical rather than technical so maybe we should discuss this at some point.

Edit: I think we're going to need to adopt a general policy of how easy it should be to write slow code. I think for the sake of portability and convenience we're going to need to allow it, which might include things like Index. Another example is implementing Div for integer vectors, which definitely won't be performant on x86 since it'll turn into idiv for each lane.

@Lokathor
Copy link
Contributor Author

Yeah, the AsRef is "no cost" in the case of SIMD in the sense that, once you have &self on a vector, you can turn that into &[f32] "for free" (well, as cheaply as an array dereferencing to a slice, at least).

I guess we'll just allow slow ops and then... tell people somewhere, uh, "i know we let you do it but it's for emergencies only".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-simd Area: SIMD. Put this on tracking issues to help with cross-repo issue organization C-tracking-issue Ongoing issue with checkboxes for partial progress and such
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants