🧙🏼 🥩 🧝🏻 LLVMテストスイートを例として使用して、プログラムメトリックをテストおよび収集するための柔軟なシステム 😠 😾 👲🏼

はじめに

ほとんどの開発者は、LLVMシステムやclangコンパイラなど、非常に重要なオープンソース開発について明確に聞いています。ただし、LLVMはコンパイラーを作成するためのシステムそのものであるだけでなく、コンパイラー作成のあらゆる段階で発生するさまざまな問題を解決するための多くのプロジェクトを含む大規模なエコシステムでもあります（通常、各プロジェクトには独自のリポジトリがあります）。インフラストラクチャの一部には、テストおよびベンチマークツールが含まれます。コンパイラを開発するとき、その有効性は非常に重要な指標です。これらの個々のLLVMテストインフラストラクチャプロジェクトの1つは、テストスイート（公式ドキュメント）です。

LLVMテストスイート

テストスイートリポジトリを一見すると、これはC / C ++のベンチマークのセットにすぎないようですが、これは完全に真実ではありません。パフォーマンス測定が行われるプログラムのソースコードに加えて、テストスイートには、メトリックを構築、実行、および収集するための柔軟なインフラストラクチャが含まれています。デフォルトでは、コンパイル時間、実行時間、リンク時間、コードサイズ（セクション）のメトリックを収集します。

テストスイートは、コンパイラのテストとベンチマークに自然に役立ちますが、C / C ++コードベースが必要な他の研究タスクにも使用できます。かつてデータ分析の分野で何かをしようとした人は、ソースデータの不足と断片化の問題に直面したと思います。テストスイート。膨大な数のアプリケーションで構成されているわけではありませんが、統一されたデータ収集メカニズムを備えています。コレクションに独自のアプリケーションを追加し、特定のタスクに必要なメトリックを収集するのは非常に簡単です。したがって、私の意見では、テストスイートは（テストとベンチマークの主なタスクに加えて）基本プロジェクトに適したオプションであり、これに基づいて、プログラムコードのいくつかの機能またはプログラムのいくつかの特性を分析する必要があるタスクのデータコレクションを構築できます

LLVMテストスイートの構造

test-suite |----CMakeLists.txt //  CMake ,   ,  | //   .. | |---- cmake | |---- .modules //        , | //   API    | |---- litsupport //  Python,      test-suite, | //    lit (  LLVM) | |---- tools //   :    | //     (    | // ),    .. | | //     | |---- SingleSource //   ,       | // .        . | |---- MultiSource //   ,      | //  .        | //  . | |---- MicroBenchmarks // ,   google-benchmark.   | //  ,    ,  | //       | |---- External //    ,     test-suite,  | // ,     (  ) | // -

構造はシンプルで簡単です。

動作原理

ご覧のとおり、CMakeと特別なライトテスト形式は、メトリックのアセンブリ、起動、およびコレクションの記述に関するすべての作業を担当します。

非常に抽象的な方法で考えると、このシステムを使用したベンチマークプロセスがシンプルで非常に予測しやすいことは明らかです。

これはどのように詳細に見えますか？この記事では、システム全体でCMakeが果たす役割と、このシステムに何かを追加する場合に記述する必要がある唯一のファイルについて詳しく説明します。

1.テストアプリケーションの構築。

ビルドシステムとして、C / C ++ CMakeプログラムのデファクトスタンダードになりました。 CMakeはプロジェクトを構成し、ユーザーの好みに応じてmake、ninjaなどのファイルを生成します。直接建設のため。

ただし、テストスイートでは、CMakeはアプリケーションの構築方法に関するルールを生成するだけでなく、テスト自体も構成します。

CMakeを開始すると、アプリケーションの実行方法と正確性のチェック方法の説明とともに、ファイル（拡張子.test）がビルドディレクトリに書き込まれます。

最も標準的な.testファイルの例

 RUN: cd <some_path_to_build_directory>/MultiSource/Benchmarks/Prolangs-C/football ; <some_path_to_build_directory>/MultiSource/Benchmarks/Prolangs-C/football/football VERIFY: cd <some_path_to_build_directory>/MultiSource/Benchmarks/Prolangs-C/football ; <some_path_to_build_directory>/tools/fpcmp %o football.reference_output

拡張子が.testのファイルには、次のセクションが含まれる場合があります。

PREPARE-単体テスト用のさまざまなフレームワークに存在するBeforeメソッドと非常によく似た、アプリケーションを起動する前に実行する必要があるアクションを記述します。
RUN-アプリケーションの実行方法を説明します。
検証-アプリケーションの正しい動作を確認する方法を説明します。
METRIC-標準でさらに収集する必要があるメトリックを説明します。

これらのセクションはいずれも省略できます。

ただし、このファイルは自動的に生成されるため、ベンチマークのCMakeファイルにあります。オブジェクトファイルを取得する方法、アプリケーションにアセンブルする方法、このアプリケーションで何をする必要があるかを記述しています。

デフォルトの動作とこれがどのように記述されるかをよりよく理解するために、いくつかのCMakeLists.txtの例を検討してください。

 list(APPEND CFLAGS -DBREAK_HANDLER -DUNICODE-pthread) #      (         ..     CMak,       ) list(APPEND LDFLAGS -lstdc++ -pthread) #

フラグはプラットフォームに応じて設定できます。DetectArchitectureファイルはテストスイートcmakeモジュールに含まれており、ベンチマークが実行されるターゲットプラットフォームを決定するため、既に収集されたデータを簡単に使用できます。他のデータも利用可能です：オペレーティングシステム、バイトオーダーなど。

 if(TARGET_OS STREQUAL "Linux") list(APPEND CPPFLAGS -DC_LINUX) endif() if(NOT ARCH STREQUAL "ARM") if(ENDIAN STREQUAL "little") list(APPEND CPPFLAGS -DFPU_WORDS_BIGENDIAN=0) endif() if(ENDIAN STREQUAL "big") list(APPEND CPPFLAGS -DFPU_WORDS_BIGENDIAN=1) endif() endif()

原則として、この部分は、少なくとも一度は単純なCMakeファイルを表示または作成したことがある人にとっては新しいものであってはなりません。当然、ライブラリを使用し、自分でビルドできます。一般に、アプリケーションのビルドプロセスを説明するためにCMakeが提供する任意の手段を使用できます。

そして、.testファイルの生成を確認する必要があります。 tets-suiteインターフェースがこれを提供するツールは何ですか？

2つの基本的なマクロllvm_multisourceとllvm_singlesourceがあり、ほとんどの些細な場合にはこれで十分です。

llvm_multisourceは 、アプリケーションが複数のファイルで構成されている場合に使用されます。 CMakeでこのマクロを呼び出すときにパラメーターとしてソースコードファイルを渡さない場合、現在のディレクトリにあるすべてのソースコードファイルがビルドのベースとして使用されます。実際、テストスイートのこのマクロのインターフェイスで現在変更が行われています。ソースファイルをマクロパラメーターとして転送する方法は、マスターブランチにある現在のバージョンです。以前は、別のシステムがありました。ソースコードを含むファイルは、（リリース7.0のように）Source変数に書き込む必要があり、マクロはパラメーターを受け入れませんでした。しかし、実装の基本的なロジックは同じままです。
llvm_singlesourceは、各.c / .cppファイルが個別のベンチマークであり、それぞれに対して個別の実行可能ファイルを収集すると見なします。

デフォルトでは、ビルドされたアプリケーションを起動する上記の両方のマクロは、このアプリケーションを単に呼び出すコマンドを生成します。そして、検証は、拡張子が.reference_outputのファイル内にある予想される出力と比較することによって実行されます（また、.reference_output.little-endian、.reference_output.big-endianの可能性のあるサフィックスを使用）。

これがあなたに合っていれば、それは素晴らしいことです。アプリケーションを起動し、次の指標を取得するには、余分な行（llvm_multisourceまたはllvm_singlesourceを呼び出す）で十分です：コードサイズ（セクション）、コンパイル時間、リンク時間、実行時間。

しかし、もちろん、すべてがスムーズになることはめったにありません。 1つ以上のステージを変更する必要がある場合があります。そして、これは単純なアクションの助けを借りても可能です。覚えておく必要がある唯一のことは、あるステージを再定義する場合、他のすべてのステージを記述する必要があるということです（もちろん、それらの作業のデフォルトアルゴリズムが満たされていても、それは少し動揺します）。

APIには、各段階でのアクションを記述するマクロがあります。

準備フェーズのllvm_test_prepareマクロについて書くことはあまりありません。実行する必要があるコマンドは、単にパラメーターとして渡されます。

起動セクションには何が必要ですか？最も予測可能なケースは、アプリケーションがいくつかの引数、入力ファイルを受け入れることです。これを行うには、 llvm_test_runマクロがあります。これは、アプリケーションの起動引数（実行可能ファイルの名前なし）のみをパラメーターとして受け入れます。

 llvm_test_run(--fixed 400 --cpu 1 --num 200000 --seed 1158818515 run.hmm)

検証の段階でアクションを変更するには、 llvm_test_verifyマクロを使用します。これは、コマンドをパラメーターとして受け入れます。もちろん、正しいことを確認するには、toolsフォルダーに含まれているツールを使用することをお勧めします。これらは、生成された出力を予想された出力と比較する良い機会を提供します（実数とエラーを比較するための別の処理などがあります）。ただし、どこかで、アプリケーションが正常に完了したことなどを確認するだけです。

 llvm_test_verify("cat %o | grep -q 'exit 0'") # %o -   placeholder   ,   lit.          lit,    ,    .    lit (  ,   LLVM)      (   <a href="https://llvm.org/docs/CommandGuide/lit.html"> </a>)

しかし、追加のメトリックを収集する必要がある場合はどうでしょうか？このためのllvm_test_metricマクロがあります。

 llvm_test_metric(METRIC < > <,   >)

たとえば、dhrystoneの場合、それに固有のメトリックを取得できます。

 llvm_test_metric(METRIC dhry_score grep 'Dhrystones per Second' %o | awk '{print $4}')

もちろん、すべてのテストについて追加のメトリックを収集する必要がある場合、この方法はやや不便です。 llvm_test_metric呼び出しをインターフェースが提供する上位レベルのマクロに追加する必要があるか、TEST_SUITE_RUN_UNDER（CMake変数）と特定のスクリプトを使用してメトリックを収集できます。 TEST_SUITE_RUN_UNDER変数は非常に便利で、たとえばシミュレーターなどで実行するために使用できます。実際、コマンドを記述して、入力としてアプリケーションを引数として受け取ります。

その結果、次の形式のCMakeLists.txtを取得します。

 #       llvm_test_run(--fixed 400 --cpu 1 --num 200000 --seed 1158818515 run.hmm) llvm_test_verify("cat %o | grep -q 'exit 0'") llvm_test_metric(METRIC score grep 'Score' %o | awk '{print $4}') llvm_multisource() # llvm_multisource(my_application)

CMakeを使用してアプリケーションが既にビルドされている場合、統合に追加の労力は必要ありません。テストスイートのCMakeList.txtに、既存のCMakeをアセンブリに含めて、簡単なマクロ呼び出しを追加できます。

2.テストの実行

その結果、CMakeは指定された説明に従って特別なテストファイルを生成しました。しかし、このファイルはどのように実行されますか？

litは常にlit.cfg構成ファイルを使用します。これは、テストスイートに存在します。この構成ファイルには、実行可能なテストの形式など、テストを実行するためのさまざまな設定が示されています。テストスイートは、litsupportフォルダーにある独自の形式を使用します。

 config.test_format = litsupport.test.TestSuiteTest()

この形式は、標準照明テストから継承され、実行インターフェイスのメインメソッドをオーバーライドするテストクラスとして記述されます。また、litsupportの重要なコンポーネントは、TestPlanテスト実行計画の説明を持つクラスです。このクラスには、さまざまな段階で実行する必要があり、段階の順序を知る必要があるすべてのコマンドが格納されます。必要な柔軟性を提供するために、mutatePlanメソッドを提供する必要のあるアーキテクチャにもモジュールが導入されました。その中で、テスト計画を変更し、必要なメトリックのコレクションの説明を導入するだけでなく、アプリケーションを起動するための時間を測定するためのコマンドを追加しますこのソリューションにより、アーキテクチャはうまく拡張されています。

テストスイートテストのおおよそのスキーム（TestContextクラス、さまざまな点灯構成、テスト自体などの形式の詳細を除く）を以下に示します。

点灯すると、構成ファイルで指定されたテストタイプが実行されます。 TestSuiteTestは、生成されたCMakeテストファイルを解析し、メインステージの説明を受け取ります。次に、見つかったすべてのモジュールが呼び出されて現在のテスト計画が変更され、起動がインスツルメントされます。次に、受信したテスト計画が実行されます。準備、起動、および検証の段階で実行されます。必要に応じて、プロファイリングを実行できます（構成中にプロファイリングの必要性を示す変数が設定された場合、モジュールの1つによって追加されます）。次の手順では、メトリックを収集し、TestPlanのmetric_collectorsフィールドに標準モジュールによって追加された収集機能を収集します。その後、CMakeでユーザーが記述した追加のメトリックを収集します。

3.テストスイートの実行

test-suiteを実行するには2つの方法があります。

マニュアル、つまりコマンドの順次呼び出し。

 cmake -DCMAKE_CXX_COMPILER:FILEPATH=clang++ -DCMAKE_C_COMPILER:FILEPATH=clang test-suite #  make #   llvm-lit . -o <output> #

LNT（LLVMエコシステムの別のシステムを使用して、ベンチマークを実行し、結果をデータベースに保存し、Webインターフェイスで結果を分析できます）。テスト実行チーム内のLNTは、前の段落と同じ手順を実行します。

 lnt runtest test-suite --sandbox SANDBOX --cc clang --cxx clang++ --test-suite test-suite

各テストの結果は次のように表示されます

 PASS: test-suite :: MultiSource/Benchmarks/Prolangs-C/football/football.test (m of n) ********** TEST 'test-suite :: MultiSource/Benchmarks/Prolangs-C/football/football.test' RESULTS ********** compile_time: 1.1120 exec_time: 0.0014 hash: "38254c7947642d1adb9d2f1200dbddf7" link_time: 0.0240 size: 59784 size..bss: 99800 … size..text: 37778 **********

テストスイートに含まれるスクリプトを使用して、LNTを使用せずにさまざまな起動の結果を比較できます（ただし、このフレームワークはさまざまなツールを使用して情報を分析する素晴らしい機会を提供しますが、個別のレビューが必要です）

 test-suite/utils/compare.py results_a.json results_b.json

2つの起動からの同じベンチマークのコードサイズを比較する例：-O3および-Osフラグを使用

 test-suite/utils/compare.py -m size SANDBOX1/build/O3.json SANDBOX/build/Os.json Tests: 1 Metric: size Program O3 Os diff test-suite...langs-C/football/football.test 59784 47496 -20.6%

おわりに

テストスイートに実装されたベンチマークを記述および実行するためのインフラストラクチャは、使いやすく、サポートが容易であり、拡張性が高く、原則として、アーキテクチャではかなりエレガントなソリューションを使用しているため、テストスイートは開発者にとって非常に便利なツールになりますコンパイラ、およびこのシステムは、一部のデータ分析タスクで使用するために変更できます。

LLVMテストスイートを例として使用して、プログラムメトリックをテストおよび収集するための柔軟なシステム

はじめに