少し間が空いてしまいました。
今回の記事では、引き続き Compiler について書いていきます。
今回の記事は前回からの続きとなりますので、未読の方はぜひこちらをご覧ください。
- パフォーマンスが一定以上出るかどうか
前回の記事でも書きましたが、ここで言う、
「パフォーマンスが一定以上出る」
という表現は、
「他のCompilerと比較してパフォーマンスが極端に低くない」
という意味であり、最適（最速）な組み合わせを求めているわけではありません。
特定の Compiler によって、性能が大きく劣化してしまうケースは、
前回述べた、動作そのものが不安定になるケースよりは数が少ないです。
Compiler によって性能が大きく劣化してしまうケースで、過去に体験したことがあるのは以下のような場合でした。
- IntelMKLを使用している場合（IntelCompiler 限定）
計算科学アプリケーションで IntelCompiler に対応している場合、
数値演算ライブラリとしてMKLを使用するケースが非常に多いです。
MKL は数値演算ライブラリとして非常に優秀な性能を示しますが、
新しいCPUと古いMKL（ IntelCompiler )の組み合わせの場合、
MKLがCPUアーキテクチャに対応していない事があります。
このような場合、新しいMKLに比べ、性能が非常に低下する事があります。 - 特定の環境（Compiler、CPU等）向けに作りこまれている場合
公開されているアプリケーションの中には、開発陣が非常に作りこんでいて、
性能を最大限高めるためにソースコードやビルド時のオプションまで細かく調整されているものがあります。
非常に稀なケースになりますが、そのようなアプリで、
開発元が想定していない Compiler を使用した場合、十分な性能が出ないことがあります。
〇 まとめ
アプリケーションを安定動作させるためのコツをまとめてみたいと思います。
１．対象のアプリケーションを開発元が検証している環境（OS、Compiler、MPI等）を調査し、
手元の環境で再現できるかどうか検討する
今まで話してきた通り、開発元がアプリケーションを開発、検証している環境を調べ、
その環境に可能な限り合わせる、という事が、安定動作させるための基本的方針になります。
そのため、まず、アプリケーション開発陣の開発環境を調べ、その環境がどの程度、
手元の環境で再現できるか検討します。
２．手元環境に開発元の検証環境が再現できる場合には、環境を合わせて検証を行う。
特に今まで検証したことのないアプリケーションの場合、
まず開発元の環境で動作検証を行い、確実に動作するバイナリを作成することを目的とします。
手元の環境で、最終的に使用したい希望環境が明確にイメージできている場合でも、
まず開発元の環境で検証を行い、正常に動作するアプリケーションをビルドした後、
環境を少しずつ（１つずつ）変えていくと、問題が起きた場合に対応しやすくなります。
３．手元環境に開発元の検証環境が再現できない場合、
アプリケーションによっては、既に開発が止まっていたり、
前回の更新から長い年月が立っている場合があります。
この場合には、開発元の検証環境が現在のハードウェア、OS環境と合わないため、
開発当時の環境をそのまま使用することは難しくなります。
このようなケースでは、開発元検証環境で使用されていた
OS、Compiler、MPI について、同系統の現行Versionを選択する事が無難です。
例）
開発元環境： CentOS 5.6 – IntelCompiler v15.0.3 – OpenMPI v1.5.3
検証環境： CentOS 7.5 – IntelCompiler v19.0.4 – OpenMPI v3.1.4
上記に例に挙げたケースのように、
アプリケーションの検証環境と現在の環境が大きくずれている場合、
安定動作するバイナリをビルドする事が非常に困難なケースもあります。
この場合、トラブルが発生した際に出るエラーメッセージを参照し、
原因を推測、対策を行っていくことになります。
トラブルの原因として多い要因として、
ソースコードが現在の Compiler、MPI の規格にあっていない、等が挙げられますが、
この原因追及、対策は状況により変わってきますので、
難易度が高く、ある程度の経験が必要になるかもしれません。
最近は、仮想マシンやコンテナ技術が進歩していますので、
どうしても古いアプリケーションを動作させたい場合、
これらを利用して、該当アプリケーションの開発環境を再現してしまうのも
良いかもしれません。
前回、今回とアプリケーションビルド時のCompilerの選択について説明してきました。
正直な話、こういう場合にはこうすれば解決する、という特効薬的な解決策はありませんが、
アプリケーションの開発陣が開発している環境を参考に、可能な限り合わせる、
ということを考慮すれば、トラブルは減るのではないかと考えます。
