オーバーヘッド って何なんだ！！！？
～ソフトの動的解析に付きまとう余計な処理時間を何とかしたい～

”オーバーヘッド”

この記事を書いている2022年末、民放各社のニュースはワールドカップに沸きましたが、
このブログで扱うオーバーヘッドは、もちろんサッカーの話ではありません。

ソフトウェアの検証を考えるうえでゼッタイ避けては通れないオーバーヘッドについて、
組込み機器をアレコレいじってきたエンジニアが、
とりあえず思いの丈をまとめてみました。

オーバーヘッドを平たく言うと

Wikipediaさんの回答は以下のとおり。

オーバーヘッド（英: overhead）は、文字通り、「頭上」「頭上の」という意味や、頭よりも遥か高い所という意味も持つが、会計をはじめとする多くの分野では、頭上という意味から転じて「間接的なコスト」という意味で使われることが多い。
（中略）
・工学の分野では、金銭に限らない種々の間接的なコストがオーバーヘッドと呼ばれることがある。
　・プログラミングや計算機科学におけるオーバーヘッドは、その処理の本質ではない演算に費やされる計算量を指す。例えば関数呼び出しのためのコールスタックの生成。

https://ja.wikipedia.org/wiki/オーバーヘッド

「平たくとか言っといていきなり引用ってどうよ」などと思いつつ、
ソフトウェア検証的な視点で自分なりの平たい言葉を絞り出すのであれば、

「実際のソフトウェア(“製品版”とか”verいくついくつ版”とかの意味)と、デバッグ版ソフトウェアの間での、処理の差による時間的な差分」

といったところ。

頑張ってもう少し簡単めな言い方を絞ってみるなら…

ある目的を達成するための手法がAとBの２通りあって、最短ルートの処理がAだとすると
「どちらも達成できることはおなじなんだけど、BはAよりどのくらい時間かかるの？(この差分時間がオーバーヘッド)」
っていう感じ。

ある変数を書き換えたいときに、
「メモリ番地指定で直接書き換える」のと「どこかの関数に引数渡して変えてもらう」のでどのくらい差があるの？
みたいな。

ソフトウェア動作への影響

一般的なソフトウェア動作におけるオーバーヘッド

じゃあ、そのオーバーヘッドって、どんなときに影響がでるか。
たとえば通信方式の違いによる完了までの速度の差とかに現れる。

TCPとUDPのお話しとか。
TCPとUDPをめちゃくちゃ端折って説明すると…

TCPは通信の信頼性を担保するためにハンドシェイクしたりAckを返したりする。
要するに１パケットごとにデータが正しいかチェックして、間違ってたら送信しなおす。

UDPはそのへんを省略しているのでTCPより通信は速い。
けど、どこかで通信がコケて内容が正しいモノじゃなくなってても、とにかく全部データ送るまで止まらない。

つまり、この例でいうと、 UDPよりTCPのほうがオーバーヘッドが大きい、ということになる。

TCPとUDPについてもっと解説している記事はコチラ↓から

でも、現実的には「オーバーヘッドが大きい方式のほうが早かった」なんてことも

完全に余談だが、現実においては、この辺はケースバイケースなので難しい。

たとえば、TCPはオーバーヘッドが大きくても、
現実的にはUDPよりTCPのが早いことが多い、なんてことが起こり得る。

「兎と亀」みたいな。

“舐めプ”しがちな兎さんがサボらずに走り切れる距離なら、それは兎さんのほうが早いけど、
兎が絶対サボっちゃうような距離なら、ぜんぜんサボらない亀のほうが結果早いこともある、
っていう感じ。

TCP/UDPの話に戻すと、
とても大きいサイズのデータを送信しなきゃいけないときは、
そのぶん、どこかで通信(正確にはパケット)がコケる可能性は大きくなる。

そういうときにUDPを使うと、全データ送り切ったあとで「なんか間違ってる…」ってなったら、
結局はじめから再送しなきゃならない。
何回も通信がコケると「全体で見ると、結局TCPのほうが早かったね…」なんてことに。

つまり、現実的なオーバーヘッドの大きさは、全体最適みたいな視点での頑張りで小さくできたりすることがある、ということ。

動的テストをつかったソフトウェア検証への影響

このオーバーヘッドは、ソフトウェア検証で動的テストをしたいときに避けては通れない要素になる。

動的テストを知らない人のために簡単に説明すると、
ソフトウェアをコンパイルして作成されたプログラムを実際にRUNさせるタイプのテストのこと。

たとえば初めての言語のお勉強でよくやる「とりあえずHello Worldと出してみる」みたいなテストは動的テストだし、
そこからもう一歩進んだくらいでやるprint文デバッグだって動的テストだ。

動的テストについて説明している記事はコチラ↓から。

ここでオーバーヘッドがどこに影響するかというと、
たとえばprint文デバッグ。
print文は最終コード(それが製品の場合はリリース版コード)には存在しない(もしくはマスクされている)ことがほとんどだと思うが、
最終版のソフトウェアの動作に対して、デバッグ版はprint文が入っている分、動作に時間がかかる。

・指定されたメモリのデータを読み出して
・ベタ書きされた文章とともにコマンドラインなどのインターフェースに出力する
という動作をするための時間がオーバーヘッドとなる。

そして、実際にソフトウェアを動かしてテストする動的テストにとって、
動作ログの出力処理によって発生するオーバーヘッドは回避することができない問題であり、
「最終製品の状態をそっくりそのままでテストできます」と言いきれない最大の理由になる。

回避できないなら、オーバーヘッドを最小にとどめるよう、運用で克服していくしかない。
たとえば、

・ログ出力に比較的高速な処理を使う/高速な構造にする(ペリフェラル使ってみるとか、アセンブラで書いてみるとか、そういう意味)
・ログ出力ポイントの数自体を絞ってみる(ただし一定以上コードの動きを頭でわかってないとダメ)
・テストツールを使ってみる(経験値が要求されるところをお金の力でカバー)

など。

動的テストでのオーバーヘッド削減のこころみアレコレ

動的テストツールDT+が苦心しているアレコレ

ここからは相当セールスピッチみたいな内容になってしまうんですが勘弁してほしい･･･。

動的テストツールDT+についての基礎知識はコチラ↓から

動的テストツール”DT+”は、
ターゲットのソースコード中に”テストポイント”と呼ばれるログ出力処理を入れた状態でコンパイルして、
実際にRunさせることで動作ログを収集/解析するツールなんですが、
もちろんこのテストポイントを大量に入れると、それだけオーバーヘッドが大きくなる。

で、オーバーヘッドが大きくなると、
例えば、割り込み処理の発生タイミングがテスト版と最終製品で違ってくる。

たいていの場合、このような比較的小さい差分は誤差的に考えてスルーしてもよいが、
組込みソフトウェア分野でありがちな
「たまにしか起こらないのに起きたら致命的な問題」
みたいなヤツは、こういうタイミング要因が原因であったりして、
しかもなかなか原因の特定がスムーズにいかないから油断できない。

そもそも、オーバーヘッドなんてものは、可能な限り0に近い方がいいのは間違いない。

そこで、DT+では以下のような手法でオーバーヘッドの削減をしている。

・ログ出力に使うGPIO本数を増やす(通信速度の高速化)
・ログ出力情報を最低限のものに削減
・むしろログ情報をほとんど全部削ってしまう(どの関数のどの処理を通ったか(つまりカバレッジ)だけ取れればよいとき限定)
・GPIOロジックのHi/Lowと特定の処理通過情報を紐づける(組込み機器限定)
・ツールにAIを導入して通過情報を予測させる(ログ出力情報は予測があってるかあってないか示すだけなので結果オーバーヘッド減る)

このへんは以下の記事で書かれているので興味のある方はぜひ参照してほしい･･･。

まとめ

いかがでした？

動的テストとオーバーヘッドについては、とにかく根が深いというか、個人の主義主張に絡むしつこい系の話なので、
わかったような、わかってないような、そんな気持ちになっていただけたらいいなと思っています。

一番いいたかったことは、

「DT+、いま結構がんばってて、いろいろ進化したんです。なんかAI入れ始めてるし。」

ということなんですけどね。

とはいえ、実際に自分で使ってみて自分なりの評価を下すのがエンジニアという生き物の習性に多いトコロだと思うので、
実際にお手元の開発中の機器に、タダで繋いで使ってもらえる「無料トライアル」なんてのをやってます。

限られた工数の中で動的テストを全部手でこなしていくことに疲れや限界を感じている組込みエンジニア諸氏は、
この機会に、ぜひ一度触ってみてください。