【連載】自作コードでC言語のベンチマーク計測#3
～ DT+Traceドライバの実力を計測 ～

これまでWindowsやLinuxのいくつかの環境でベンチマーク（今回採用したスコアはMOPS）を計測してきました。物理PCから仮想環境、さらには小型ボードまで、実行環境によってどれほど性能差が出るのかを詳しく検証した前回の内容は、以下のリンクからご覧いただけます。

→【連載】自作コードでC言語のベンチマーク計測#2 ～ Linux環境でも計測してみる ～

前回の検証を通して、それぞれの環境での性能の違いがなんとなくわかってきました。では、このコードを使って、弊社製品「DT+Trace」のテストポイントの実行処理が、どの程度影響を与えそうか？というところを計測してみたいと思います。これにより、しばしばお客様にご質問いただく、「テストポイント出力にかかるオーバーヘッドは？」という問いに対して、従来では処理時間的な視点での回答となっていたものが、別のアプローチから回答できるかな？と考えました。（その回答がユーザーにとって理解しやすい形式かと問われると疑問に思う部分もありますが一旦突き進むことにします）

今回検証に使用する「DT+Trace」とは、ソースコードに「テストポイント」という印を挿入することで、プログラムの動きをリアルタイムで可視化するツールです。ご存知ない方は、こちらの概要ページを一度見ていただくと、これからの検証内容がイメージしやすくなるかもしれません。

→ 動的テストツールDT+ 製品詳細ページ

それでは、本題の計測に入りましょう！

使用した環境

• Windows
  • プロセッサ：AMD Ryzen 7 4700U with Radeon Graphics 2.00 GHz
  • 実装 RAM：16.0 GB
  • ストレージ：477 GB SSD
  • システム：64 bit オペレーティング システム、x64 ベース プロセッサ
• Ubuntu 22.04
  • WindowsOSだと重くて使い物にならなくなった7年モノのPCにシングルブートで構築
    • プロセッサ：intel core i7-6500U
    • 実装 RAM：16 GB
    • ストレージ：500 GB HDD
    • システム：64 bit
  • 普段使用している5年モノのWindowsPC上に構築した仮想OS（VirtualBox）
    ホストPC
    • プロセッサ：AMD Ryzen 7 4700U with Radeon Graphics 2.00 GHz
    • 実装 RAM：16.0 GB
    • ストレージ：477 GB SSD
    • システム：64 bit
• Milk-V Duo256M
  • 小さなコンピュータ基板（SBC：シングルボードコンピュータ）のひとつ。
    • Raspberry Pi（ラズパイ）やArduinoに似た位置づけで、電子工作や組込み開発、AI実験に使われる
    • RISC-V搭載、Linux実行可能
    • 小型で比較的安価（2025年9月時点 ￥2,300）
• DT+Trace
  • Version 2.5.1
  • サンプルドライバはサポートサイトのもの
    • ファイル書き出しにて計測
    • Ethernet接続時も参考値として出す

使用したコードについて

基本的には共通処理で実装しています。時間を計測する関数（get_time_sec関数）の内部のみ、OSに合わせたコードに書き換わっています。高精度単調増加クロックを採用しています。（簡単に表現するとPC内部でひたすらカウントし続けるストップウォッチのようなものを使用して時間を算出しているということ）

検証方法

全体にテストポイントをいれるのではなく、計測用に呼び出されるwhileループの先頭に1つだけテストポイントを挿入します。（※そうすることで、タスク的に呼び出される処理にテストポイントを挿入した場合にかかる影響を計算できると仮定）そして、3分間の実行回数を記録し、MOPS（MOPS: Million Operations Per Second）を導出します。導出されたMOPSと、何もない状態（テストポイントが入っていない）のときのMOPSを比較することで、テストポイント1つあたりのMOPS低下率を調査します。

実行処理のおさらい

これまでの記事でも触れましたが、今回使用している計測プログラムの処理内容について、改めておさらいしておきます。

検証結果

全体的な傾向として、やはりオーバーヘッドとして、テストポイントの影響は受けてしまうようです。ただMilk-Vに関しては他のシステムと比べると、低下した性能は控えめ。他の環境が強すぎるのかもしれませんが、1つ考えられるのは、他に何もサービスとかを動かしていないので、注力できている結果なのかもしれません。これらの性能低下について許容できるかどうか、それは会社や開発チームの運用次第だと思います。

次に検証すべきことは・・・print文や自前のロギングシステムとの比較・・・この手法は組込み開発ではやらざるを得ない手法だと思います。普段やっている手法と、DT+Traceのファイル書き出しを比較したときに、許容できるかどうか。ぜひ普段やられている手段と比べてみてください。

また、自前のロギングシステムやprint文では、開発者自身がチェックポイントを挿入・削除・管理しなければなりません。しかもその管理がかなり大変だと心中お察しいたします。消し忘れなんてしたら一大事。ビルドに時間がかかる環境なら+α大変です。

DT+Traceでは、そんなチェックポイント（=テストポイントとDT+Traceでは呼びます）の挿入・削除・管理も自動でもできますし、GUIから操作、該当箇所を表示もサクッとできます。もしこの性能低下を許容できたら、デバッグやテストでの余計な管理作業を丸っと他のこと（他の作業や残業しないで帰り趣味の時間に充てるなど）が実現できるかもしれません。

まとめ

性能低下は当然のように起こりました。でもきっとデバッグやテストで使われるどんな手段（たとえLEDを点灯させるだけでも）を取ろうと、性能低下は起こると考えます。要するに、低下することを許容できるかできないか。それによっては、残業のない未来もあるかもしれません。許容できるように設計してもらうことも1つの手段だとも考えます。
組込みでハードウェアリソースのない環境や、性能的に余裕度のあるPCアプリなどの環境であれば、ファイル書き出し接続、ぜひお試しください。

本編では触れていませんが、Ethernet接続も参考として載せました。Ethernet接続で性能低下により上手く活用できなかった人は、この結果から、「ちょっとファイル書き出し試してみようかな？」と思ってもらえると嬉しいです。

また、「そもそもDT+でどんな解析ができるの？」と気になった方も、もしよろしければこちらのデモ動画をのぞいてみてください。実際の操作感や解析画面のイメージを手軽にご確認いただけます。