CPU cores are the main resources that determine Gurobi performance, as they deliver the computational power for optimizing your models. While many optimization models benefit from parallelism (allocating more than one core to a single model), the exact relationship between the number of cores and the resulting runtime can only be determined by benchmarking. You can use the following procedure to get a rough idea:
- Select a few representative models (e.g., your model with different input data sets)
- Decide which numbers of threads you wish to test (we typically consider powers of two, e.g. 1, 2, 4, 8 and 16)
- Ensure you have a machine available with the maximum number of cores you wish to test. Use this machine for all experiments.
- Decide how many runs you wish to do with each model and number of cores. Runtime will differ across runs (both for the same model and between different models), which we call performance variability. By doing multiple runs, we get a better understanding of this variability. Each run for the same model and cores would be started using a different random seed, so we learn how Gurobi behaves when choosing a slightly different solution path.
- Now run all combinations of model, #cores (using the Threads parameter) and random seed (using the Seed parameter), one after another.
- Make sure to measure pure solve time, as opposed to the time required for retrieving data, constructing the model through our API and processing the solution when the solver has completed the job. At the end of every Gurobi log you will read a line stating this runtime (e.g. “Explored N nodes (…) in N seconds (N work units)” for MIP models, “Solved in 20370 iterations and 5.75 seconds” for LP models). You can learn more about these and other statistics in our documentation. Note that there are other tools available to support you in measuring algorithmic performance on a larger scale. You may want to use grblogtools to parse the logfiles and summarize your results.
The end result of this analysis will be a statement like "My model runs in X seconds using Y cores on average, on a Z-type CPU". This understanding will help you size your Gurobi architecture.
Comments
0 comments
Article is closed for comments.