Parallelize cycle finding #77
Open
Comments
Hi @ZevEisenberg, |
Related: #79 I think there are some quick improvements that could be made to |
@dabbott No doubt you're right! Good call. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Would it be possible to speed up
detectCycles
anddetectCyclesAsEdges
by making them run parts of the search in parallel? I don't know whether the algorithm is suitable for parallelization, but it could be worth looking into.Background: I've been modifying my juggling code to deal with throwing multiple objects at the same time, and the state graphs for this technique are way bigger than for throwing a single object at once. For 3 balls, for a maximum throw height of 6, there are 110,552 cycles in the graph. I don't know how many there are for a maximum throw height of 7 because I haven't been able to run the code for long enough yet to find out.
For graphs this large, memory usage is also a concern. My current test run searching for a max throw height of 7 is up over 1 GB used.
(Much of this is academic. I don't know if I have a real-world use case for searching for cycles on graphs this large, at least not quickly. If my app needs to use them, I'll probably generate them once and bake them into the app.)
The text was updated successfully, but these errors were encountered: