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

AStar/GuidedSearch benchmark issues. #4

Open
smarr opened this issue Sep 29, 2015 · 1 comment
Open

AStar/GuidedSearch benchmark issues. #4

smarr opened this issue Sep 29, 2015 · 1 comment

Comments

@smarr
Copy link

smarr commented Sep 29, 2015

The allNodes field is for some reason a HashMap. However, it seems to be densely populated so, I would kind of assume it should be an array. Any specific reason why it is a HashMap?

The busyWait function uses Math.random() and thus, sequentializes all workers on the AtomicLong seed of the shared Random object.

@smarr
Copy link
Author

smarr commented Sep 29, 2015

Implementing this benchmark faithfully with a language that guarantees isolation between actors is also hard. I am not sure how to do it. Especially not preserving the parallelism.

At each step, the GridNodes are read and mutated. Interestingly, mutation is probably idempotent, but, an actor needs to know whether it succeeded to know whether it should continue working on the neighbor, or to check whether it is done.

I have no good idea how to realize this in a pure event-loop language without sequentializing all operations. There needs to be either a strategy of distributing the grid nodes between multiple actors, or a mechanism that allows for instance idempotent racy mutation. Either way, this seems like a huge change to the benchmark.

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

1 participant