Skip to content
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

Should parallelization be handled upstream? #174

Open
arokem opened this issue Apr 16, 2024 · 4 comments
Open

Should parallelization be handled upstream? #174

arokem opened this issue Apr 16, 2024 · 4 comments

Comments

@arokem
Copy link
Collaborator

arokem commented Apr 16, 2024

This is a suggestion to simplify this:

with Parallel(n_jobs=n_jobs) as executor:

We are in the midst of some work to parallelize model fitting in DIPY itself: dipy/dipy#2593, which would benefit all downstream uses of these models, including here. I wonder whether we should aim to use these methods as implemented there (e.g., by passing through parallelization kwargs to DIPY's multi-voxel parallelization methods), instead of implementing that separately here.

@oesteban
Copy link
Member

Yes :)

@arokem
Copy link
Collaborator Author

arokem commented Apr 18, 2024

OK - well - let's keep this open if that's fine by you, so that we remember to refactor that code once the parallelization code is incorporated into DIPY (hopefully in the upcoming release).

@arokem
Copy link
Collaborator Author

arokem commented Jun 30, 2024

Good news! dipy/dipy#2593 got merged 😄

@arokem arokem closed this as completed Jun 30, 2024
@arokem arokem reopened this Jun 30, 2024
@arokem
Copy link
Collaborator Author

arokem commented Jun 30, 2024

Actually, reopening, because we still need to remove the parallelization code from here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants