>
> Note since AMBER sits entirely on a GPU so you can run multiple jobs on a
>> node without contention (1 per GPU). This is not true with Gromacs due to
>> all the CPU to CPU and CPU to GPU communication that floods the
>> communication channels between CPU cores and the PCI-E bus to the GPU. As
>> such you can't reliably run say 2 Gromacs jobs on the same node where one
>> uses 20 cores and 2 GPUs and another uses the remaining 20 cores and
>> remaining 2 GPUs.
>>
>
> Uh, no. These run fine (ie *reliable*) and when set up properly will
> naturally run out of phase with eachother and maximise throughput. See e.g.
> http://onlinelibrary.wiley.com/doi/10.1002/jcc.24030/abstract;jsessionid=3CD2B4EE326378381D60FCB0BD1B26A0.f02t02
> (or same on arxiv.
>
> Mark
Only if you go to the trouble of placing threads properly and locking things to the right cores and corresponding GPUs. This, and the complexity in choosing hardware for Gromacs as illustrated by the plethora of options and settings highlighted in that paper, is something that is generally way beyond the average user and a pain in the butt to configure properly with most queuing systems. So while it works in theory my experience is that this is very difficult to achieve reliably in practice.
All the best
Ross
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Tue Jul 25 2017 - 12:30:02 PDT
