移植は、同じプログラムを別の機器へ運ぶ作業ではありません。条件が変わった環境の上で、要求をもう一度成立させ直す設計の工程です。
画像処理は、多くの場合まずPC上で作られます。処理を書き、データで確かめ、想定した結果が出ることを確認する。ここまでは比較的見通しが立ちます。
難しくなるのは、それを実際に使う機器へ移したあとです。PCでは余裕をもって動いていた処理が、機器の上では要求どおりに動かないことがあります。
この記事では、移植のときに何が変わり、何を確かめる必要があるのかを整理します。どの機器を選ぶかという話は別の記事で扱っているので、ここでは「選んだ機器へ移したあと」から始めます。
PCで動いた、では終わらない
PC上で意図した結果が出たとき、処理そのものは完成したように見えます。実際、考え方が正しいかどうかはここで確かめられます。
しかし、その処理が最終的に動くのはPCではなく、現場に置かれる機器です。そして機器の上では、PCとは条件が変わります。処理の内容が同じでも、成立するかどうかは別の問題になります。
移植を、動くものを別の場所へ運ぶ作業だと考えると、この差が見落とされます。
移植とは、同じ処理を別の条件の上で成立させ直すこと
移植でやっていることは、処理の考え方を変えずに、条件の違う環境の上で要求をもう一度成立させることです。
PCと組込み機器では、使える資源も、処理の実行のされ方も、周囲で動いているものも違います。同じ手順を書いても、その手順が置かれる条件が変わっている以上、結果として現れるものは変わりえます。
だから移植は、書き換え作業ではなく、条件が変わった環境で要求を満たせるかを確かめ、必要なら組み立て直す設計の工程です。この見方をしておくと、後の判断が変わります。
私たちは、PCで検証したアルゴリズムをターゲット機器へ移植し、実時間で動作させるところまで対応できます。以下では、その過程で何を見ているのかを説明します。
変わるのは処理の速さだけではない
移植というと、処理が遅くなるかどうかに関心が向きがちです。実際には、速さ以外にも変わるものがあります。
実行環境・演算の条件・使える資源
移植先が変わるとき、次のようなものが同時に変わることがあります。
- 実行環境:処理がどのように順番を与えられ、どこで待たされるか
- 演算の条件:計算の扱われ方や、値の持ち方
- 使える資源:計算のための余裕、記憶できる量、それらを他と分け合う前提
- 生成のされ方:同じ記述でも、どのように機械語へ変換されるか
- 処理を任せられる先:機器が備えている専用の処理機構を使えるかどうか
これらは、処理の速さとは別の軸です。速さだけを見ていると、なぜ結果が変わったのかを説明できなくなります。
実行環境の変更、命令体系の変更、変換の仕組みの変更を伴う移植にも対応できます。ただし、どこまで何が変わるかは移植先ごとに異なるため、はじめに条件を確かめるところから進めます。
同じ入力でも、同じ結果になるとは限らない
移植で見落とされやすいのは、出力が完全には一致しないことがある、という点です。
計算の扱われ方が変われば、途中の値のわずかな差が生まれることがあります。ふつうはその差は見えません。しかし、判定のようにどこかで線を引く処理があると、わずかな差が結論を分けることがあります。
境界に近いデータほど、この影響を受けます。大半のデータでは同じ結果が出ているのに、一部だけ判定が変わる。移植後にこうした状態が起きることがあります。
そのため、移植の確認は「動いたかどうか」だけでは足りません。どのようなデータで、どこまで一致していればよいのかを、あらかじめ決めておく必要があります。
「移植できた」を何で判断するか
移植の完了をどこで判断するかは、思っているほど自明ではありません。
同じ結果が出ることと、要求を満たすことは違う
PCと同じ結果が出ることを基準にすると、わずかな差も許されないことになります。しかし本来必要なのは、その処理が果たすべき目的が達成されることです。
逆に、要求を満たしていればよいと考えるなら、どの条件で、何が、どこまで満たされていればよいのかを先に決めておかなければ判断できません。ここが決まっていないと、確認は「なんとなく動いている」で終わります。
移植の前に決めておく必要があるのは、たとえば次のようなことです。
- どの範囲のデータで確かめるのか
- PCとの差をどこまで許容するのか
- どの条件のときに要求を満たしていればよいのか
- 満たせなかったとき、何を優先して調整するのか
これを移植のあとに決めると、基準そのものを結果に合わせて動かしてしまいます。
実時間で動くとは、平均で間に合うことではない
移植先で求められることの多くに、決められた時間の中で処理が終わることが含まれます。ここでよく起きるのが、平均で間に合っているから成立している、という判断です。
最も条件が厳しいときに間に合うか
処理にかかる時間は、いつも同じではありません。入力の内容によって変わることもあれば、機器の状態によって変わることもあります。
実時間で成立しているかどうかを決めるのは、平均ではなく、最も条件が厳しいときに間に合うかどうかです。ほとんどの場合は間に合っていても、間に合わない場面が残っていれば、その場面で結果が失われます。
そして、間に合わない場面ほど、その処理が本当に必要とされる場面であることがあります。対象が多いとき、変化が大きいとき、条件が悪いとき。ここで落ちる構成は、要求を満たしているとは言えません。
同じ機器の上で動く他の処理と資源を分け合う
機器の上で動いているのは、その画像処理だけとは限りません。映像の取り込み、表示、通信、記録、機器そのものの制御が同時に動いていることがあります。
そのため、単体で測ったときには間に合っていても、全体が同時に動いたときには間に合わないことがあります。実時間で成立するかどうかは、処理単体ではなく、機器全体の動き方の中で決まります。
間に合わないとき、どこから見直すか
移した先で要求に届かないとわかったとき、どこから手をつけるかで結果が変わります。
実装を詰めるか、処理の組み立てに戻るか
まず考えられるのは、同じ処理のまま実装を詰めることです。無駄な計算や、繰り返しの重なりを整理する。データの持ち方を変える。機器が備えている処理機構に一部を任せる。これで届くなら、影響範囲が小さく済みます。
それでも届かない場合は、処理の組み立てまで戻ります。どの粒度で処理するのか、どの順に置くのか、どの段階で対象を絞るのか。全体に同じ手間をかけるのではなく、必要な範囲だけ丁寧に扱う組み方に変えることもあります。
ここで確かめ直すのは、そもそもどの条件で成立していればよかったのか、という点です。要求を満たす範囲が広すぎないか、必要以上の条件を自分たちで課していないか。ここを戻さずに実装だけを詰め続けると、届かないまま作業が続きます。
移植先の条件は、方式を決める段階から持っておく
ここまでは、移したあとに何が起きるかを見てきました。ただ、移植で起きる問題の一部は、移す前に決められています。
PC上で自由に作った処理は、PCの条件を前提にしています。潤沢な計算資源があり、時間の制約が緩い。その前提のまま組み立てた方式は、移植先の条件と合わないことがあります。
そのため、どの方式で解くかを決める段階で、移植先の条件をある程度持っておく必要があります。最終的にどのような機器で動かすのか、どの程度の資源があるのか、どの時間の中で終わらせる必要があるのか。これが分かっていれば、成立しにくい方式を早い段階で外せます。
移植は最後の工程ですが、移植の条件は最初の工程で効いてきます。
NeoTech Innovationが組込みでの実装について考えていること
私たちは、移植を、できあがったものを機器へ載せる作業だとは考えていません。条件の変わった環境で、要求をもう一度成立させ直す工程だと捉えています。
そのため、移す前に、何をもって成立とするのかを決めます。どの範囲のデータで、どの条件のときに、何が満たされていればよいのか。この基準があってはじめて、移植の結果を判断できます。
要求に届かないときには、実装を詰めるだけでなく、処理の組み立てや、そもそもの方式まで戻って考えます。作ったものを動かすことではなく、機器の上で必要な条件を満たすこと。そこを目的に置いています。
まとめ
PCで動く画像処理を組込み機器へ移植するときに起きることを整理します。
- 移植は運搬作業ではなく、条件の変わった環境で要求を成立させ直す設計の工程である
- 変わるのは処理の速さだけではなく、実行環境・演算の条件・使える資源も変わる
- 計算の扱われ方が変われば、境界に近いデータで結果が分かれることがある
- 「PCと同じ結果」と「要求を満たす」は別の基準であり、どちらで判断するかを先に決めておく
- 実時間で成立するかは平均ではなく、最も条件が厳しいときに間に合うかで決まる
- 同じ機器の上で動く他の処理と資源を分け合うため、単体の測定だけでは判断できない
- 届かないときは、実装を詰めるか、処理の組み立てまで戻るかを切り分ける
- 移植先の条件は、方式を決める段階から持っておく
PCで動いたことは、方式が成り立つ見込みが立ったということです。それを実際に使える形にするまでが、移植という工程です。