Update running CUDA and performance tuning 03/4803/4 release-2.13
authorDavid Hardy <dhardy@ks.uiuc.edu>
Fri, 9 Nov 2018 18:45:25 +0000 (12:45 -0600)
committerDavid Hardy <dhardy@ks.uiuc.edu>
Fri, 9 Nov 2018 19:37:43 +0000 (13:37 -0600)
Moved performance tuning chapter to later part of user guide.
Updated to discuss NAMD performance tuning concepts.

Updated section on running CUDA for modern GPUs, added explanation
of what is and is not accelerated, what is and is not disabled by
CUDA-accelerated builds, and added some keywords.

Updated copyright year on user guide.

Change-Id: I21cda6ef7bd25fde53274d0733637b645645c2f8

ug/namd_copyright.tex
ug/ug.tex
ug/ug_performance.tex
ug/ug_qmmm.tex
ug/ug_runit.tex

index a0bd86f..b3f5a12 100644 (file)
@@ -10,7 +10,7 @@
 \medskip
 {\large Theoretical and Computational Biophysics Group, Beckman Institute, University of Illinois.} \\
 \bigskip
-{\large \copyright 1995-2011 The Board of Trustees of the University of Illinois.
+{\large \copyright 1995-2018 The Board of Trustees of the University of Illinois.
 All Rights Reserved} \\
 \bigskip
 \end{centering}
index 1f7977f..cb8dbc7 100644 (file)
--- a/ug/ug.tex
+++ b/ug/ug.tex
 \newpage
 \input{ug_dynamics}
 
-% Performance tuning parameters
-\newpage
-\input{ug_performance}
-
 % User defined forces
 \newpage
 \input{ug_userdef}
 \newpage
 \input{ug_analysis}
 
+% Performance tuning parameters
+\newpage
+\input{ug_performance}
+
 % Equivalence with X-PLOR parameters
 \newpage
 \input{ug_xplor}
index e4a7ccc..3d526e1 100644 (file)
@@ -1,6 +1,101 @@
 \section{Performance Tuning}
 \label{section:performance}
 
+\subsection{NAMD performance tuning concepts}
+The simulation performance obtained from NAMD depends on many factors.
+The particular simulation protocol being run is one of the largest
+single factors associated with NAMD performance, as different simulation
+methods invoke different code that can have substantially different 
+performance costs, potentially with a different degree of parallel
+scalability, message passing activity, hardware acceleration through
+the use of GPUs or CPU vectorization,
+and other attributes that also contribute to overall NAMD performance.
+
+\paragraph{Measuring performance.}
+When NAMD first starts running, it does significant I/O, FFT tuning,
+GPU context setup, and other work that is unrelated to normal 
+simulation activity, so it is important to measure performance only
+when NAMD has completed startup all of the processing units are 
+running at full speed.
+The best way to measure NAMD performance accurately requires running
+NAMD for 500 to 1,000 steps of normal dynamics (not minimization), 
+so that load balancing has a chance to 
+take place several times, and all of the CPUs and GPUs have ramped up
+to 100\% clock rate.  NAMD provides ``Benchmark time:'' and ``TIMING:''
+measurements in its output, which can be used for this purpose.  
+Here, we are only interested in the so-called wall clock time.
+
+\paragraph{NAMD configuration and I/O performance.}
+Aside from the choice of major simulation protocol and associated
+methods in use, it is also important to consider the performance impacts
+associated with routine NAMD configuration parameters such as those
+that control the frequency of simulation informational outputs and 
+various types of I/O.
+Simulation outputs such as energy information may require NAMD to do additional
+computations above and beyond standard force evaluation calculations.
+We advise that NAMD simulation configuration parameters be selected such
+that output of energies (via the \texttt{outputEnergies} parameter) 
+be performed only as much as is strictly necessary, since 
+they otherwise serve to slow down the simulation due to the extra
+calculations they require.  
+NAMD writes ``restart" files to enable simulations that were terminated 
+unexpectedly (for any reason) to be conveniently restarted from the 
+most recently written restart file available.  While it is desirable
+to have a relatively recent restart point to continue from, writing
+restart information costs NAMD extra network communication and disk I/O.
+If restart files are written too frequently, this extra activity and I/O
+will slow down the simulation.  A reasonable estimate for restart
+frequency is to choose the value such that NAMD writes restart files
+about once every ten minutes of wall clock time.  
+At such a rate, the extra work and I/O associated with writing
+the restart files should remain an insignificant factor in NAMD performance.
+
+\paragraph{Computational (arithmetic) performance.}
+NAMD is provided in a variety of builds that support platform-specific
+techniques such as CPU vectorization and GPU acceleration 
+to achieve higher arithmetic performance, thereby increasing 
+NAMD simulation throughput.  
+Whenever possible NAMD builds should be compiled such that 
+CPU vector instructions are enabled, and highly tuned
+platform-specific NAMD code is employed for performance-critical 
+force computations.
+The so-called ``SMP'' builds of NAMD benefit from reduced memory use 
+and can in many cases perform better overall, but one trade-off 
+is that the communication thread is unavailable for simulation work.
+NAMD performance can be improved by explicitly setting CPU affinity
+using the appropriate Charm++ command line flags, e.g., 
+\texttt{++ppn 7 +commap 0,8 +pemap 1-7,9-15} as an example.
+
+It is often beneficial to reserve one CPU core for the 
+operating system, to prevent harmful operating system noise or ``jitter'',
+particularly when running NAMD on large scale clusters or supercomputers.
+The Cray \texttt{aprun -r 1} command reserves and
+forces the operating system to run on the last CPU core.
+
+State-of-the-art compute-optimized GPU accelerators, 
+can provide NAMD with simulation performance equivalent to 
+several CPU sockets (on the order of 100 CPU cores) when used to 
+greatest effect, e.g., when GPUs have sufficient work per GPU.
+In general, effective GPU acceleration currently requires on the order
+of 10,000 atoms per GPU assuming a fast network interconnect.
+NAMD currently requires several CPU cores to drive each GPU effectively,
+ensuring that there is always work ready and available for the GPU.
+For contemporary CPU and GPU hardware, the most productive ratios of 
+CPU core counts per GPU tend to range from 8:1 to 25:1 depending on 
+the details of the hardware involved. 
+
+\paragraph{Networking performance.}
+When running NAMD on more than a single node, it is important to 
+use a NAMD version that is optimal for the underlying network hardware
+and software you intend to run on.  The Charm++ runtime system on which
+NAMD is based supports a variety of underlying networks, so be sure to
+select a NAMD/Charm++ build that is most directly suited for your 
+hardware platform.  In general, we advise users to avoid the use of 
+an MPI-based NAMD build as it will underperform compared with a native
+network layer such as InfiniBand IB verbs (often referred to as ``verbs''),
+the Cray-specific ``gni-crayxc'' or ``gni-crayxe'' layer,
+or the IBM PAMI message passing layer, as practical examples.
+
 
 \subsection{Non-bonded interaction distance-testing}
 
index fedf1fd..19e5e4d 100644 (file)
@@ -601,10 +601,10 @@ identified by a non-zero number.
 \vspace{-1em}
 \small{
 \begin{tabbing}
-qmCustomPCFile \= system/system.customPC.1.pdb \\
-qmCustomPCFile \> system/system.customPC.2.pdb \\
-qmCustomPCFile \> system/system.customPC.3.pdb \\
-qmCustomPCFile \> system/system.customPC.4.pdb
+qmCustomPCFile  system/system.customPC.1.pdb \\
+qmCustomPCFile  system/system.customPC.2.pdb \\
+qmCustomPCFile  system/system.customPC.3.pdb \\
+qmCustomPCFile  system/system.customPC.4.pdb
 \end{tabbing}
 } % \small
 } % \texttt
@@ -659,12 +659,12 @@ string composed of the QM group ID, the segment name and the residue ID.
 \vspace{-1em}
 \small{
 \begin{tabbing}
-qmLSSRef \= "1 RP1 9" \\
-qmLSSRef \> "2 RP1 3" \\
-qmLSSRef \> "2 RP1 2" \\
-qmLSSRef \> "3 AP1 9" \\
-qmLSSRef \> "3 AP1 3" \\
-qmLSSRef \> "4 AP1 9"
+qmLSSRef  "1 RP1 9" \\
+qmLSSRef  "2 RP1 3" \\
+qmLSSRef  "2 RP1 2" \\
+qmLSSRef  "3 AP1 9" \\
+qmLSSRef  "3 AP1 3" \\
+qmLSSRef  "4 AP1 9"
 \end{tabbing}
 } % \small
 } % \texttt
@@ -682,8 +682,8 @@ if either ORCA or MOPAC are selected.
 \vspace{-1em}
 \small{
 \begin{tabbing}
-qmConfigLine \= "! PM3 ENGRAD" \\
-qmConfigLine \> "\%\%output PrintLevel Mini Print\textbackslash{[}P\_Mulliken\textbackslash{]} 1 Print\textbackslash{[}P\_AtCharges\_M\textbackslash{]} 1 end"
+qmConfigLine  "! PM3 ENGRAD" \\
+qmConfigLine  "\%\%output PrintLevel Mini Print\textbackslash{[}P\_Mulliken\textbackslash{]} 1 Print\textbackslash{[}P\_AtCharges\_M\textbackslash{]} 1 end"
 \end{tabbing}
 } % \small
 } % \texttt
@@ -694,8 +694,8 @@ qmConfigLine \> "\%\%output PrintLevel Mini Print\textbackslash{[}P\_Mulliken\te
 \vspace{-1em}
 \small{
 \begin{tabbing}
-qmConfigLine \= "PM7 XYZ T=2M 1SCF MOZYME CUTOFF=9.0 AUX LET GRAD QMMM GEO-OK" \\
-qmConfigLine \> "Test System"
+qmConfigLine  "PM7 XYZ T=2M 1SCF MOZYME CUTOFF=9.0 AUX LET GRAD QMMM GEO-OK" \\
+qmConfigLine  "Test System"
 \end{tabbing}
 } % \small
 } % \texttt
@@ -714,10 +714,10 @@ and its multiplicity.
 \vspace{-1em}
 \small{
 \begin{tabbing}
-qmMult \= "1 1" \\
-qmMult \> "2 1" \\
-qmMult \> "3 1" \\
-qmMult \> "4 1"
+qmMult  "1 1" \\
+qmMult  "2 1" \\
+qmMult  "3 1" \\
+qmMult  "4 1"
 \end{tabbing}
 } % \small
 } % \texttt
@@ -736,10 +736,10 @@ of the QM region ID and its total charge.
 \vspace{-1em}
 \small{
 \begin{tabbing}
-qmCharge \= "1 1" \\
-qmCharge \> "2 -1" \\
-qmCharge \> "3 1" \\
-qmCharge \> "4 -1"
+qmCharge  "1 1" \\
+qmCharge  "2 -1" \\
+qmCharge  "3 1" \\
+qmCharge  "4 -1"
 \end{tabbing}
 } % \small
 } % \texttt
@@ -846,7 +846,6 @@ This independent frequency allows the user to store QM-specific energy
 data at a larger stride to save time and space.
 }
 
-
 \item
 \NAMDCONFWDEF{qmChargeFromPSF}{Set charge of QM region from PSF file}%
 {``on" or ``off"}{off}{%
@@ -854,7 +853,6 @@ Automatically determine charge of QM regions by adding the charges of
 atoms in each region.
 }
 
-
 \item
 \NAMDCONFWDEF{qmCSMD}{Apply conditional-SMD to QM atoms?}%
 {``on" or ``off"}{off}{%
@@ -875,8 +873,5 @@ following syntax:\\
 Atom1 Atom2 Force(Kcal/Mol/A) Speed(A/step) Cutoff(A)
 }
 
-
-
-
 \end{itemize}
 
index bd0276b..2d086c3 100644 (file)
@@ -391,20 +391,74 @@ should be used, with CPU affinity set as described above.
 
 Energy evaluation is slower than calculating forces alone, and the loss
 is much greater in CUDA-accelerated builds.  Therefore you should set
-outputEnergies to 100 or higher in the simulation config file.  Some
-features are unavailable in CUDA builds, including alchemical free
-energy perturbation and the {Lowe-Andersen} thermostat.
-
-As this is a new feature you are encouraged to test all simulations
-before beginning production runs.  Forces evaluated on the GPU differ
+outputEnergies to 100 or higher in the simulation config file.
+% As this is a new feature you are encouraged to test all simulations
+% before beginning production runs.
+Forces evaluated on the GPU differ
 slightly from a CPU-only calculation, an effect more visible in reported
 scalar pressure values than in energies.
 
+NAMD now has the entire force calculation offloaded to GPU
+for conventional MD simulation options.
+However,
+not all advanced features are compatible with CUDA-accelerated NAMD builds,
+in particular, any simulation option that requires modification
+to the functional form of the non-bonded forces.
+Note that QM/MM simulation is also disabled for CUDA-accelerated NAMD,
+because the calculation is bottlenecked by
+the QM calculation rather than the MM force calculation,
+so can benefit from CUDA acceleration of the QM part when available.
+Table~\ref{table:CUDA-accelerated} lists the parts of NAMD
+that are accelerated with CUDA-capable GPUs,
+and Table~\ref{table:CUDA-disabled} lists the advanced simulation
+options that are disabled within a CUDA-accelerated NAMD build.
+
+\begin{table}[htb]
+\caption{NAMD GPU: What is accelerated?}
+\begin{center}
+\begin{tabular}{c|c}
+\textbf{Accelerated} & \textbf{Not Accelerated} \\ \hline
+short-range non-bonded  & integration \\
+PME reciprocal sum      & rigid bonds \\
+bonded terms            & grid forces \\
+implicit solvent        & collective variables \\
+NVIDIA GPUs only        &
+\end{tabular}
+\end{center}
+\label{table:CUDA-accelerated}
+\end{table}
+
+\begin{table}[htb]
+\caption{NAMD GPU: What features are disabled?}
+\begin{center}
+\begin{tabular}{c|c}
+\textbf{Disabled} & \textbf{Not Disabled} \\ \hline
+Alchemical (FEP and TI)
+  & Memory optimized builds \\
+Locally enhanced sampling
+  & Conformational free energy \\
+Tabulated energies
+  & Collective variables \\
+Drude (nonbonded Thole)
+  & Grid forces \\
+Go forces
+  & Steering forces \\
+Pairwaise interaction
+  & Almost everything else \\
+Pressure profile
+  & \\
+QM/MM
+  &
+\end{tabular}
+\end{center}
+\label{table:CUDA-disabled}
+\end{table}
+
 To benefit from GPU acceleration you will need a CUDA build of NAMD
-and a recent high-end NVIDIA video card.  CUDA builds will not function
-without a CUDA-capable GPU and a driver that supports CUDA 6.0.  If the
+and a recent NVIDIA video card.  CUDA builds will not function
+without a CUDA-capable GPU and a driver that supports CUDA 8.0.  If the
 installed driver is too old NAMD will exit on startup with the error
-``CUDA driver version is insufficient for CUDA runtime version''.
+``CUDA driver version is insufficient for CUDA runtime version.''
 
 Finally, if NAMD was not statically linked against the CUDA runtime
 then the libcudart.so file included with the binary (copied from
@@ -419,7 +473,8 @@ when running a multicore binary (recommended for a single machine):
 \end{verbatim}
 
 Each namd2 thread can use only one GPU.  Therefore you will need to run
-at least one thread for each GPU you want to use.  Multiple threads
+at least one thread for each GPU you want to use.
+Multiple threads in an SMP build of NAMD
 can share a single GPU, usually with an increase in performance.  NAMD
 will automatically distribute threads equally among the GPUs on a node.
 Specific GPU device IDs can be requested via the +devices argument on
@@ -485,6 +540,76 @@ Do NOT add the cuda option to the Charm++ build command line.  The
 only changes to the build process needed are to add --with-cuda and
 possibly --cuda-prefix ... to the NAMD config command line.
 
+Right now, NAMD does not support all features available on GPUs.
+Thus, some keywords were introduced to help the user have a better control of 
+the calculation. These keywords are relevant only for CUDA builds, 
+and are ignored if the user is running a CPU build.
+
+\subsubsection{Keywords}
+
+\begin{itemize}
+\setlength{\itemsep}{0.4cm}
+
+\item
+\NAMDCONFWDEF{bondedCUDA}{0 to 255}{Integer value between 0 and 255}{255}{%
+NAMD provides CUDA kernels for calculating
+six different bonded force terms.
+The bondedCUDA parameter acts as a bit mask
+that can disable particular kernels.
+Any partial sum of the following values can
+be used to enable only the specified bonded terms:
+\begin{itemize}
+\item bonds $=$ 1
+\item angles $=$ 2
+\item dihedrals $=$ 4
+\item impropers $=$ 8
+\item exclusions $=$ 16
+\item crossterms $=$ 32
+\end{itemize}
+}
+
+\item
+\NAMDCONFWDEF{usePMECUDA}{Offload entire PME reciprocal sum to GPU?}%
+{``on" or ``off"}{on}{%
+The entire PME reciprocal sum is offloaded to GPUs,
+when using no more than four nodes.
+Otherwise usePMECUDA is disabled by default.
+}
+
+\item
+\NAMDCONFWDEF{PMEoffload}{Offload PME gridding/ungridding procedures to GPU?}%
+{``on" or ``off"}{off}{%
+The gridding and ungridding procedures for calculating the PME
+reciprocal sum is offloaded to GPUs,
+with the FFT calculation still performed by CPUs.
+PMEoffload is enabled by default only for PMEinterpOrder $>$ 4.
+
+For huge systems (10 million atoms and above)
+where the parallel FFT limits performance,
+it is desirable to use PMEoffload in conjunction with
+increased order interpolation and increased grid spacing,
+in order to decrease the overall communication latency
+by decreasing the overall grid size by a factor of 8
+while maintaining the same accuracy for the calculation.
+
+\vspace{-0.25em}
+\textbf{Exemplary use:}
+\texttt{%
+\vspace{-1em}
+\small{%
+\begin{tabbing}
+PME on \\
+PMEinterpOrder 8 \\
+PMEgridSpacing 2.0 \\
+PMEoffload on   ;\# enabled by default for these PME settings
+\end{tabbing}
+} % \small
+} % \texttt
+} % \NAMDCONFWDEF
+
+
+\end{itemize}
+
 \subsection{Xeon Phi Acceleration}
 
 NAMD supports offloading calculations to Intel Xeon Phi coprocessors.