search

openmm / openmm-plumed

OpenMM plugin to interface with PLUMED
59 stars 23 forks source link

CUDA slowness #29

Closed tonigi closed 4 years ago

tonigi commented 4 years ago

There is something odd going on in the CUDA version: it's many times slower than the reference implementation, even with a "do-nothing" PLUMED input. I doubt it's just memory copying as it occurs with a handful of atoms. A self-contained example is here https://github.com/giorginolab/openmm-plumed-diala

peastman commented 4 years ago

Using it with CUDA does have extra overhead. PLUMED runs on the CPU, so we have to copy data back and forth between CPU and GPU. This is especially significant when using a small system with just a few atoms, since in that case the cost is dominated by latency, which is independent of the number of atoms.

instaM commented 2 years ago

I have a similar issue right now. I have not looked at the code but I wonder if it would be possible to update the external forces generated by openmm-plumed every 100 steps instead of every step. Would that make a significant difference ?

raimis commented 2 years ago

PLUMED has such option: STRIDE = 100 (https://www.plumed.org/doc-v2.7/user-doc/html/_m_e_t_a_d.html)

instaM commented 2 years ago

Sure thank you I know about this option. Howerer STRIDE is an option from the PRINT function. Just tried if it would do anything to solve my performance problem, and it does not. My question was more about the frequency at which the force applied to the system is updated, not printed. There is neither such an option from the MOVINGRESTRAINT (which I am using ) and neither from the METAD function.

raimis commented 2 years ago

Regarding the functionally of PLUMED, probably you should ask in its repo: https://github.com/plumed/plumed2. OpenMM-PLUMED doesn't modify what PLUMED is doing.