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

[feature request] support parallelism facilities by default #135

Open
lm1909 opened this issue Jun 24, 2021 · 1 comment
Open

[feature request] support parallelism facilities by default #135

lm1909 opened this issue Jun 24, 2021 · 1 comment

Comments

@lm1909
Copy link

lm1909 commented Jun 24, 2021

It would be great if QuESTlink would support the Mathematica parallelisation facilities (e.g. ParallelTable etc.) by default. Currently, this results in errors of e.g. the form
questlinkparallelism

I think this would necessitate that each kernel has its own QuEST backend, I hacked a solution together:

Parallel`Developer`$InitCode =
 Hold[
  Import["path/QuESTlink.m"];CreateLocalQuESTEnv["path/quest_link"];
 ]

via the solution proposed in this stackexchange answer. However, as mentioned there, $InitCode is undocumented and thus probably not suitable for implementing in QuESTlink directly, though the answerer mentions it appears to be quite stable.

I feel this would be very useful though, e.g. I often ran an algorithm using QuESTlink repeatedly with different parameters for comparison, and it was very comfortable to use e.g. ParallelTable for that.

@TysonRayJones
Copy link
Member

Hi there,
Please forgive the absolutely incredible delay!
This is a nice idea, although there isn't much more one can do besides setting ParallelDeveloper$InitCode as you do above (except worse/hackier things inside each Parallel function). Further, it seems parallelisation of this granularity is only worthwhile for very small systems when the exponentially growing costs of simulating a single statevector at a time haven't yet dominated. For larger systems, it is better to dedicate all threads to modify the same statevector (achieving better cache behaviour and minimising context switching) at one time. I think your solution for unusually small systems is the only way to go.

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