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

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

●概要　

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

●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 はあまりにも遅いので、画像を扱うメソッドでは、マーシャルクラスのアンマネージコードで処理している。