4 ms·
As for the performance aspect, these kinds of simulations (typically using fixed time steps and with per-agent decision-making) are a natural fit for many-core
by frankling_ 8y ago
As for the performance aspect, these kinds of simulations (typically using fixed time steps and with per-agent decision-making) are a natural fit for many-core devices. We recently did a survey on that subject [1]. There is a lot of work being done along these lines right now.
Some groups are also trying to target sequential, parallel and, say, GPU execution from the same model specification language, which could actually help with the usability of running such simulations in practice.
[1] https://arxiv.org/abs/1807.01014 https://arxiv.org/abs/1807.01014
- veddox 8y agoThis is interesting. We've been thinking quite a bit about parallelising our model, but haven't managed it yet. The problem is that although our agents are mostly independent of each other, they all depend on the shared state of the world (and modify this, too). Therefore, if we were to use a multiprocessing setup, we would have to be able to lock the world object when a process is writing to it; and furthermore, find a way to pass it around in memory so that all processes have read access to it. While we know that it should be technically doable, the latency overhead of the latter has proven prohibitively high.
- frankling_ 8y agoYeah, for some models, especially small-scale ones, it can be hard to get a performance gain. There are actually ways of avoiding the locking, e.g., by staging the desired actions and then carrying them out afterwards, resolving conflicts as needed. We actually have a paper on this as well, but I'm going to stop pushing my research at this point ;)