-
-
Notifications
You must be signed in to change notification settings - Fork 331
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
Optimize scheduler #54
Comments
How did you profile the code? I would like to try some things and see the change |
The slight complication is that the simulation is still sensitive, so for example, if the a new priority queue slightly reorders commands with the same timestamp, then hypothetically gridlock could occur on these currently stable maps. If that happens, performance grinds to a halt, so it's obvious. :) On my machine, prebaking takes about 5 minutes total, so it's fairly obvious when a new problem is introduced. |
affect determistic simulation, but yields a crazy speedup. #54 - 8 hours of downtown: 122s to 102s!!! - prebake: 181s to 160s
@vks, based on your other repos (thanks for all your work on |
I'm not really an expert on data structures, but I would be interested having a look at performance! So thanks for marking me. |
This crate looks promising: priority-queue It is built with an ordered hash map (indexmap). We could try to swap it in and see whether it improves performance. |
This looks like it might work. I'm not sure if the Item struct should be the It would be nice if we could do away with having both a priority queue and a separate CommandType -> Command lookup. The queue's item must implement That's why the whole |
It is deterministic, and independent of the hasher: garro95/priority-queue#29 |
@vks, I might actually try tackling this soon. I just wanted to make sure I'm not repeating something you've started or were really keen to do |
Thanks for the heads up! I don't have plans to work on this soon, so please feel free to go ahead. |
implementation gets simpler, but the net performance doesn't improve. #54
Well that was anti-climactic. I tried two different approaches for using I measured total time to run the small montlake simulation. I repeated each run 3 times and tried to avoid other heavy activity while the test ran. There's a fair bit of noise repeating runs, but consistently, all of the variations using the new priority queue were slower than the current use of BinaryHeap. So, failed experiment, sadly. :( But it could be eventually worth trying out other priority queue implementations. |
Do we know what priority queue operation is costing the most in this case? |
Profiling reveals https://github.com/dabreegster/abstreet/blob/master/sim/src/scheduler.rs as a hot spot, which makes sense. Anybody have ideas to speed it up? It's a priority queue with updateable priorities. There are lots of alternatives to std::collections::BinaryHeap, but I think I had trouble finding one that was deterministic (given the same inputs, simulations must run exactly the same).
I squeezed running a huge scenario from 71s to 63s using 7a0b9cd. I bet there's more possible.
The text was updated successfully, but these errors were encountered: