かにの泡ぶく(2008-11-15)

2008-11-15 今日は4つを使い倒すための第一歩。

_ クワッドコアを意識したコーディングについてのちょっとしたメモ。

そもそもWindowsだという時点でげんなりなんですけどね、まぁそこは言ってもどうにもならない大人の事情ですのでおいとくとして・・・

かにこむで開発する画像処理システムも扱うデータ量が年々増大しておりまして、今、受注している　とある　案件なぞは、扱う画像サイズが1枚11ギガバイト（！）なんてことになっているのです。で、これに対して解析処理をするわけで、ヒストグラム取るだけでも一苦労なんですよね。

で、これを動かすPCも当然ハイスペックワークステーションになるわけですが、そんなわけで今、我が家には開発機としてインテル/Xeon/E5440/2.83GHzが鎮座しています。

しかしですね・・・単一スレッドのアプリではコアが4つあっても全然活かせないわけで、画像処理システムにおいて4つのコアを有効に使って処理時間を短縮させるためには、画像処理をどうスレッドに分解すればよいのか？　ということを今日は考えていたのですが・・・

画像処理って通常はstep by stepで進行しますから、並列に処理できる内容って実はあまりないのですね。敢えて分解するとするならば・・・

・ヒストグラム生成時にRとGとBのカウントループをそれぞれスレッ分解して
　回す。
・YとCbCrに独立して異なる処理を行うところをスレッド分解して回す。
・一時ファイルに書き出す際にファイル書き出しの時間を使ってついでにヒス
　トグラムも取るべくスレッド分解して回す。


・・・・・

要は、なんらかの成分に着目して、ばらばらで処理しても問題ないところを片っ端からスレッド分解するってことでしょうか。

入力画像のライブ表示なんつう処理はすでに別スレッドになっていますからこのままでOK。

う〜〜ん・・・あんまし目に見えた恩恵はなさそうだなぁ・・・

画像処理システムに使うPCのような、特定用途専用機の場合、マルチコア化よりもシングルコアでいいからCPU爆速化してもらったほうが、正直嬉しいなぁって感じです。

Windowsでマルチスレッド書いちゃうと移植性にも大きく影響してくるって点も、いまいち気が重いところです。

さてと・・・少しコード書いて実際にどの程度パフォーマンス向上するか、実験してみるとしますか。

_ クワッドコアを意識したコーディングについてのちょっとしたメモ-その2。

ファイル操作について

・あるメモリブロックの内容をディスクに書き出すという処理において：
　- メモリブロックの内容を書き出す処理と、メモリブロックの内容をオンメ
　　モリのみで参照する処理を並列にすると、処理時間は短縮する。
　- メモリブロックの内容を異なる複数のファイルに書き出す処理を並列にす
　　ると、直列で処理したときよりも処理時間は増大する。
　　但し、複数のファイルを別の物理ストレージに書き出す場合は、この限り
　　では無い。
　　→ディスクの回転待ちでオーバーヘッドが発生していると推測。
　　→ディスクキャッシュに入りきるような十数メガバイトの画像データであ
　　　れば同じ物理ストレージ上に書き出しても恩恵あるかも。


・あるメモリブロックの内容を参照し、計算するという処理において：
　- いかなる場合においてもオンメモリで完結する処理であれば、並列化した
　　ほうが処理時間は短縮するようである。

ファイルアクセスが発生しそうな処理の並列化の際は、注意ですね。

本日のツッコミ(全5件) [ツッコミを入れる]

_ 切磋琢磨 (2008-11-15 20:57)

何をなさろうと、しているのかわかりません！ （入力、出力の関係） 私は画像は使った事ありませんし、圧縮のアルゴリズムも知りませんが「トーナメント・ソート法」や「２分岐・ソート法」が参考になるかも知れませんね？ 私だと画像のＲＧＢと位置情報を全部なめて、一回、ＲＧＢの合計がどんな色彩になるか求めて、それを始めの分岐とします。 要は配色で多そうな判断文を最初に通るようにする。 それでは失礼します。

_ 青木@管理人 (2008-11-15 21:49)

えーと、今回は特に入出力の関係には言及していません。 画像処理のシーケンスフローを高速化するにおいて、クワッドコアでどういうところに留意してコーディングすればよいのか？　という点についての勘所を知るための予備実験です。 だから、特に画像に限ったことではなく、まぁ、マルチコアCPU上で稼動する実行コードを書くにおいてのコード実装上の勘所を試行錯誤したところのヨタ話ってところであります。

_ 切磋琢磨 (2008-11-15 23:50)

まずは情報共有です。 http://ja.wikipedia.org/wiki/%E3%82%AF%E3%82%A2%E3%83%83%E3%83%89%E3%82%B3%E3%82%A2#.E6.A6.82.E8.A6.81 また、文中に「画像サイズが1枚11ギガバイト」とあります。 ・処理を早くするためにはＣＰＵを増やすより、11GBayt以上のメモリ積んでI-Oを減らすことでCPUを増やすより早くなります。 ・もともとクワットコアはマルチタスクで各タスクが別々のＣＰＵに割り当てられることを前提だと思うのですが？ ・OS、Windaosに頼るのであれば、「msconfig」などで余計な処理を立ち上げないとか。 http://speedup-xp.com/06-04.htm のページにあるように優先度をあげるとか。 ・以下のミドルウェア入れるとか http://www.imageom.co.jp/HarmonyCalc/Features.HTML また、CPUの切り替えのスイッチ信号は取得出来る言語なのでしょうか？？？メモリーもスイッチできるのでしょうか？ ・こんな本も出てますし。 　http://www.amazon.co.jp/dp/4798014621?tag=reciente-22&camp=243&creative=1615&linkCode=as1&creativeASIN=4798014621&adid=10T10SJBG0CSGZJXVZ70& ・私が私パソコンで高速処理するのであればLinuxのコマンドラインで最低減のソフトでC++でコーディングします。 　でももう、この世界には入りません！　ではでは！

_ 青木@管理人 (2008-11-16 08:46)

いろいろありがとうございます。 私もそのへんは当然検討済みなんですが、メモ的日記なのでシステム仕様全貌を書いていない点は少し情報不足でしたね。 まず、繋がるハードウェア要件及びクライアントの事情により、Windowsしか選択の余地がありません（私が可能な限りWindowsを選ばない人であることは有名な話 ^^)）。 そして、これまたハードウェア要件より、64Bit版Windowsは使用不能。よって、搭載可能なメモリは最大4GBとなります。 クライアントのシステム管理コスト（金と時間）等々を考えて、なるべく安定かつ汎用性を維持することを考えると、特殊な設定にはしたくない。というか、最近のマシンであればする必要はありません。プロセスマネージャーを使えばCPU占有できますしね。 私も言語はC/C++を使っていますが、コンパイラが優秀ならば、バイナリレベルの処理は言語にあんまし依存しないかと思います。言語の選択というのは、また別の問題かと。 さて、今日も画像処理ライブラリのマルチスレッド化を進めなければ・・・ ^^)

_ 切磋琢磨 (2008-11-16 09:43)

そうですか、11GByteの画像ファイルを4GByteの制限では大変ですネ！ やはり私はメモリーに気が行きます。 半導体メモリーも安くなった事だし、一次ファイル吐き出す先を半導体メモリーに出して、最終的にはディスクに出す、なんてどうでしょう。 ある、仲買の入札システムで、この手つかいました。 １８年も前の話です。