Informations on MDBNCH, a molecular dynamics benchmark

Table of contents

1. Molecular dynamics and MDBNCH

1.1 What is molecular dynamics?

Molecular dynamics is a standard computational technique used in condensed matter physics, materials science, chemistry, and other fields, consisting of following the temporal evolution of a system of N particles, interacting with each other by means of a certain law. In classical molecular dynamics, the evolution is based on the Newton's law, F=ma, and the forces are obtained as gradients of a certain potential which is function of all the particle coordinates.

Use of periodic boundary conditions is customary to simulate infinite systems. Thermodynamic variables such as pressure and temperature can be defined (even if they will fluctuate a bit because the number of particles is finite), and the technique can be used to study a large number of phenomena including phase transitions, liquid structure, defects in solids (vacancies, dislocations, grain boundaries, etc), amorphous materials, surfaces, clusters.

1.2 The nature of molecular dynamics codes

Typically, interactions are short range: two particles do not interact if their distance is larger than a certain cutoff distance (this does not mean that interactions should be pairwise: there can be many-body terms, but they are also typically local in space). And of course, particles can move around in the system. So an efficient molecular dynamics code must:

• deal efficiently with the locality of interactions, that is, avoid running over all pairs just to find out that the majority of them were too far from each other to be interacting. This is usually accomplished by introducing neighbor lists, or by performing some kind of filtering on the particle pairs.
• deal with the fact that the topology changes as times goes on, so that the above lists have to be kept updated dynamically.

As a result of these points, codes using smart algorithms often end up accessing data from memory in a rather irregular way. One rather typical example could be a double do-loop of the type

	DO I=1,N
	    DO JLST=MRKR1(I),MRKR2(I)
	       J=LIST(JLST)
	          I and J are neighbors, compute their distance,
	          compute energies and forces FIJ, etc ...
               FORCEZ(I) = FORCEZ(I) + FZIJ
               FORCEZ(J) = FORCEZ(J) - FZIJ
	    ENDDO
	ENDDO

Not that the situation is much better on traditional vector supercomputers. The above inner loop may be hard to vectorize (at the very least we have to tell the compiler that all J will be different and no one of them will be equal to I), and it is typically a short loop anyway.

1.3 History of MDBNCH

1.4 What does MDBNCH do?

1.5 What to do with MDBNCH results

MDBNCH results provide information about the speed of machines in classical molecular dynamics calculations using short-range potentials and neighbor lists. More generally, they may give you a feeling about the behavior of systems on codes which are relatively small, but tend to access memory in a quite irregular way, probably causing many cache misses on recent RISC architectures.

Performance on vector computers is also quite poor, as inner loops may be short and/or not vectorizable (see example above). There are vectorizable codes which do the same job and run much faster on vector machines, but they usually run slower on workstations, and such codes are not included in MDBNCH anyway. Just keep in mind that molecular dynamics production codes on vector computers are somewhat faster than what suggested by MDBNCH results.

In summary, MDBNCH is coded by striving for algorithmic efficiency for the problem at hand, rather than for computational efficiency. For this reason, it is almost certainly unable to bring any machine close to its peak theoretical limit. In this sense, MDBNCH provides for a different perspective with respect to, say, Linpack, and it should be considered as a real life benchmark.

1.6 What NOT to do with MDBNCH results

Do not use these results to draw general conclusions about machine speeds. Different applications are known to yield very different speed ratios between different machines. If you are evaluating a set of machines for general purpose computing, MDBNCH performance may be one indicator you may wish to consider, but by no means the only one. In particular, codes which access memory in a regular pattern, such as for instance most electronic structure codes and linear-algebra based codes, will not be represented at all by MDBNCH, and you should look elsewhere to get performance indicators for this kind of codes. The same can be said for codes dominated by integer arithmetics.

2. Practical guide for getting timing results

2.1 Getting the source

2.2 Compiling

First of all, note that MDBNCH requires 64-bit floating point arithmetic, and that the code declares all floats to be DOUBLE PRECISION and constants are also explicitly written as 3.D0. This means that on practically all the modern RISC machines you do not have to use any particular compiler option, as DOUBLE PRECISION means REAL*8, i.e. 64-bit. However, you must be careful on machines with a wide word, most typically Crays, where the compiler would produce very slow code using 128-bit arithmetics. On these systems make sure to specify a compiler option called disable precision, or something similar, to avoid this problem.

Hunting for the best compiler options is up to you, but here are a few additional comments:

• if are really in a hurry, use the standard optimization option of your compiler, typically -O.
• if you have more time, explore the various optimization levels that are usually provided, such as -O1, -O2, -O3 ....
• if a machine similar to yours already appears in the results table, look at what options where used to get the best times, and try those.
• your machine may have a Fortran preprocessor available. The preprocessor is usually activated by a compilation switch. Usually MDBNCH does not get much benefit from preprocessors, and in some case things may even be slower, but it may be worth a try. Also note that compilation time may increase enormously, as anybody who ever tried the HP's +OP4 option on this code will confirm without hesitation.
• an attentive reading of the compiler manual page may reveal to be a fruitful activity. Little gems like IBM's -qhsflt were discovered in this way.
• MDBNCH works happily with either static or stack allocation, and this issue may be worth exploring. The default allocation scheme depends on the compiler. The best speed is usually reached by using stack allocation, but this is not a rule.
• ANSI error flagging shouldn't bring in any warning message, as I made an attempt to conform strictly to Fortran 77. If it does on your machine, I would appreciate hearing about it.

There is no point in trying automatic parallelization on machines with multiple CPUs. This code is not suitable for parallelization and no automatic tool can do anything significantly useful with it in this area. MDBNCH is a scalar benchmark.

2.3 Running and measuring the execution time

MDBNCH occupies a quantity of memory of the order of 8MB when running. The execution time is of the order of one minute on a typical 1994 workstation.

There are no input files. Just run the executable, redirecting the output on a file. On a Unix machine, for example,

Even if the CPU time is returned, it is good practice to run the benchmark on a lightly loaded or possibly empty machine, as it is known that the CPU time of a run is slightly dependent on the system load. If this is not feasible at your site, data for a loaded machine are better than no data at all.

The `official' time is the last time printed on the standard output. The line containing it may look like

Even if the time is printed with a microsecond precision, very few machines provide timing routines with this kind of resolution. In fact, the typical resolution in a Unix machine may be 10 milliseconds, as in the example above. For pratical purposes, this is actually more than enough. In fact, you will find that repeating a run may yield a different CPU time, with fluctuations of the order of 1%. These fluctuations may be due to changes in the system load: the processor has to do extra work to switch between different tasks, and this extra work is always charged to somebody. For this reason I recommend to run on a lightly loaded system, and always run at least twice each case. If you have many runs to choose from, the time to report is the best time with a given set of compilation options.

Due to the fluctuations discussed above, the 10 milliseconds resolution discussed above is more than adequate with the current machine speed. After you have taken the time, round it (using nearest digit rounding) so that there are 3 decimal digits. That is, round to the second if the time was larger than 100 s; to the tenth of second if the time was between 10 and 100 s; to the hundredth of second if the time was between 1 and 10 s.

2.4 Verifying the output

In order for the timing to be validated, one should make sure that the program did the right thing. Surprises often occur, particularly when pushing the limits with preprocessors and optimizers. The easy way to verify the output is to send it to me and I will have a look. Or you can do it by yourself (thanks!), using the following guidelines.

2.5 Reporting data