Search code examples
javarepast-simphony

Low CPU and Core Usage during Repast Simphony Java Run

I am building an ABM in Repast 2.7 and we're getting to the point in the project where we are being delivered the larger production datasets for informing our model.

I'm noticing on my 32 core workstation that the executable is only using 3-12 cores; and the average cpu consumption is steady at about 5.5%. It seems as though it should be using either more cores; or maxing out the cores that it is using. I realize this is likely naïve speculation.

Runtime.getRuntime().availableProcessors()

Reports 32 cores are available.

I'm interested in knowing if and how to configure my project to utilize more resources. I realize that the HPC version is available; however I'd first like to see if I can get the simulation to use all of the available resources of this machine before pursuing another rewrite (we came to Repast from AnyLogic.)

Tick is currently taking around 60 seconds on a dataset that's only 1/30th the size of the final version and we're going to be doing 10s of thousands of iterations over approximately 100 comparative runs.

Thanks for any ideas!

Solution

  • Repast doesn't provide automatic parallelization of the model code. The Repast scheduler and agent code runs in a single thread, and the displays will run in separate threads, so really only one CPU is doing all of the work of the model logic. To improve the model performance, we recommend two important steps:

    1. Profile the code to determine which parts are computational bottlenecks. Yourkit is a good Java profiler I've used in the past. Profiling can help determine if parts of the code are inefficient and/or called very frequently. Small improvements to frequently used code can speed up a model significantly.

    2. Parallelize your model by explicitly using Java thread pools. If your agent logic is dependent on the state of the agent and environment only during the previous step, this is a very straightforward process. The Repast "Flock" demo is a simple example of this concept. In short, you can create an agent "manager" that is scheduled for every tick, and the manager will divide up the agents by the number of CPUs and have each of the batches of agents execute in parallel.