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

Parallelize MULTISHOT #108

Open
stylewarning opened this issue Jun 3, 2019 · 6 comments
Open

Parallelize MULTISHOT #108

stylewarning opened this issue Jun 3, 2019 · 6 comments
Assignees
Labels
enhancement New feature or request

Comments

@stylewarning
Copy link
Member

stylewarning commented Jun 3, 2019

Right now, MULTISHOT experiments under the parallelization limit only use a single core. We could use this as an opportunity to do multicore computations. The general flow would be:

  1. Is the computation under the parallelization limit? If no, perform single-threaded.
  2. Does the computation exceed the number of shots necessary to parallelize? If no, perform single-threaded.
  3. Parallelize across threads, each modifying thread-local state, then combine state.

This was requested by the Slack community.

@stylewarning stylewarning self-assigned this Jun 3, 2019
@stylewarning stylewarning added the enhancement New feature or request label Jun 3, 2019
@jlapeyre
Copy link
Contributor

jlapeyre commented Jun 3, 2019

I can do this.
EDIT: I see you have "self-assigned". I'm happy to do it unless you want to do it yourself.

@stylewarning
Copy link
Member Author

@jlapeyre I've at least started it. I'll push my branch and maybe you can critique/discuss if it's in the right direction?

@stylewarning
Copy link
Member Author

By the way, I only tested this behavior on macOS.

@jlapeyre
Copy link
Contributor

jlapeyre commented Jun 4, 2019

I'll try it this afternoon (was preparing and giving TTS today) on my linux laptop.

@jlapeyre
Copy link
Contributor

jlapeyre commented Jun 5, 2019

I checked out this branch. grepping shows that I indeed have your edits. I then do make clean-cache and make clean (I needed them both in order for the build to succeed). Then make qvm. The resulting qvm binary is identical to the binary built from the master branch. This doesn't make sense. I'll look at it again tomorrow.
EDIT: I fixed this problem by uninstalling a quicklisp-installed version of qvm that was competing with the cloned repo.

@jlapeyre
Copy link
Contributor

jlapeyre commented Jun 5, 2019

By the way, I only tested this behavior on macOS.

Can you give an example invoking qvm from the command line that will test this feature ?

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

Successfully merging a pull request may close this issue.

2 participants