-
Notifications
You must be signed in to change notification settings - Fork 31
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
Get rid of global variables #30
Comments
Are you trying to conduct multiple screamer searches concurrently or are you trying to make it possible for non-deterministic execution to explore multiple assignments concurrently? The latter would be a very large ask. |
I'm trying to have multiple screamer searches concurrently, to allow parallelizing codebases with screamer code in them without needing to fix every non-deterministic block. Currently I'm making do with a macro for let-binding (P.S.: I'm guessing parallel assignment exploration would require a complete rewrite of the backtracking mechanism (maybe using the recursion stack for state) to allow spinning off thread-local trails?) |
Yes, and there would have to be some kind of supervisor that would manage the partial solutions. Such a supervisor could easily become a bottleneck. Search is less easy to parallelize than one would like... |
Hi, just letting you know that I'm not actively maintaining Screamer these days. If someone wants to pick it up and run, they should feel free to do so. |
Currently we cannot execute screamer code (or at least screamer code using variables) in parallel, such as via the
lparallel
library. I suspect the main culprit for this is*trail*
(which, to my limited understanding, manages some aspect of choice-point tracking), or more generally the use of non-local variables to handle backtracking (and constraints?), but there may be some other factors involved.Considering the strong relationship between non-determinism and ease of parallelization (for instance, moving some choice points out of screamer code to parallelize exploration of possible values), perhaps we should replace any global variables with local counterparts implemented as part of the macroexpansion of e.g.
one-value
, to allow users this flexibility.I'll look into the code if I get a chance, to locate globals and see how difficult they are to restructure as locally-defined dynamic variables, or perhaps even convert to lexical usage (though the latter seems ridiculously difficult at first thought).
EDIT: All this really seems to require is lexically binding trail in the one-value and all-values macros. I'm not entirely sure whether or not this is a good idea performance-wise, though, not having much experience with low-level CL. Thoughts?
The text was updated successfully, but these errors were encountered: