コレクタが収集するデータの内容

コレクタは、プロファイルデータ、トレースデータ、および大域データの 3 種類のデータを収集します。

• プロファイルデータの収集は、一定の間隔でプロファイルイベントを記録することによって行います。間隔は、システム時間を使用して取得した時間間隔、または特定のタイプのハードウェアイベントの数です。指定の間隔に達すると、シグナルがシステムに送られ、次の機会にデータが記録されます。

• トレースデータの収集は、さまざまなシステム関数をラッパー関数で割り込み、それによってシステム関数の呼び出しをインターセプトし、呼び出しに関するデータを記録することによって行います。

• 大域データの収集は、さまざまなシステムルーチンを呼び出して情報を取得することによって行います。大域データパケットのことを標本と呼びます。

プロファイルデータとトレースデータの両方が特定のイベントに関する情報を含んでおり、いずれのデータの種類もパフォーマンスメトリックスに変換されます。大域データはメトリックスに変換されませんが、プログラムの実行を複数のタイムセグメントに分割するために使用できるマーカーを提供します。大域データは、タイムセグメントにおけるプログラム実行の概要を示します。

それぞれのプロファイルイベントやトレースイベントで収集されたデータパケットには、次の情報が含まれます。

• データ識別用のヘッダー

• 高分解能のタイムスタンプ

• スレッド ID

• 軽量プロセス (LWP) ID

• プロセッサ (CPU) ID (オペレーティングシステムから提供できる場合)

• 呼び出しスタックのコピー。Java プログラムの場合、マシン呼び出しスタックと Java 呼び出しスタックの 2 つの呼び出しスタックが記録されます。

• OpenMP プログラムの場合、現在の並行領域の識別子と、OpenMP の状態も収集されます。

スレッドと軽量プロセスについての詳細は、第 6 章パフォーマンスアナライザとそのデータについてを参照してください。

こうした共通の情報のほかに、各イベントに固有のデータパケットには、データの種類に固有の情報が含まれます。コレクタが記録できるデータは、次の 5 種類です。

• 時間プロファイルデータ

• ハードウェアカウンタのオーバーフロープロファイルデータ

• 同期待ちトレースデータ

• ヒープトレース (メモリー割り当て) データ

• MPI トレースデータ

これらの 5 種類のデータ、それらから派生したメトリックス、およびメトリックスの使用方法については、あとの項で説明します。6 種類目のデータ、大域標本データには呼び出しスタック情報が含まれないため、メトリックスに変換できません。

時間データ

時間ベースのプロファイル時に収集されるデータは、オペレーティングシステムが提供するメトリックスによって異なります。

Solaris OS での時間ベースのプロファイル

Solaris OS での時間ベースのプロファイルでは、各 LWP の状態が定期的な間隔で格納されます。この時間間隔は、プロファイル間隔と呼ばれます。この情報は整数の配列に格納されます。その配列の 1 つの要素は、カーネルによって維持される 10 個のマイクロアカウンティングの各状態に使用されます。収集されたデータは、各状態で消費された、プロファイル間隔の分解能を持つ時間値に、パフォーマンスアナライザによって変換されます。デフォルトのプロファイル間隔は、約 10 ミリ秒 (10 ms) です。コレクタは、約 1 ミリ秒の高分解能プロファイル間隔と、約 100 ミリ秒の低分解能プロファイル間隔を提供し、OS で許されれば任意の間隔を許可します。引数を付けずに collect コマンドを実行すると、このコマンドが実行されるシステム上で許される範囲と分解能が出力されます。

次の表に、時間ベースのデータから計算されるメトリックスの定義を示します。

マルチスレッドの実験では、すべての LWP にまたがって実経過時間以外の時間が集計されます。定義した時計時間は、MPMD (Multiple-Program Multiple-Data) プログラムには意味がありません。

タイミングメトリックスは、プログラムがいくつかのカテゴリで時間を費やした部分を示し、プログラムのパフォーマンス向上に役立てることができます。

• ユーザー CPU 時間が大きいということは、その場所で、プログラムが仕事の大半を行なっていることを示します。この情報は、アルゴリズムを再設計することによって特に有益となる可能性があるプログラム部分を見つけるのに使用できます。

• システム CPU 時間が大きいということは、プログラムがシステムルーチンに対する呼び出しで多くの時間を使用していることを示します。

• CPU 待ち時間が大きいということは、使用可能な CPU 以上に実行可能なスレッドが多いか、ほかのプロセスが CPU を使用していることを示します。

• ユーザーロック時間が大きいということは、要求対象のロックをスレッドが取得できないことを示します。

• テキストページフォルト時間が大きいということは、リンカーによって指定されたコードが、多数の呼び出しまたは分岐で新しいページの読み込みが発生するようなメモリー上の配置になることを意味します。

• データページフォルト時間が大きいということは、データへのアクセスによって新しいページの読み込みが発生していること示します。この問題は、プログラムのデータ構造またはアルゴリズムを変更することによって解決できます。

Linux OS での時間ベースのプロファイル

Linux OS で利用できるメトリックは、ユーザー CPU 時間だけです。報告される合計 CPU 使用時間は正確ですが、アナライザは Solaris OS の場合ほど正確に実際のシステム CPU 時間の割合を判別できない場合があります。アナライザは軽量プロセス (LightWeight Process、LWP) のデータであるかのように情報を表示しますが、実は Linux OS 上に LWP はなく、表示される LWP ID は実際にはスレッド ID です。

MPI プログラム対応の時間ベースのプロファイル

時間プロファイリングデータは、Oracle Message Passing Toolkit (以前の Sun HPC ClusterTools) で実行される MPI 実験で収集できます。Oracle Message Passing Toolkit はバージョン 8.1 またはそれ以降である必要があります。

Linux で Oracle Message Passing Toolkit 8.2 または 8.2.1 を使用する場合、回避策が必要になる場合があります。バージョン 8.1 または 8.2.1c の場合、または Oracle Solaris Studio コンパイラを使用している場合はどのバージョンでも回避策は必要ありません。回避策については、docs.sun.com の Oracle Solaris Studio 12.2 Collection - Japanese 内の『Oracle Solaris Studio 12.2 リリースの新機能』を参照してください。

MPI 実験で時間プロファイリングデータを収集すると、次の 2 つのメトリックスが追加されます。

• MPI 作業: 要求やメッセージの処理など、プロセスが MPI ランタイム実行作業の内部にある場合に蓄積されます。

• MPI 待機: プロセスが MPI ランタイムの内部にあり、イベント、バッファー、またはメッセージを待機している場合に蓄積されます。

Solaris OS では、MPI 作業は作業が直列または並列に実行される場合に蓄積されます。MPI 待機は、MPI ランタイムが同期化を待機している間に蓄積され、待機が CPU 時間ないしスリーピングのいずれかを使用しているか、または作業が並列実行中であるがスレッドは CPU 上にスケジュールされていない場合に、蓄積されます。

Linux OS では、MPI 作業および MPI 待機は、プロセスがユーザーモードまたはシステムモードでアクティブになっている場合にのみ蓄積されます。MPI がビジーウェイトを行う必要があるものとして指定しないかぎり、Linux での MPI 待機は有用ではありません。

OpenMP プログラム対応の時間ベースのプロファイル

時間ベースのプロファイルが OpenMP プログラムで実行される場合は、OpenMP 作業および OpenMP 待機という 2 つの追加メトリックスが提供されます。

Solaris OS では、OpenMP 作業は作業が直列または並列に実行される場合に蓄積されます。OpenMP 待機は、OpenMP ランタイムが同期化を待機している場合に蓄積し、待機が CPU 時間かスリーピングを使用しているか、または作業は並行してなされるがスレッドが CPU 上でスケジュールされていない場合に蓄積します。

Linux OS では、OpenMP 作業および OpenMP 待機は、プロセスがユーザーモードまたはシステムモードでアクティブになっている場合にのみ蓄積されます。OpenMP でビジーウェイトを行う必要があるものとして指定しないかぎり、Linux での OpenMP は有用ではありません。

ハードウェアカウンタオーバーフローのプロファイルデータ

ハードウェアカウンタは、キャッシュミス、キャッシュストールサイクル、浮動小数点演算、分岐予測ミス、CPU サイクル、および実行対象命令といったイベントの追跡に使用されます。ハードウェアカウンタオーバーフローのプロファイルでは、LWP が動作している CPU の特定のハードウェアカウンタがオーバーフローしたときに、コレクタはプロファイルパケットを記録します。この場合、そのカウンタはリセットされ、カウントを続行します。プロファイルパケットには、オーバーフロー値とカウンタタイプが入っています。

各種の CPU ファミリが 2 潤ｵ 18 個の同時ハードウェアカウンタレジスタをサポートしています。コレクタは、複数のレジスタ上でデータを収集できます。コレクタではレジスタごとに、オーバーフローを監視するカウンタの種類を選択し、カウンタのオーバーフロー値を設定することができます。ハードウェアカウンタには、任意のレジスタを使用できるものと、特定のレジスタしか使用できないものがあります。このことは、1 つの実験であらゆるハードウェアカウンタの組み合わせを選択できるわけではないことを意味します。

パフォーマンスアナライザは、ハードウェアカウンタのオーバーフロープロファイルデータをカウントメトリックスに変換します。循環型のカウンタの場合、報告されるメトリックスは時間に変換されます。非循環型のカウンタの場合は、イベントの発生回数になります。複数の CPU を搭載したマシンの場合、メトリックスの変換に使用されるクロック周波数が個々の CPU のクロック周波数の調和平均となります。プロセッサのタイプごとに専用のハードウェアカウンタセットがあり、またハードウェアカウンタの数が多いため、ハードウェアカウンタメトリックスはここに記載していません。次の項で、どのような種類のハードウェアカウンタがあるかについて調べる方法を説明します。

ハードウェアカウンタの用途の 1 つは、CPU に出入りする情報フローに伴う問題を診断することです。たとえば、キャッシュミス回数が多いということは、プログラムを再構成してデータまたはテキストの局所性を改善するか、キャッシュの再利用を増やすことによってプログラムのパフォーマンスを改善できることを意味します。

ハードウェアカウンタはほかのカウンタと関連する場合があります。たとえば、分岐予測ミスが発生すると、間違った命令が命令キャッシュに読み込まれ、これらの命令を正しい命令と置換しなければならなくなるため、分岐予測ミスと命令キャッシュミスが関連付けられることがよくあります。置換により、命令キャッシュミス、命令変換索引バッファー (Instruction Translation Look aside Buffer、ITLB) ミス、またはページフォルトが発生する可能性があります。

ハードウェアカウンタのオーバーフローは、イベントを発生させて対応するイベントのカウンタをオーバーフローにした命令のあとに、1 つ以上の命令で実現される傾向があります。これは「滑り止め」と呼ばれ、カウンタオーバーフローのプロファイルを解釈しにくくする可能性があります。原因となる命令を正確に識別するためのハードウェアサポートがないと、候補の原因となる命令の適切なバックトラッキング検索が行われる場合があります。

そのようなバックトラッキングが収集中にサポートされて指定されると、ハードウェアカウンタプロファイルパケットにはさらに、ハードウェアカウンタイベントに適した候補の、メモリー参照命令の PC (プログラムカウンタ) と EA (有効アドレス) が組み込まれます。解析中の以降の処理は、候補のイベント PC と EA を有効にするのに必要です。このメモリー参照イベントに関する追加情報により、データ空間プロファイリングと呼ばれるさまざまなデータ指向解析が容易になります。バックトラッキングは、Oracle Solaris オペレーティングシステムを実行している SPARC ベースのプラットフォームでのみサポートされます。

候補のイベント PC および EA のバックトラッキングと記録は、時間プロファイルに対しても指定できますが、解釈しにくい場合があります。

ハードウェアカウンタのリスト

ハードウェアカウンタはプロセッサ固有であるため、どのカウンタを利用できるかは、使用しているプロセッサによって異なります。パフォーマンスツールには、よく使われると考えられるいくつかのカウンタの別名が用意されています。コレクタから特定システム上で利用できるハードウェアカウンタの一覧を取り出すには、引数を付けないで collect をそのシステム上の端末ウィンドウに入力します。プロセッサとシステムがハードウェアカウンタプロファイルをサポートしている場合、collect コマンドは、ハードウェアカウンタに関する情報が入った 2 つのリストを出力します。最初のリストには一般的な名称に別名が設定されたハードウェアカウンタが含まれ、2 番目のリストには raw ハードウェアカウンタが含まれます。パフォーマンスカウンタサブシステムも collect コマンドも特定システムのカウンタの名前を知らない場合、各リストは空になります。ただしほとんどの場合、カウンタは数値で指定できます。

