dabreegster
commented
3 years ago There are a few other ideas / considerations...
- The core UI event loop with
winitdoes all event handling and drawing on one thread. Should we move heavy operations to another? I haven't seen best practices established in other winit projects. (It's also been a challenge to make async stuff work with winit; seemap_gui/src/load.rs) - Almost everything needs to work on both native and wasm, where threads are unavailable. I haven't played around with web workers yet; maybe things are getting easier there.
As far as I can tell, abstreet currently only uses one core.
There's a few places we use timer.parallelize, which uses scoped_threadpool underneath. But otherwise true.
Parallelizing agents would be non-trivial, and probably not worth it.
Yuuup. It's a cool algorithmic problem, though. I've come across some academic papers talking about running discrete-event traffic simulations in parallel. If you can partition the map carefully and have long roads along the boundary of two different execution contexts, then both machines/threads can simulate this overlap road. The amount of simulation time they could drift apart is bounded by the time it takes an agent to cross that road. Fun to think about, highly unlikely we'll ever try something like this.
prebaking should be easy to parallelize
That'd be a good one to include. The barrier here IMO is logging / UI. For prebaking it's maybe not as necessary to easily see the logs per map, but I'd like to figure out a general strategy for doing this. Prefixing each line with [map-name] might do the trick here. It'd be really nice to have some kind of floating progress bar showing the number of maps finished, with logs beneath it, but that means finding a console UI library.
vks
As far as I can tell, abstreet currently only uses one core. Parallelizing agents would be non-trivial, and probably not worth it. However, for example the prebaking should be easy to parallelize, so that several maps can be simulated at the same time.