パフォーマンス改善¶
GPUの改善¶
上記に加えて、全体的な軽微な改善によりCUDAのパフォーマンスが最大5%向上します。したがって、パラメータやコンパイラによっては、GPUカーネルのパフォーマンスが5〜20%向上すると予想されます。これらの効果は、CUDA 7.5（現在推奨するバージョン）で確認できます。また、一部の古いバージョン（例：7.0）では、さらに大きな改善が見られます。
AMDデバイスにおけるOpenCLのパフォーマンスに関するさらなる改善が期待されており、例えば、RF/プレーンカットオフとPMEを使用することで、50%以上の改善が見られる可能性があります。また、最近のAMD OpenCLコンパイラを使用した場合、パフォーマンスが向上する可能性があります。
注意：NVIDIA OpenCLコンパイラには制限があるため、CUDAはNVIDIA GPU上で依然として優れたパフォーマンスを発揮します。したがって、NVIDIAハードウェアではCUDAベースのGPUアクセラレーションの使用が推奨されます。
OpenCLデバイスのサポートが改善されました¶
OpenCL のサポートは、MPI、スレッドとMPI、および PP レベルでの GPU の共有を含む、すべてのインnitřおよびインターノード並列化モードと完全に互換性があります。 (以前の制限は、GROMACS の高レベルコード内のバグによって引き起こされました。)
さらに、短距離範囲のカーネル（CUDAコードにあるものと同様）で、これまで無効になっていた一部の事前読み込み機能が、実際に有効にすることで効果があることが判明しました。
GPU用のレンナー・ジョーンズの組み合わせルールカーネルを追加¶
CUDAおよびOpenCLカーネルにおいて、幾何学的およびローレンツ-ベルテローの組み合わせルールの両方に対して、LJ組み合わせルールのパラメータ検索を実装し、平坦なLJカットオフにも有効化しました。この最適化は、CPUカーネルにも存在していました。これにより、OPLS、GROMOS、AMBERなどの力場に対して、約10〜15%のパフォーマンスが向上します（ただし、CHARMM力場には効果がありません。なぜなら、CHARMM力場はスイッチングされたカーネルを使用しているためです）。
CUDA CC 6.0/6.1 のサポートを追加¶
これまでに発表され、CUDA 8.0コンパイラによってサポートされている Pascal アーキテクチャ (GP100: 6.0, GP104: 6.1) 用のビルドシステムおよびカーネル生成機能を追加しました。
デフォルトでは、sm_60 と sm_61 の両方に対して、バイナリコードと PTX コードの両方を生成します。また、両方の仮想アーキテクチャに対して PTX コードを生成します。現時点では、CC 6.2 (GP102) のコンパイルをサポートしていませんが、その理由は不明です。
カーネル生成側では、レジスタファイルの増加に伴い、CC 6.0 では「より広範な」128スレッド/ブロックのカーネルが有効になります。6.1以降では、64スレッド/ブロックが引き続き使用されます。
GPUペアのリスト分割を改善し、パフォーマンスを向上¶
代わりに、最大分割点に基づいてGPUリストを分割するのではなく、ターゲットリストサイズにできるだけ近いリストを生成するように変更しました。クラスタペアの推定値が10%から0～1%に調整され、これにより、ペアリストの数がわずかに少なくなりますが、それでも要求された数よりもわずかに多くなります。
CUDA GPU メモリ構成の改善¶
これにより、対応するハードウェア (K40、K80、Tegra K1、および CC 5.2) で利用可能な L1 キャッシュのより大きな容量を、グローバルなロード キャッシュに活用できます。そのため、適切なコマンドラインオプション ("-dlcm=ca") を指定します。
Intel Knight's Landing向けに、nstlistの自動変更が最適化されました。¶
CPU の改善¶
これらの個々のカーネルの改善は、それらがアクティブな場合に、シミュレーションのCPUパフォーマンスに段階的な改善をもたらしますが、GPUオフロードを使用するシミュレーションでは、特に高い価値があります。なぜなら、自動チューニングにより、さまざまなリソースの利用とスループットを向上させることができるからです。
Invalid section title or transition marker.¶
結合相互作用のマルチスレッディングのためのコードは、最後に力を結合する必要があります。この最適化では、32個の原子の固定サイズのブロックを使用し、ブロック全体をスレッド間で均等に分割するのではなく、使用されているブロックのみを均等に分割します。これにより、ドメイン分割を使用しない場合、典型的なタンパク質+水系の計算速度がスレッド数 (!) 倍に向上します。ドメイン分割を使用した場合、速度向上率は最大3倍になります。
SIMDによる結合された力削減にSIMDによる転置-スプレッドを使用¶
角度と二次元SIMD関数は、SIMD転置スプレッド関数を使用して、力の削減を実現します。この変更により、特に結合された分子に対して、大幅なパフォーマンス向上が得られます。これは、二次元力の更新が、以前はSIMDを使用せずに多くのベクトル演算を行っていたため、SIMD演算によって完全に置き換えられたためです。
Lennard-Jones 1-4 の相互作用に対する SIMD 実装を追加¶
これにより、いくつかの要因による速度向上が得られます。主な改善は、表ではなく、簡略化された解析的なLJを使用することによるもので、SIMDもわずかに貢献しています。
SETTLEのSIMD実装を追加¶
ハッセルプロセッサでは、これによりSETTLEの処理速度が5倍向上します。
周期境界座標変換ルーチン用のSIMDサポートを追加¶
スレッドの改善¶
これらの改善により、複数のCPUスレッドで実行されるコードのパフォーマンスが向上します。
Verletスキームを用いたペアリストのワークロードバランスの改善¶
VerletスキームのCPUペアリストに対するほぼ完璧なロードバランシングを実装しました。これにより検索コストが3%増加しますが、特に小さなシステムでは、よりバランスの取れた非相互作用カーネルの実行時間が大幅に短縮されるため、この増加は相殺されます。
仮想サイトコードの並行処理を改善¶
多くのスレッドにおいて、多くのvsitesが個別のシリアルタスクに割り当てられるため、スケーラビリティが制限される。現在、各スレッドに対して2つの弱依存関係のあるタスクが生成され、そのうちの1つがスレッドローカルのフォースバッファを使用し、異なるスレッドがそれぞれの部分を処理します。
また、設定の実行もマルチスレッド化されました。
より多くのループにOpenMPのサポートを追加¶
多数のスレッドを使用すると、アトミック操作の回数が多くなり、結果としてシリアル実行時間が大幅に増加し、スケーラビリティが制限されます。
OpenMPによる並列化をpullコードに追加¶
大規模なプルグループを用いたOpenMP並列シミュレーションにおいて、プルコードの実行に最大3分の1の計算時間がかかる場合があります。現在、すべてのプルコードループ（アトームに対するループ）にはOpenMP並列版が実装されています。
その他の改善¶
複数のシミュレーションが、より頻繁に連携されなくなる¶
例えば、レプリカ・エクスチェンジシミュレーションは、交換試行時にのみシミュレーション間で通信を行います。通常のマルチシミュレーションは、シミュレーション間で通信しません。全体的なパフォーマンスは、あるシミュレーションの進行が他のシミュレーションよりも速い場合に改善する傾向があります（たとえば、異なる圧力を使用している場合、またはネットワークの別の部分を使用している場合）。