ホーム ] 実行例 ] 処理速度 ] 画像処理メソッド構造 ] 技術解説 ]

上へ
高速化
色空間変換
画像色変換処理
画像濃度変換処理
空間フィルタ
非線形フィルタ
機能フィルタ

画像演算ライブラリ (ImageProcess)

高速化

最終更新日:2007/04/26  修正

●概要 

 この開発で行った高速化を一般論と、共通項目について説明する。個々の高速化については、以降の各技術解説で述べる。

●VBは遅いか?

 以前のVBはインタプリタ方式で、実行の度に翻訳され(多分、サブルーティンのお化け)ていて、実行速度は期待できなかったが、現在のVBは、コンパイル方式となっているので、都度の翻訳は無い。しかし、CPUネイティブなコードではなく、汎用の中間言語で実行される。

 でも、実際の実行時には、CPUネイティブに翻訳される。インスタンスが継続実行される場合は、そのままネイティブ語で走る。システム関連、共通関数は.NET Framework にて関数群が供給される。これらは、十分に高速である。

 しかし、マネージコードなので、メモリ空間チェック、データ型チェック、オブジェクトの寿命管理とリソースの自動取得、開放がバックグランドで走る。この分がオーバヘッドとなるが、コードが安全に走るための代償と思えば、お釣りがくる。特に、リソースの自動開放はご利益が大きい。この分を考慮すれば、VBはそれなりに速いと思っても良い。

 86ネイティブコードには適わないまでも、純粋VBでの高速化は意味のあるアプローチと思っているが、C++を限定的に利用するアプローチも開始。限定的とは、主要な演算エンジンとしてである。 

●高速化の手法

 今回適用した高速化は以下のようになっている。

○アルゴリズムの改良

 同じ結果になるより高速に演算できるアルゴリズムにする。

  • 厳密に同じでなくとも、誤差範囲や省略可能範囲であれば、簡略化する。
  • 数学的に同義な別の表現にする。
  • 空間を変える。ハッシュ空間のように、広大な処理空間を狭い連続空間にするなど。
  • 演算をなくす。結果のデータ範囲が限られていれば、予め算出しておき、参照方式にする。

○コードの高速化

 特に、カーネル部分のコードは重要で、少しの無駄が全体を支配する。以下のような方法をとっている。また、これらは、VBにおいても成立する。

  • ステップ数(演算数)を減らす。但し、短ければ速いと言う訳ではない。より、原始的な命令での話し。
  • 関数をなくし、直に展開する。画素数は大きく、少しのオーバーヘッドが影響を及ぼす。
  • リカーシブは避ける。再帰はリソースを食い尽くすし、スタッキングのオーバーヘッドが大きい。
    (一見スマートでカッコ良いコードは、遅いことが多い)
  • より速い命令を使用する。
  • 多次元配列をやめ、一次元配列にする。但し、アドレス算出で乗算を使用するのは、元の木阿弥となる。
    (便利なものは遅い)
  • CPUのキャッシュを意識したメモリアクセスにする。
  • カーネル内で、New 、ReDim はやめる。カーネル外で確保したインスタンスを再利用する。
  • そのCPUにあった語長を選択する。たとえば、ペンティアム4以降では、整数ではIntegerが最も速い(ByteやShortより速い)。また、科学演算では、Double が早く、これは整数演算より高速になっている。一昔前のような、"浮動小数点演算は遅い"と言うのはもはや事実ではない。

○言語による高速化

  • VBであっても、探せば高速な関数やライブラリが多数ある。これらを利用する。
  • 最終兵器。CPUをネイティブで動かす。C++ネイティブコードの利用。

●画像データの確保と戻し

 VBで最も遅くなる理由はこの部分である。演算自体はそんなに遅くはない。VBのGetPixel/SetPixel はあまりにも遅いので、画像を扱うメソッドでは、マーシャルクラスのアンマネージコードで処理している。