Dear all,
I have made some timing runs to get a more qualitative idea of the overhead involved in using OpenKIM. The data are in the attached file. I have run MD simulations with 500,000 atoms per CPU core, i.e. more atoms in larger simulations. I have made two sets of data, one with the Intel compilers and one with the GNU compilers.
Major observation:
* The real performance killer is choosing the wrong kind of neighbor list. With full lists, up to a factor of two is lost in performance, due to the model not being able to re-use terms in the force expression. This is so bad that I am considering if it was a good idea to support the full neighbor lists at all for this particular model. The model puts them lower on the list than the _H versions, but as I understand the documentation it is the simulators ranking of the neighbor lists that is used during matching.
I suggest that all simulators include a way for the user to control which neighbor list is used, and that users before performance-critical simulations take time to investigate how the model they intend to use performs with the different neighbor list models.
Minor observations:
* Asap runs much faster with the Intel compiler than with the GNU compiler. That was already known and is of marginal interest to the OpenKIM community unless it is a general trend with other models, too.
* It looks like there is a relatively large KIM overhead when compiling with the Intel compiler. This is, however, not due to OpenKIM overhead but appears to be due to the code taking a generic code path instead of the path optimized for this particular cpu. This is with Intel compilers version 2013.1.117. With version 2015.1.133 the difference is less pronounced, unfortunately due to the native code being slower.
* I should look into why EMT is so much slower for a binary alloy (CuAu) than for the pure metal (Cu or Au, the latter data are not included as they are indistinguisable from Cu). It should be slightly slower, and the single element case is special-cased in the code, but almost a factor two is unexpected.
Merry Christmas to you all,
Jakob
OpenKIM_Performance.txt (2.2 KB)