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

Get rid of global variables #30

Open
swapneils opened this issue Jun 11, 2023 · 4 comments
Open

Get rid of global variables #30

swapneils opened this issue Jun 11, 2023 · 4 comments

Comments

@swapneils
Copy link

swapneils commented Jun 11, 2023

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?

@rpgoldman
Copy link

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.

@swapneils
Copy link
Author

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 screamer::*trail* to a new array, but manually rebinding a non-exported symbol feels like an ugly hack.

(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?)

@rpgoldman
Copy link

(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...

@nikodemus
Copy link
Owner

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.

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

3 participants