This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing
This article is within the scope of WikiProject Physics, a collaborative effort to improve the coverage of Physics on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.PhysicsWikipedia:WikiProject PhysicsTemplate:WikiProject Physicsphysics
This article is within the scope of WikiProject Linux, a collaborative effort to improve the coverage of Linux on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.LinuxWikipedia:WikiProject LinuxTemplate:WikiProject LinuxLinux
"The highly optimized code makes GROMACS the fastest program for molecular simulations to date."
Fastest because it scales the best? Fastest on a single proc? Fastest SPME routines, fastest Monte Carlo, fastest what? Seems more like the puffery of a sales pitch. Cite some *recent* benchmarks, please. —Preceding unsigned comment added by 134.253.26.11 (talk) 17:06, 20 May 2008 (UTC)[reply]
If we look at the 1 fs time step results, we can see that, per clock cycle, GROMACS is 2 times faster than Desmond and 3−4 times faster than NAMD, even though the benchmark settings are unfavorable for GROMACS. Additionally GROMACS can be another factor 1.5 faster by increasing the time step from 2.5 to 4 fs, which is made possible by constraining all bonds and converting hydrogens to virtual sites. With MPI, Desmond shows similar scaling to GROMACS, whereas NAMD scales worse. With a special Infiniband communication library, Desmond scales much further than GROMACS in terms of number of cores but only slightly further in terms of actual performance. GROMACS would certainly also benefit from such a library.[1]
How good the scaling is depends on three factors: the speed of the computational part in isolation, the efficiency of the parallel and communication algorithms, and the efficiency of the communication itself. The first two factors we have been optimized extensively. The single processor performance of GROMACS is unrivaled. This makes good relative scaling extremely difficult, since communication takes relatively more time. Nevertheless, the benchmarks show that the scaling is now nearly linear over a large range of processor counts. .... There are still alternatives with even more impressive relative scaling,9 and dedicated-hardware implementation might provide extremely high performance if cost is no issue. However, for all normal cases where resources are scarce and absolute performance is the only thing that matters, we believe the implementation presented here will be extremely attractive for molecular simulations[2] --Dr DBW (talk) 01:52, 30 November 2009 (UTC)[reply]
.jpg?lang=en){kind=small}
