You can get a rough comparison of CPU performance by browsing the SPEC CPU2006 benchmarks. Specifically, the results in SPECfp2006 should help you compare single-threaded performance (simplex and root node of a MIP). Parallel performance (for barrier and MIP tree exploration) is highly problem dependent. SPECfp_rate2006 is useful to estimate the best-case parallel performance, but actual testing is required to determine real-world performance. As for memory, you should have enough memory so that the model can be solved in physical memory - without using virtual memory. Based on models that customers share with Gurobi, 32GB is sufficient for most models, and many can be solved with much less memory. Apart from cost considerations, having too much memory is no problem, while having too little can create severe problems for performance. Finally, if you are solving a MIP where you need to explore a large number of nodes, you can save memory by setting the NodefileStart parameter; this is much more efficient than relying on virtual memory.
Articles in this section
- Which R versions are supported by Gurobi?
- How to handle a NoClassDefFoundError?
- How to handle a BadImageFormatException?
- How do I use Gurobi with PyCharm?
- How does Gurobi perform on different computer hardware?
- What can be done to avoid an out-of-memory condition?
- Can I use Python 3.x on macOS?
- Error message: The application has failed to start because its side-by-side configuration is incorrect.
- A Java program gives out-of-memory errors, yet the same model can be solved as an LP or MPS file.
- How do I configure a new Gurobi C++ project with Microsoft Visual Studio 2017?