次に、カウンタリストに含まれるエントリの表示例を示します。別名が設定されたカウンタがリストの最初に表示され、続いて raw ハードウェアカウンタリストが表示されます。この例の出力における各行は、印刷用の形式になっています。

Aliased HW counters available for profiling:
cycles[/{0|1}],9999991 (’CPU Cycles’, alias for Cycle_cnt; CPU-cycles)
insts[/{0|1}],9999991 (’Instructions Executed’, alias for Instr_cnt; events)
dcrm[/1],100003 (’D$ Read Misses’, alias for DC_rd_miss; load events)
...
Raw HW counters available for profiling:
Cycle_cnt[/{0|1}],1000003 (CPU-cycles)
Instr_cnt[/{0|1}],1000003 (events)
DC_rd[/0],1000003 (load events)

別名が設定されたハードウェアカウンタリストの形式

別名が設定されたハードウェアカウンタリストでは、最初のフィールド (たとえば、cycles) は、collect コマンドの -h counter... 引数で使用できる別名を示します。この別名は、 er_print コマンド内で使用する識別子でもあります。

リストの 2 番目のフィールドには、そのカウンタに使用可能なレジスタ、たとえば、[/{0|1}] が示されます。

3 番目のフィールドは、たとえば 9999991 など、カウンタのデフォルトのオーバーフロー値です。別名が設定されたカウンタの場合は、合理的なサンプルレートを提供するためにデフォルト値が選択されています。実際のレートは、かなり変化するため、デフォルト以外の値を指定する必要がある場合もあります。

4 番目のフィールドは、括弧で囲まれ、タイプ情報を含んでいます。これは、簡単な説明 (CPU Cycles など)、raw ハードウェアカウンタ名 (Cycle_cnt など)、およびカウントされる単位の種類 (CPU-cycles など) を提供します。

タイプ情報の最初のワードが、

• load、store、または load-store のいずれかである場合、そのカウンタはメモリーに関連したものです。collect -h コマンド内でカウンタ名の前に + 符号を付ける (たとえば、+dcrm) ことにより、イベントの原因となった正確な命令と仮想アドレスを検索できます。+ 符号を使用すると、データ空間プロファイリングも使用可能になります。詳細については、「「データオブジェクト」タブ」、「「データレイアウト」タブ」、および「メモリーオブジェクトのタブ」を参照してください。

• not-program-related である場合、カウンタはほかのプログラムによって開始されたイベント、たとえば CPU 対 CPU のキャッシュスヌープなどを取り込みます。プロファイリングにカウンタを使用すると、警告が生成され、プロファイリングで呼び出しスタックが記録されません。

タイプ情報の 2 番目または唯一のワードが、

• CPU-cycles である場合は、そのカウンタを使用して時間ベースのメトリックを提供できます。そのようなカウンタについて報告されるメトリックスは、デフォルトでは包括的時間および排他的時間へ変換されますが、イベントカウントとして表示することもできます。

• events である場合、メトリックは包括的および排他的イベントカウントであり、時間へ変換できません。

この例の別名が設定されたハードウェアカウンタリストでは、タイプ情報に 1 ワードが含まれており、最初のカウンタの場合は CPU-cycles で、2 番目のカウンタの場合は、events となっています。3 番目のカウンタでは、タイプ情報に load events という 2 ワードが含まれています。

raw ハードウェアカウンタリストの形式

raw ハードウェアカウンタリストに含まれる情報は、別名設定されたハードウェアカウンタリストに含まれる情報のサブセットです。raw ハードウェアカウンタリスト内の各行には、cpu-track(1) によって使用された内部カウンタ名、そのカウンタを使用できるレジスタ番号 (単数または複数)、デフォルトのオーバーフロー値、およびカウンタ単位が含まれており、カウンタ単位は CPU-cycles か Events です。

カウンタがプログラムの実行に関連のないイベントを測定する場合、タイプ情報の最初のワードは not-program-related になります。そのようなカウンタの場合、プロファイリングで呼び出しスタックが記録されませんが、その代わりに、擬似関数 collector_not_program_related で使用された時間が示されます。スレッドと LWP ID は記録されますが、意味がありません。

raw カウンタのデフォルトのオーバーフロー値は 1000003 です。この値はほとんどの raw カウンタで最適でないため、raw カウンタを指定する際にオーバーフロー値を指定する必要があります。

同期待ちトレースデータ

マルチスレッドプログラムでは、たとえば 1 つのスレッドによってデータがロックされていると、別のスレッドがそのアクセス待ちになることがあります。このため、複数のスレッドが実行するタスクの同期を取るために、プログラムの実行に遅延が生じることがあります。これらのイベントは同期遅延イベントと呼ばれ、Solaris または pthread のスレッド関数の呼び出しをトレースすることによって収集されます。同期遅延イベントを収集して記録するプロセスを同期待ちトレースと言います。また、ロック待ちに費やされる時間を待ち時間と言います。

ただし、イベントが記録されるのは、その待ち時間がしきい値 (ミリ秒単位) を超えた場合だけです。しきい値 0 は、待ち時間に関係なく、あらゆる同期遅延イベントをトレースすることを意味します。デフォルトでは、同期遅延なしにスレッドライブラリを呼び出す測定試験を実施して、しきい値を決定します。こうして決定された場合、しきい値は、それらの呼び出しの平均時間に任意の係数 (現在は 6) を乗算して得られた値です。この方法によって、待ち時間の原因が本当の遅延ではなく、呼び出しそのものにあるイベントが記録されないようになります。この結果として、同期イベント数がかなり過小評価される可能性がありますが、データ量は大幅に少なくなります。

同期トレースは Java プログラムに対してはサポートされていません。

同期待ちトレースデータは、次のメトリックスに変換されます。

この情報から、関数またはロードオブジェクトが頻繁にブロックされるかどうか、または同期ルーチンを呼び出したときの待ち時間が異常に長くなっているかどうかを調べることができます。同期待ち時間が大きいということは、スレッド間の競合が発生していることを示します。競合は、アルゴリズムの変更、具体的には、ロックする必要があるデータだけがスレッドごとにロックされるように、ロックを構成し直すことで減らすことができます。

ヒープトレース (メモリー割り当て) データ

正しく管理されていないメモリー割り当て関数やメモリー割り当て解除関数を呼び出すと、データの使い方の効率が低下し、プログラムパフォーマンスが低下する可能性があります。ヒープトレースでは、C 標準ライブラリメモリー割り当て関数 malloc、realloc、valloc、memalign、および割り当て解除関数 free で割り込み処理を行うことによって、コレクタはメモリーの割り当てと割り当て解除の要求をトレースします。mmap への呼び出しはメモリー割り当てとして扱われ、これによって Java メモリー割り当てのヒープトレースイベントを記録することが可能になります。Fortran 関数 allocate および deallocate は C 標準ライブラリ関数を呼び出すため、これらのルーチンは間接的にトレースされます。

Java プログラムのヒーププロファイリングはサポートされません。

ヒープトレースデータは、次のメトリックスに変換されます。

ヒープトレースデータの収集は、プログラム内のメモリーリークを特定したり、メモリーの割り当てが不十分な場所を見つける上で役立ちます。

dbx デバッグツールなどで使用されることの多い、メモリーリークの別の定義では、メモリーリークとは、プログラムのデータ空間内のいずれかを指しているポインタを持たない、動的に割り当てられるメモリーブロックです。ここで使用されているリークの定義にはこの代替定義が含まれますが、ポインタが存在するメモリーも含まれます。

MPI トレースデータ

コレクタは、Message Passing Interface (MPI) ライブラリの呼び出しの際のデータを収集できます。

MPI トレースは、オープンソースの VampirTrace 5.5.3 リリースを使用して実装されます。これは次の VampirTrace 環境変数を認識します。

これらの変数については、Technische Universität Dresden Web サイトにある『Vampirtrace User Manual』を参照してください。

バッファーの制限に達したあとに発生する MPI イベントはトレースファイルに書き込まれないため、トレースが不完全になります。

この制限を撤廃してアプリケーションのトレースを完全なものにするには、VT_MAX_FLUSHES 環境変数を 0 に設定します。この設定を行うと、MPI API トレースコレクタは、バッファーがいっぱいになるたびにバッファーをディスクにフラッシュします。

バッファーのサイズを変更するには、VT_BUFFER_SIZE 環境変数を設定します。この変数の最適値は、トレース対象のアプリケーションによって異なります。小さな値を設定すると、アプリケーションに利用できるメモリーは増えますが、MPI API トレースコレクタによるバッファーのフラッシュが頻繁に行われるようになります。このようなバッファーのフラッシュによって、アプリケーションの動作が大幅に変化する可能性があります。その一方、大きな値 (2G など) を設定すると、MPI API トレースコントローラによるバッファーのフラッシュは最小限に抑えられますが、アプリケーションに使用できるメモリーは少なくなります。バッファーやアプリケーションデータを保持するために十分なメモリーを利用できない場合、アプリケーションの一部がディスクにスワップされて、アプリケーションの動作が大幅に変化する可能性があります。

次のリストに、データが収集される関数を示します。

MPI トレースデータは、次のメトリックスに変換されます。

MPI 時間は MPI 関数でかかった LWP 時間の合計です。MPI 状態の時間も収集される場合、MPI_Init および MPI_Finalize 以外のすべての MPI 関数については、MPI 作業時間と MPI 待機時間の合計が MPI 作業時間にほぼ等しくなるはずです。Linux では、MPI 待機および MPI 作業はユーザー CPU 時間とシステム CPU 時間の合計に基づきますが、MPI 時間は実際の時間に基づくため、数値は一致しません。

MPI のバイトおよびメッセージのカウントは、現在のところ 2 点間のメッセージについてのみ収集され、集合的な通信機能に関しては記録されません。MPI 受信バイト数は、すべてのメッセージで実際に受信したバイト数をカウントします。MPI 送信バイト数は、すべてのメッセージで実際に送信したバイト数をカウントします。MPI 送信数は送信したメッセージの数をカウントし、MPI 受信数は受信したメッセージの数をカウントします。

MPI トレースデータの収集は、MPI 呼び出しが原因となる可能性のある、MPI プログラム内のパフォーマンスの問題を抱えている場所を特定する上で役立ちます。パフォーマンスの問題となる可能性のある例としては、負荷分散、同期遅延、および通信のボトルネックがあります。

大域 (標本収集) データ

大域データは、コレクタによって標本パケットと呼ばれるパケット単位で記録されます。各パケットには、ヘッダー、タイムスタンプ、ページフォルトや I/O データなどのカーネルからの実行統計情報、コンテキストスイッチ、および各種のページの常駐性 (ワーキングセットおよびページング) 統計情報が含まれます。標本パケットに記録されるデータはプログラムに対して大域的であり、パフォーマンスメトリックスには変換されません。標本パケットを記録するプロセスを標本収集と言います。

標本パケットは、次の状況で記録されます。

• IDE のデバッグ中や dbx で、プログラムが何らかの理由 (ブレークポイントなど) により停止したとき (このためのオプションが設定されている場合)。

• 標本収集の間隔の終了時 (定期的な標本収集を選択している場合)。標本収集の間隔は整数値 (秒単位) で指定します。デフォルト値は 1 秒です。

• dbx collector sample record コマンドを使用し、標本を手動で記録したとき。

• このルーチンに対する呼び出しがコードに含まれている場合に collector_sample を呼び出したとき (「データ収集のプログラム制御」を参照)。

• collect コマンドで -l オプションが使用されている場合に指定したシグナルが送信されたとき (collect(1) のマニュアルページを参照)。

• 収集が開始および終了したとき。

• dbx collector pause コマンドで収集を一時停止したとき (一時停止の直前)、および dbx collector resume コマンドで収集を再開したとき (再開の直後)。

• 派生プロセスが作成される前後。

パフォーマンスツールは、標本パケットに記録されたデータを使用して、時間期間別に分類します。この分類されたデータを標本と呼びます。特定の標本セットを選択することによってイベントに固有のデータをフィルタできるので、特定の期間に関する情報だけを表示させることができます。各標本の大域データを表示することもできます。

パフォーマンスツールは、標本ポイントのさまざまな種類を区別しません。標本ポイントを解析に利用するには、1 種類のポイントだけを記録対象として選択してください。特に、プログラム構造や実行シーケンスに関する標本ポイントを記録する場合は、定期的な標本収集を無効にし、dbx がプロセスを停止したとき、collect コマンドによってデータ記録中のプロセスにシグナルが送られたとき、あるいはコレクタ API 関数が呼び出されたときのいずれかの状況で記録された標本を使用します。