GMX-NONBONDED-BENCHMARK(1)

โœจ NAME โœจ

gmx-nonbonded-benchmark โ€” a benchmarking tool for the non-bonded pair kernels. it's giving "I stress-test your CPU so you don't have to" ๐Ÿ’…


๐Ÿฆ‹ SYNOPSIS ๐Ÿฆ‹

gmx nonbonded-benchmark [-o [<.csv>]] [-size <int>] [-nt <int>]
             [-simd <enum>] [-coulomb <enum>]
             [-interactmodifier <enum>] [-[no]table]
             [-combrule <enum>] [-[no]halflj] [-[no]energy]
             [-[no]all] [-cutoff <real>] [-iter <int>]
             [-warmup <int>] [-[no]cycles] [-[no]time]

๐ŸŒธ DESCRIPTION ๐ŸŒธ

okay bestie, sit down, because gmx nonbonded-benchmark is lowkey the main character of performance testing. she runs benchmarks for one or more of the so-called Nbnxm non-bonded pair kernels. โœจ

and why do we care?? because the non-bonded pair kernels are the most compute intensive part of MD simulations and usually comprise 60 to 90 percent of the runtime. yeah. that much. ๐Ÿ˜ญ so obviously they're highly optimized, and there are several different setups available to compute the same physical interactions. plus there are different physical treatments of Coulomb interactions, and optimizations for atoms that don't have Lennard-Jones interactions. ๐Ÿซถ

there are also different physical treatments of Lennard-Jones interactions, but ngl only a plain cut-off is supported in this tool, because that is by far the most common treatment. and finally โ€” while force output is always necessary, energy output is only required at certain steps. and when you add it all up? there are 36 relevant combinations of options. and the combinations double to 72 when two different SIMD setups are supported. ๐Ÿคฏ you can run all of these with a single invocation using the -all option. iconic behavior, honestly.

the behavior of each kernel is affected by caching behavior, which is determined by the hardware used together with the system size and the cut-off radius. the larger the number of atoms per thread, the more L1 cache is needed to avoid L1 cache misses. the cut-off radius mainly affects the data reuse: a larger cut-off results in more data reuse and makes the kernel less sensitive to cache misses. โœจ

OpenMP parallelization is used to utilize multiple hardware threads within a compute node. in these benchmarks there is no interaction between threads, apart from starting and closing a single OpenMP parallel region per iteration. additionally, threads interact through sharing and evicting data from shared caches. the number of threads to use is set with the -nt option. thread affinity is important โ€” especially with SMT and shared caches. affinities can be set through the OpenMP library using the GOMP_CPU_AFFINITY environment variable. ๐Ÿ‘‘

the benchmark tool times one or more kernels by running them repeatedly for a number of iterations set by the -iter option. an initial kernel call is done to avoid additional initial cache misses (warmup is real and it matters, bestie ๐Ÿงš). times are recording in cycles read from efficient, high accuracy counters in the CPU. note that these often do not correspond to actual clock cycles. ๐Ÿ’€ for each kernel, the tool reports the total number of cycles, cycles per iteration, and (total and useful) pair interactions per cycle.

because a cluster pair list is used instead of an atom pair list, interactions are also computed for some atom pairs that are beyond the cut-off distance. these pairs are not useful (except for additional buffering, but that is not of interest here), only a side effect of the cluster-pair setup. the SIMD 2xMM kernel has a higher useful pair ratio then the 4xM kernel due to a smaller cluster size, but a lower total pair throughput.

๐Ÿšจ bestie listen. it is best to run this โ€” or, for that matter, any โ€” benchmark with locked CPU clocks, because thermal throttling can significantly affect performance. if that is not an option, the -warmup option can be used to run initial, untimed iterations to warm up the processor. ๐Ÿ”ฅ

the most relevant regime is between 0.1 to 1 millisecond per iteration. thus it is useful to run with system sizes that cover both ends of this regime. ๐ŸŒˆ

the -simd and -table options select different implementations to compute the same physics. the choice of these options should ideally be optimized for the target hardware. historically, we only found tabulated Ewald correction to be useful on 2-wide SIMD or 4-wide SIMD without FMA support. as all modern architectures are wider and support FMA, we do not use tables by default. the only exceptions are kernels without SIMD, which only support tables. ๐ŸŒธ

options -coulomb, -combrule, -interactmodifier and -halflj depend on the force field and composition of the simulated system. the optimization of computing Lennard-Jones interactions for only half of the atoms in a cluster is useful for water, which does not use Lennard-Jones on hydrogen atoms in most water models. in the MD engine, any clusters where at most half of the atoms have LJ interactions will automatically use this kernel. ๐Ÿ’ง and finally, the -energy option selects the computation of energies, which are usually only needed infrequently. periodt.


๐Ÿ’– OPTIONS ๐Ÿ’–

๐ŸŽ€ Options to specify output files

  • -o [<.csv>] (nonbonded-benchmark.csv) (Optional) โ€” also output results in csv format ๐Ÿ“„ so you can spreadsheet-ify your flex.

๐Ÿ’… Other options

  • -size <int> (1) โ€” the system size is 3000 atoms times this value. math is math, bestie ๐Ÿงฎ
  • -nt <int> (1) โ€” the number of OpenMP threads to use ๐Ÿงต
  • -simd <enum> (auto) โ€” SIMD type. auto runs all supported SIMD setups, or no SIMD when SIMD is not supported: auto, no, 4xm, 2xmm โšก
  • -coulomb <enum> (ewald) โ€” the functional form for the Coulomb interactions: ewald, reaction-field โš›๏ธ
  • -interactmodifier <enum> (PotShift) โ€” the Coulomb / VdW interaction modifier. reported under the 'intmod.' column: PotShift, PotSwitch, ForceSwitch ๐Ÿช„
  • -[no]table (no) โ€” use lookup table for Ewald correction instead of analytical ๐Ÿ“Š
  • -combrule <enum> (geometric) โ€” the LJ combination rule. reported under the 'comb.' column: geometric, lb, none ๐Ÿงฌ
  • -[no]halflj (no) โ€” use optimization for LJ on half of the atoms. reported under the 'LJ' column ๐Ÿ“
  • -[no]energy (no) โ€” compute energies in addition to forces ๐Ÿ”‹
  • -[no]all (no) โ€” run all 36 combinations of options for coulomb, halflj, combrule, interactmodifier. go big or go home ๐Ÿ’ฅ
  • -cutoff <real> (1) โ€” pair-list and interaction cut-off distance โœ‚๏ธ
  • -iter <int> (100) โ€” the number of iterations for each kernel ๐Ÿ”
  • -warmup <int> (0) โ€” the number of iterations for initial warmup โ˜•
  • -[no]cycles (no) โ€” report cycles/pair instead of pairs/cycle ๐Ÿ”„
  • -[no]time (no) โ€” report micro-seconds instead of cycles โฑ๏ธ

๐Ÿ‘€ SEE ALSO ๐Ÿ‘€

more information about GROMACS is available at http://www.gromacs.org/. go read, iykyk ๐Ÿฆ‹


2026, GROMACS development team ๐Ÿ’œ


and that's the whole thing, bestie!! you just read the entire gmx-nonbonded-benchmark(1) page and honestly? slay. this was GROMACS 2026.4, dated Oct 02, 2026 โ€” go lock your CPU clocks, warm up your processor, and benchmark like the main character you are. mwah ๐Ÿ’…โœจ๐ŸŽ€๐Ÿซถ

๐Ÿ“ฆ where this page comes from