-
Notifications
You must be signed in to change notification settings - Fork 291
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
Make ndarray-parallel a direct optional part of ndarray? #551
Comments
It would be great to have all methods that could benefit from parallelization to use it out of the box with |
Sure, I wouldn't use it if I couldn't deselect features I wasn't using. clean build of ndarray: 22 sec on a hot slow laptop |
If you're thinking of default parallelization of a method like |
|
Once upon a time in nightly you could specialize on presence or absence of Send/Sync and parallelize transparently if allowed. Not even sure that's a good idea, but it's pretty cool. At the moment we don't know when/if specialization will arrive though. |
We could approach the problem from a different perspective: If the |
It doesn't match the "feature flags are purely additive" rule which we see that we need as soon as there is more than one crate that uses ndarray in the currently compiling project. What happens is that one crate can pull in ParMappable without the other crate being ready for it. This is a rule for cargo feature flags in general. |
Let's work on making the parallel methods visible. I think that in general we don't want this to happen automatically, the users will know which operations to parallelize. That said there could certainly be ways we can make it easier to opt in to this -- even a newtype, a wrapper type? ndarray-parallel is also missing some important operations, most notably |
Hrm, the LinalgScalar trait doesn't have the foresight of requiring |
Rayon is now 1.0 and the plumbing parts we use to implement parallel iterators are as stable as the rest of the crate. See that written in this PR: rayon-rs/rayon#469
Rayon plumbing docs: https://docs.rs/rayon/*/rayon/iter/plumbing/index.html
This makes it viable to make rayon a direct dependency of ndarray, presumably an optional one, and it lets us simplify its usage.
The text was updated successfully, but these errors were encountered: