GROMACS ACCELERATO CON GPU

Inizia subito con questa guida per applicazioni basate su GPU.

GROMACS

GROMACS è un'applicazione di dinamica molecolare progettata per simulare equazioni di moto newtoniane per sistemi con centinaia di milioni di particelle. GROMACS è progettato per la simulazione di molecole biochimiche, ad esempio proteine, lipidi e acidi nucleici, che si basano su numerose interazioni con legami complicati.

L'esecuzione di GROMACS è 3 volte più veloce su sistemi accelerati con GPU NVIDIA rispetto ai sistemi basati solo su CPU*, per cui le simulazioni di dinamica molecolare richiedono ore e non giorni.

GROMACS è 3 volte più veloce su sistemi accelerati con GPU NVIDIA

Installazione

GROMACS (versione 5.1.2), può essere scaricato dal sito Web GROMACS. Nell'esempio seguente, nelle righe di comando sostituire "VERSION" con 5.1.2 o con la versione di GROMACS più recente o quella che si intende utilizzare. Dopo la redazione di questa guida, è stata rilasciata la versione 5.1.4 che si è rivelata più veloce della versione 5.1.2.

Istruzioni di download e di installazione

Per la configurazione (con CMake) e la build della versione accelerata tramite GPU, è necessario il software seguente:

  • CMake
  • NVIDIA CUDA®*
  • GCC*
  • MPI (opzionale, da utilizzare se serve la versione multi-nodo).

*Si consiglia di utilizzare una versione CUDA recente (attualmente 7.5) e la versione gcc più recente supportata dalla versione CUDA indicata.

$ wget ftp://ftp.gromacs.org/pub/gromacs/gromacs-VERSION.tar.gz
$ tar -xzvf gromacs-VERSION.tar.gz
$ mkdir gromacs-VERSION-build
$ cd gromacs-VERSION-build
$ CC=gcc CXX=g++ cmake <GROMACS_SRC_DIR> -DGMX_OPENMP=ON -DGMX_GPU=ON -
DGPU_DEPLOYMENT_KIT_ROOT_DIR=<GDK_PATH> -DGMX_BUILD_OWN_FFTW=ON -
DGMX_PREFER_STATIC_LIBS=ON -DCMAKE_BUILD_TYPE=Release -
DCMAKE_INSTALL_PREFIX=<GROMACS_INSTALL_DIR>

CMAKE (CROSS PLATFORM MAKE): OPZIONI

Sostituire con il percorso per la directory del sorgente GROMACS, per esempio, ../gromacs-5.1.2. è dove è installato il kit di implementazione GPU.

I clock GPU GROMACS 5.1 possono essere regolati automaticamente per prestazioni ottimali via NVML. Per creare il supporto NVML opzionale è necessario il supporto del kit di implementazione GPU (GDK).

Dopo aver eseguito il download e l'installazione, sostituire con il percorso della directory gdk. È possibile rimuovere l'opzione -DGPU_DEPLOYMENT_KIT_ROOT_DIR= installando GDK nella posizione predefinita. Anche va sostituito con la directory di installazione desiderata, per esempio /opt/gromacs.

Qui vengono effettuate diverse altre configurazioni usando le opzioni CMake, come l'abilitazione del supporto OpenMP usando -DGMX_OPENMP=ON. Con l'opzione di configurazione -DGMX_BUILD_OWN_FFTW=ON, FFTW viene scaricato e creato durante la creazione GROMACS. Questo garantisce che vengano selezionate le flag di ottimizzazione corrette per FFTW. In alternativa, è possibile utilizzare una specifica installazione FFTW; si veda la sezione FFTW delle istruzioni di installazione GROMACS per i dettagli. Per informazioni dettagliate su ogni opzione, fare riferimento al Manuale GROMACS.

GROMACS con MPI

Per la build e l'installazione di GROMACS con il supporto MPI, è necessario modificare il comando precedente in base a quello successivo utilizzando i wrapper del compilatore MPI e l'aggiunta di "-DGMX_MPI=ON".

$ CC=mpicc CXX=mpicxx cmake <GROMACS_SRC_DIR> -DGMX_OPENMP=ON -DGMX_GPU=ON
-DGPU_DEPLOYMENT_KIT_ROOT_DIR=<GDK_PATH> -DGMX_MPI=ON -DGMX_BUILD_OWN_FFTW=ON -DGMX_PREFER_STATIC_LIBS=ON -
DCMAKE_BUILD_TYPE=Release -DGMX_BUILD_UNITTESTS=ON -DCMAKE_INSTALL_PREFIX=<GROMACS_INSTALL_DIR>

BUILD E INSTALLAZIONE

Per creare e installare GROMACS, usare il seguente comando:

$ make
$ sudo make install

Per verificare la correttezza di GROMACS dopo l'installazione, aggiungere l'opzione -DREGRESSIONTEST_DOWNLOAD=ON al comando di configurazione ed eseguire "make check" prima di "make install". Inoltre, è possibile anche usare "make -jN", N è il numero dei core nelle piattaforme per avanzare più rapidamente.

Per ulteriori dettagli sulle opzioni di installazione, fare riferimento alla Guida di installazione GROMACS.

Esecuzione di processi

GROMACS fornisce gli script per configurare l'ambiente per diversi shell. Per configurare il PATH e un altro ambiente deve essere usato il comando sotto.

    $ source <GROMACS_INSTALL_DIR>/bin/GMXRC

Per la build di file binari MPI e non MPI come sopra descritto, la cartella bin dell'installazione includerà sia "gmx" che "gmx_mpi". Gli esempi descritti in questa guida usano gruppi di dati acqua dell'ftp GROMACS. L'esecuzione di GROMACS con questi gruppi di dati richiede una fase di preparazione dati come descritto sotto. Dettagli/opzioni supplementari relativi alla preparazione di input per l'esecuzione di GROMACS sono riportati qui.

Per eseguire GROMACS sono necessari due passaggi:

Passaggio 1. Preparazione dell'input con grompp (preprocessore GROMACS) 

a. Per la versione a nodo singolo: $ gmx grompp -f

Passaggio 2. Avvio di mdrun

a. Per la versione a nodo singolo: $ gmx mdrun 
b. Per la versione MPI  (np = numero di GPU): $ mpirun -np gmx_mpi mdrun

Per numeri di nodi bassi, queste impostazioni garantiscono solitamente buone prestazioni. Tuttavia un po' di tuning solitamente migliora le prestazioni di simulazione del GROMACS. Questo tuning manuale diventa più importante per numeri di nodi più elevati. Consultare il  manuale di GROMACS , la  mailing list degli utenti gmx e i documenti pubblicati per i dettagli.

Il presente documento descrive le opzioni di ottimizzazione delle prestazioni relative alle GPU. I set di input per il benchmarking sono disponibili per il download.

OPZIONI DI ESECUZIONE BENCHMARK

Durante l'esecuzione dei benchmark GROMACS per misurare le prestazioni, utilizzare le seguenti opzioni della riga di comando:

1. –resethway : all'avvio di ogni simulazione, GROMACS ottimizza la decomposizione del dominio e bilancia il carico tra le CPU e le GPU disponibili. Questo rallenta le prime centinaia di iterazioni. Poiché le simulazioni reali funzionano per un periodo molto lungo, questo non ha alcun impatto sulle prestazioni raggiunte. Per ridurre al minimo il runtime necessario per ottenere risultati stabili durante il benchmarking, è necessario specificare l'opzione –resethway. -resethway ripristina tutti i contatori delle prestazioni quando è eseguita metà delle iterazioni, consentendo così di misurare una prestazione realistica senza troppi step temporali. Attenzione: se il ripristino avviene mentre il bilanciatore di carico PME è ancora attivo all'inizio dell'esecuzione, può presentarsi il seguente errore "PME tuning was still active when attempting to reset mdrun counters at step xxxxxxx". Per evitare questo errore è possibile aumentare gli incrementi di tempo di esecuzione aumentando il -maxh utilizzato o aggiungendo il parametro -nstpes per aumentare il numero di step temporali della simulazione.

2. -maxh: controlla il tempo massimo dell'esecuzione della simulazione. mdrun esegue incrementi di tempo sufficienti per funzionare almeno per il periodo specificato in ore. Il valore impostato dovrebbe essere abbastanza elevato da ottenere risultati di prestazioni stabili. Un valore ragionevole sarebbe tipicamente di 5 minuti = 0,08333. Per limitare il tempo di esecuzione della simulazione può essere usata questa opzione oppure l'opzione "nsteps" descritta sotto.

3. –noconfout: questo disabilita l'uscita del confout.groche potrebbe richiedere una considerevole quantità di tempo, ad es. su file system paralleli. Poiché questo viene fatto molto raramente nelle simulazioni reali, la funzione va disattivata durante il benchmarking.

4. -v: stampa più informazioni per la riga di comando e il file log md.log. Le informazioni contenute sono molto utili per ottimizzare la prestazioni di GROMACS.

5. -nb: indica a GROMACS di utilizzare "gpu" o "cpu" per alcuni calcoli

6. -nsteps: numero di incrementi di tempo da eseguire. Ignora il valore predefinito nel file mdp. Questa opzione può anche essere usata per controllare il tempo complessivo di esecuzione di una simulazione, invece di utilizzare il maxh.

Le prestazioni sono riportate al fondo del file log prodotto (md.log) e sull'output console in ns/giorno (più alto è preferibile). 

Visitare la pagina di documentazione GROMACS per avere maggiori dettagli sui parametri della riga di comando.

OTTIMIZZAZIONE DELLE PRESTAZIONI

Per comprendere il comportamento delle prestazioni di GROMACS è utile avere una comprensione di base delle operazioni che GROMACS esegue. Qui di seguito è mostrato un prospetto semplificato. Da una prospettiva di alto livello, GROMACS esegue quattro operazioni:

1. PP: calcola forze a corto raggio non di legame o interazioni particella-particella (PP) (compute bound solo per le comunicazioni tra primi vicini)

2. PME: calcola un'approssimazione per la parte a lungo raggio di forze non di legame a lungo raggio (comunicazione intensa in esecuzioni multi-nodo)

3. Bonded (di legame - B): calcola forze di legame

4. Altro: applica vincoli di legame, avanza posizioni atomiche, calcola liste vicini e altro.

La versione GPU di GROMACS accelera l'attività più lunga PP sulla GPU mentre le altre tre attività PME, Bonded e Altro possono essere eseguite solo sulla CPU. L'attività PP è indipendente dall'attività Bonded e PME e può essere eseguita in contemporanea mentre l'attività Altro dipende principalmente dall'output di PP, PME e Bonded. Quindi la versione GPU esegue le attività PME e Bonded su CPU, mentre la GPU esegue l'attività PP:

Attività PP con calcoli complessi degli offload GROMACS su GPU

Scalando il cutoff elettrostatico (distanza oltre la quale una forza è gestita dalla parte a lungo raggio) GROMACS può spostare il carico dalla CPU (attività PME) alla GPU (attività PP) (se abilitata automaticamente, può essere disabilitata con l'interruttore sulla riga di comando –tunepme). A causa delle restrizioni sulla precisione questo non è possibile nella sequenza inversa. Esempio nel caso in cui la GPU completi l'attività PP più rapidamente della CPU (vedere la figura sotto), GROMACS sposta il carico dalla CPU alla GPU il che porta un runtime dell'applicazione più breve.

GROMACS trasferisce i carichi di lavoro alle GPU per accelerare le simulazioni

L'attività PP ha una complessità di O(m*n) e l'attività PME di O(n log(n)), dove n è il numero delle particelle e m la dimensione della lista vicini. I valori tipici di m sono compresi solitamente tra 200 e 400, un valore di molto inferiore a n.

Le seguenti impostazioni possono essere usate per ottimizzare le prestazioni di GROMACS.

CONFIGURAZIONE DELL'AVVIO

GROMACS utilizza MPI e OpenMP per poter utilizzare tutte le risorse GPU e CPU disponibili in un cluster. In base all'input impostato e alla capacità della rete, vi sono diverse configurazioni di avvio ottimali. Queste vanno da un processo MPI per ciascun core logico con un thread OpenMP fino ad un processo MPI per nodo che utilizza tutti i core disponibili in quel nodo. Per scegliere la migliore configurazione di avvio è possibile ricorrere alle seguenti linee guida:

  • se si utilizza solo il single (a volte dual) CPU socket, la parallelizzazione OpenMP è solitamente più efficiente dell'MPI
  • se si utilizzano CPU socket o nodi multipli, la parallelizzazione MPI e OpenMP (ibrida) usando 2-4 thread OpenMP per rank MPI è solitamente più efficiente del solo utilizzo di MPI
  • con un grande numero di nodi potrebbe essere utile usare più thread OpenMP per rank MPI per ridurre la quantità di comunicazione richiesta. La quantità di tempo impiegato nella comunicazione è riportata nel file di output md.log (vedere il conteggio Script 1 Time per la comunicazione in md.log).
Computing: Num Ranks Num Threads Call Count Wall time (s) Giga-Cycles total sum %
[…]
Comm. coord. 2 10 252681 63.467 3808.202 3.6
[…]
Comm. energies. 2 10 25917 1.108 66.457 0.1
Total 1782.537 106957.655 100.0
Breakdown of PME mesh computation
[…]
PME 3D-FFT Comm. 2 10 518322 126.829 7610.103 7.1
[…]

Conteggio Script 1 Time per la comunicazione in md.log

Per la versione MPI il numero dei rank MPI può essere controllato con il programma di avvio dell'implementazione MPI utilizzata (parametro -np), il numero dei thread OpenMP può essere controllato con l'opzione riga di comando mdrun –ntomp o la variabile di ambiente OMP_NUM_THREADS. La versione a nodo singolo di mdrun utilizza thread-MPI (un'implementazione MPI interna basata su thread) e OpenMP. Per questa versione il numero dei thread OpenMP può anche essere controllato anche con l'opzione della riga di comando -ntomp e il numero dei ranghi MPI può essere controllato con -ntmpi. Per la versione accelerata GPU di GROMACS, è necessario avere almeno un rank MPI per GPU per utilizzare tutti i GPU disponibili.

PINNING DEL THREAD/PROCESSO

Il thread OpenMP GROMACS e i processi MPI devono essere collegati correttamente ai core/thread del sistema. Questo si può fare tramite il programma di avvio MPI / sistema batch o tramite GROMACS. Per impostazione predefinita, GROMACS tenta il pinning automatico del thread, ma se parte del pinning è già stato effettuato dal programma di avvio MPI, l'implementazione OpenMP o il numero di core logici disponibili non corrisponde al numero dei thread totali utilizzati su un nodo, questo viene disattivato. In questo caso il pinning può essere attivato con l'opzione –pin on se il pinning non è effettuato dal programma di avvio MPI o dal sistema discontinuo.

SMT/HYPERTHREADING

Utilizzando tutti i core logici in un sistema (noto come SMT o Hyperthreading) si ottiene un leggero miglioramento delle prestazioni.

GPU BOOST

I kernel GPU di GROMACS non sfruttano l'intera potenza e il budget termico di una GPU. È quindi consigliabile e sicuro aumentare i clock GPU fino al massimo supportato tramite i clock dell'applicazione. A partire da GROMACS 5.1, tale operazione viene effettuata automaticamente dal gmx eseguibile se le impostazioni delle autorizzazioni dei clock dell'applicazione sono illimitate (UNRESTRICTED) e l'output è simile al seguente: "Changing GPU clock rates by setting application clocks for Tesla K80 to (2505,875)" e indica che la modifica delle velocità di clock delle GPU con l'impostazione a 2505,875 dei clock dell'applicazione per Tesla K80.

Nel caso in cui le autorizzazioni clock siano impostate su LIMITATE, GROMACS lo segnala con un output simile a questo:

Not possible to change GPU clocks to optimal value because of insufficient permissions to set application clocks for Tesla K80 (Impossibile modificare i clock GPU sul valore ottimale a causa delle autorizzazioni insufficienti per impostare i clock dell'applicazione per Tesla K80). Current values are (2505,562) (I valori attuali sono (2505,562)). Max values are (2505,875) Use sudo nvidia-smi -acp UNRESTRICTED or contact your admin to change application clock permissions" e indica che i valori correnti sono 2505,562 valori attuali e che occorre utilizzare sudo nvidia-smi -acp UNRESTRICTED o rivolgersi all'amministratore per modificare le autorizzazioni dei clock dell'applicazione.

Come indicato nel messaggio di avvertenza che si può utilizzare

$ sudo nvidia-smi -acp UNRESTRICTED

per modificare le autorizzazioni clock dell'applicazione su UNRESTRICTED.

Se la build GROMACS non include il GDK, GROMACS fornirà una segnalazione simile a questa:

"GROMACS was configured without NVML support hence it can not exploit
application clocks of the detected Tesla K80 GPU to improve performance", ossia "GROMACS è configurato senza supporto NVML, quindi non può sfruttare i clock dell'applicazione della GPU Tesla K80 per incrementare le prestazioni".
Ricompilare con la libreria NVML (compatibile con il driver usato) o impostare manualmente i clock dell'applicazione.

In questo caso è possibile configurare manualmente il boost clock max con il comando simile a quello sotto. Attenzione: l'impostazione clock max sarà diversa per le diverse GPU.

$ nvidia-smi -ac 2505,875       # numero massimo di clock per GPU K80

Per ulteriori dettagli sul boost tramite GPU, fare riferimento a Incremento delle prestazioni con il boost della GPU e GPU e Autoboost K80.

AGGIORNAMENTI DELLE LISTE VICINI

Quando è utilizzato lo schema di cutoff Verlet (richiesto per l'accelerazione GPU) l'intervallo di aggiornamento per le liste vicini può essere selezionato liberamente. Se la ricerca della lista vicini richiede molto tempo, è possibile aumentare l'intervallo degli aggiornamenti della lista stessa. Il tempo per la ricerca della lista vicini è fornito in md.log (vedere il conteggio Script 2 Time per la ricerca lista vicini in md.log). Un probabile aumento richiesto del raggio di cutoff viene eseguito automaticamente. Poiché le liste vicini sono calcolate sulla CPU e il cutoff più lungo porta una maggiore aumento nel calcolo della Forza, nstlist trasferisce parte del carico dalla CPU alla GPU. Oltre alla lista vicini, il calcolo richiede la comunicazione tra i rank MPI in modo che ciò trasferisca la comunicazione per il calcolo.

Computing: Num
Nodes
Num
Threads
Call
Count
Wall time
(s)
Giga-Cycles total sum %
[…]
Neighbor search 2 10 6480 32.464 1947.963 1.8
[…]
Total 1782.537 106957.655 100.0

OTTIMIZZAZIONE PME - BILANCIAMENTO DEL CARICO PP

[…]
Force evaluation time GPU/CPU: 4.972 ms/5.821 ms = 0.854
For optimal performance this ratio should be close to 1!
[…]

Script 3 PME bilanciamento del carico PP output in md.log

Come descritto sopra, deve essere bilanciato il carico tra i nodi PME e PP. Questo è abilitato in modo predefinito e può essere disattivato con il parametro –notunepme. Per il singolo processo GPU accelerata esegue il PP (GPU) / PME (CPU), il bilanciamento del carico è riportato nel file di output md.log (vedere lo Script 3 PME output bilanciamento del carico PP in md.log)

RANGHI PME SEPARATI

Interruzione del calcolo mesh PME

Breakdown of PME mesh computation
PME redist. X/F 2 10 518322 167.004 10020.730 9.4
PME spread/gather 2 10 518322 429.501 25771.381 24.1
PME 3D-FFT 2 10 518322 123.600 7416.369 6.9
PME 3D-FFT Comm. 2 10 518322 126.829 7610.103 7.1
PME solve Elec 2 10 259161 13.470 808.259 0.8

Conteggio Script 4 Time per l'attività PME task in md.log

La gestione di interazioni senza legame a lungo raggio con PME è un'attività di comunicazione intensa, perché richiede l'esecuzione di una FFT in 3D. Poiché le attività PP e PME sono indipendenti, GROMACS supporta l'avvio dei cosiddetti nodi PME separati (processi che eseguono solo l'attività PME) per ridurre la pressione sulla rete in modalità MPMD. Di default il numero di rank PME è determinato automaticamente solo quando le GPU non sono utilizzate. Può essere ottimizzato con il parametro –npme. Se il tempo di comunicazione dell'attività PME riportato nel file di output md.log è elevato, occorre considerare la separazione PME. Questo avviene solitamente a partire da 3-4 nodi.

Vi sono due diverse opzioni per mappare i rank MPI sui nodi PP e PME che sono interessanti per le esecuzioni GPU accelerata di GROMACS:

  • l'interleaving dei nodi PME avviene con i cosiddetti nodi PP (i nodi PP stanno eseguendo l'attività Force) e questo carica maggiormente la rete, ma evita risorse inutilizzate. L'opzione della riga di comando è –ddorder interleave (predefinita per esecuzioni GPU accelerata).
  • I nodi PME sono raggruppati vicini tra loro. Questo riduce il carico sulla rete, ma lascia alcune GPU inattive. L'opzione della riga di comando è –ddorder pp_pme (predefinita solo per esecuzioni CPU).

CONDIVISIONE DI UNA GPU TRA PROCESSI
MULTIPLI E IL MULTI PROCESS SERVICE (MPS)

In molte situazioni la condivisione di una GPU tra rank MPI multipli può migliorare le prestazioni.

Nel caso di nodo singolo con build di GROMACS senza MPI, questo può essere supportato semplicemente tramite thread-MPI usando l'opzione -ntmpi e i parametri e impostando semplicemente (o lasciando che lo faccia GROMACS) -ntmpi in modo che esegua 2 o più rank MPI per GPU.

Per le esecuzioni multi-nodo e MPI build di GROMACS, la condivisione di una GPU è possibile su GPU con una capacità di calcolo di 3,5 tramite il Multi Process Service (MPS). Questo richiede l'impostazione delle GPU usate sulla modalità di processo esclusiva e l'avvio di un daemon di controllo MPS su ogni nodo (nvidia-cuda-mps-control):

#!/bin/bash
sudo nvidia-smi -c 3
nvidia-cuda-mps-control -decho " -started nvidia-cuda-mps-control on `hostname`"

Esempio di script per avviare un MPS su nodo singolo

#!/bin/bash
echo quit | nvidia-cuda-mps-control
sudo nvidia-smi -c 0
echo " stopping MPS on `hostname`"

Esempio di script per interrompere un MPS su nodo singolo

Maggiori informazioni sull'MPS sono riportate qui.

OPZIONI AVANZATE

Sono disponibili impostazioni di decomposizione dominio più avanzate. Per sistemi disomogenei (per es. #atomi per dominio), la cui ottimizzazione può migliorare ulteriormente le prestazioni. Consultare il Manuale GROMACS o la mailing list degli utenti GROMACS per ulteriori informazioni.

Declinazione di responsabilità

*GROMACS include numerose opzioni per ottimizzare le prestazioni di elaborazione di diversi input in varie architetture o sistemi. Le istruzioni sono impostate in modo da coprire gli aspetti più importanti per le GPU accelerate GROMACS.

ESEMPI DETTAGLIATI

In questa sezione sono descritti alcuni esempi per l'esecuzione di GROMACS. I set di dati input usati per questi esempi sono disponibili qui.

Per cominciare, occorre scaricare e estrarre l'archivio

$ wget ftp://ftp.gromacs.org/pub/benchmarks/water_GMX50_bare.tar.gz
$ tar -zxvf water_GMX50_bare.tar.gz

Questi dati comprendono dati "acqua" di diversi formati con nomi di cartelle come 0384, 0768 e 1536. Il nome della cartella corrisponde al numero degli atomi in migliaia, vale a dire che la cartella 0768 conterrà un caso con 256 mila molecole di acqua e 768 mila atomi. Il primo passaggio serve a preparare i dati usando il tool grompp.

Per esempio, utilizzare i seguenti comandi per eseguire il caso 1536. Utilizzare pme.mdp se si desidera fare ricorso al Particle Mesh Ewald (PME). L'esecuzione del comando seguente genererà il file topol.tpr che è usato come input per il GROMACS mdrun.

$ cd water-cut1.0_GMX50_bare/1536
$ gmx grompp -f pme.mdp

Qui di seguito sono riportate diverse variazioni per l'esecuzione di GROMACS con e senza GPU su 1 o 2 nodi e rappresentano una sottosezione dei casi che dovevano essere eseguiti per raccogliere i risultati di esempio riportati alla fine di questa sezione.

Il numero dei rank MPI utilizzato negli esempi GPU dipende dal numero di GPU del sistema e dal numero dei rank MPI per GPU. In molti casi l'esecuzione di più di 1 rank MPI per GPU migliora le prestazioni. Questo è possibile usando il thread-MPI per l'esempio del nodo singolo ed è anche reso possibile utilizzando la funzione CUDA MPS nel caso di esecuzione di nodi multipli. Alcuni ulteriori dettagli su CUDA MPS descritti nella presente guida.

Si consiglia normalmente di avere da 2 a 6 thread OMP per ogni rank quando si usano le GPU. -ntomp o la variabile OMP_NUM_THREADS può essere usata per specificare il numero desiderato di thread OMP per rank. Solitamente sono necessari alcuni esperimenti per regolare il numero di rank MPI rispetto al numero di thread per rank per capire quale funzioni al meglio per una determinata configurazione di sistema e per determinati dati di input.

Negli esempi 1, 2 e 4 riportati sotto sono usati 2 Tesla K80, che sono 4 GPU (2 schede K80) per nodo.

5 esempi sono esecuzioni su nodi con 2 CPU socket Haswell

  • 32 core in totale
  • hyperthreading disabilitato

Esempio 1. I parametri di avvio (ntmpi e ntomp) non sono specificati, quindi GROMACS stabilirà automaticamente quanti rank MPI per GPU e quanti thread OMP per rank lanciare.

Esecuzione su un nodo singolo con 4 GPU utilizzando thread-MPI, con GROMACS che determina automaticamente i parametri di avvio (ntmpi, ntomp).

$ GROMACS_BIN_DIR/gmx mdrun -resethway -noconfout -nsteps 4000 -v -pin on -nb gpu

Se si ha il tempo per effettuare prove, si possono provare le combinazioni possibili di rank MPI per GPU e di thread OMP per rank per vedere quale sia la migliore. Le opzioni disponibili dipendono dal numero totale di core CPU e dal numero di GPU per nodo. Per esempio, se si hanno 4 GPU/nodo con 32 core VPU per nodo, è possibile provare le combinazioni riportate qui di seguito per verificare se forniscono le migliori prestazioni.

-ntmpi 4 -ntomp 8 # 1 rank per GPU with 8 threads per rank
-ntmpi 8 -ntomp 4 # 2 MPI ranks per GPU with 4 threads per rank
-ntmpi 16 -ntomp 2 # 4 MPI ranks er GPU with 2 threads per rank

Per gli esempi 2-5 qui di seguito, i casi selezionati forniscono il migliore risultato sul sistema di test benchmark.

Esempio 2. Esecuzione su un nodo singolo con 4 GPU, 4 OMP thread/rank, 8 rank, 2 rank MP per GPU usando thread-MPI

$ GROMACS_BIN_DIR/gmx mdrun -ntmpi 8 -ntomp 4 -resethway -noconfout -nsteps 4000 -v -pin on -nb gpu

Esempio 3. Esecuzione su un nodo singolo con soli core CPU, 1 OMP thread/rank, 32 rank, usando thread-MPI

$ $GROMACS_BIN_DIR/gmx mdrun -ntmpi 32 -ntomp 1 -resethway -noconfout -nsteps 4000 -v -pin on -nb cpu

Esempio 4. Esecuzione su 2 nodi con 4 GPU/nodo, 2 OMP thread/rank, 16 rank per nodo, 4 rank MPI per GPU usando CUDA MPS per consentire rank MPI multipli per GPU:

$ OMP_NUM_THREADS=2 mpirun -np 32 $GROMACS_BIN_DIR/gmx_mpi mdrun -resethway -noconfout -nb gpu -nsteps 8000 -v -pin on

Esempio 5. Esecuzione su 2 nodi con soli core CPU, 1 OMP thread/rank, 32 rank per nodo

$ OMP_NUM_THREADS=1 mpirun -np 64 $GROMACS_BIN_DIR/gmx_mpi mdrun -resethway -noconfout -nb cpu -nsteps 8000 -v -pin on

Benchmark

Questa sezione descrive le prestazioni con più GPU in un singolo nodo. Il benchmark, inoltre, riporta le prestazioni di 1, 2 e 4 nodi utilizzando due schede GPU Tesla P100 per nodo. Ogni scheda P100 include una singola GPU Pascal. Le esecuzioni sono avvenute utilizzando alcune varianti delle righe di comando descritte precedentemente per dimensioni dati acqua 0768, 1536 e 3072.

Prestazioni singolo nodo 768K molecole d'acqua
Prestazioni singolo nodo 1,5M molecole d'acqua
Prestazioni singolo nodo 3M molecole d'acqua
Prestazioni scalabili 3M molecole d'acqua

Configurazioni del sistema consigliate

Configurazione hardware

PC

Parameter
Specs

CPU Architecture

x86

System Memory

16-32GB

CPUs

8 Cores, 8 GHz
10 Cores, 2.2 GHz
16 Cores, 2GHz

GPU Model

NVIDIA TITAN X

GPUs

1-2 TITAN X

Servers

Parameter
Specs

CPU Architecture

x86

System Memory

32GB

CPUs/Nodes

2 (16+ cores, 2+ GHz)

GPU Model

NVIDIA® Tesla® P100

GPU/Node

1-2 Tesla GPU cards

Interconnect

InfiniBand

Configurazione software

Software stack

Parameter
Version

OS

Linux

GPU Driver

352.79 or newer

CUDA Toolkit

7.5 or newer

Compiler

GCC 5.0

Crea la tua soluzione GPU ideale oggi stesso.