7bit

最近boost::mplに興味を持って、ちょっと色々試しています。

Base::template tmp<0>::get()

なんていう気持ち悪い場所にtemplateが書けるなんてのもここ数日で知りました。

それでテンプレートを使って、TI_0, TI_1, …, TI_n の入力型を処理してTO_0, TO_1, …, TO_m の出力型を吐くような、functionもどきを作ったりしています。

主に画像処理に使う目的(つまりTIとかTOには画像が入る)で書いていますが、
単に画像だけならvector<shared <IplImage> >+仮想関数とかでいいわけです。
ところが時々特徴点集合とか整数値とか、画像じゃないものも受け渡す必要がでてきます。

これらを全部同様に扱えるようにというひねくれた目標を掲げたら途端にテンプレートの世界へ…
だんだん慣れてきて、クソ長いコンパイルエラーもなんとか意図するところがわかるようになってきました。

ちなみにその画像処理ライブラリはテンプレートのコンパイル時inline展開の恩恵に与れているようで、結構面倒な処理を渡しても30fpsカメラで27fpsくらい出ています。

しかしcvShowImageまわりがマルチスレッドで微妙な挙動を示すのには参りました。どうやらcvNamedWindowとcvShowImageは同じスレッドで起動しなくてはならず、cvShowImageはメインスレッド(というかcvWaitKeyスレッド？)でコールしないと画像が表示されない等など。ちょっとソース見たわけではないので怪しい経験則ですが、暇があったらちゃんと読んで調べておこうと思います。
目下の所は全処理スレッドが完了するのを待った後でcvShowImageだけメインスレッドに回しています。若干汚い。

以前書いたC++がPythonより重い…でソースコードを載せると言いつつ載せて無かったので、引っ張り出してきました。

ptest_regex.zip をダウンロード

昔のことで記憶が曖昧ですが、たしかC++, Python, 生grep (追記: C#も)で

をそれぞれ試しています。多分。

用いたデータセットや結果は過去のエントリを参照してください。

勿論「C++よりPythonが全面的に速い」「C++とPythonで同じアルゴリズムを実装すると後者が速い」ということが言いたいのではありません。(そしてそれは多分言えないと思う)

適当に使えそうな/気軽に使ってしまうライブラリ(C++ではboost, ICU、Pythonでは標準のエンコーディング変換関数とre)を自然に使ってみるだけだとPythonの方が早いこともあるらしい、という驚きと悲しみをちょっと記録しただけです。

「自然に」が自分の中では結構大事で、無理して良いなら当然自由度の高い低レベルな言語が一番チューニング出来る可能性がある、でもパラメタが多すぎて難しい。
まあPythonは標準ライブラリを使っているため、ちょっとチューニングしたいと思ったときに改変がやや面倒なのに対し、C++は標準ライブラリ以外を使っている(勿論stlも使ってますが)のでその辺は楽、という点はやや不公平ではあるかもしれませんが。

C++を自然に使ってより早い結果が得られる方法があれば、教えてもらえると嬉しいです。xpressiveとか使ったこと無いけどどうなんんでしょう。

追記
忘れていましたがPython vs C++ vs C# @ 7bitでC#版も書いていたらしい。記憶にない… でもソースもあったので追加しておきました。

ウィンドウが非アクティブになると、自動的にシェード状態(タイトルバーだけ見える状態)にする
AutoShade 1.02をリリースしました。

実は今までのバージョンは、設定ファイル冒頭でPythonのモジュール”re”をロードしていて、失敗した場合にアプリケーションごと巻き込んで落ちるという事態が発生していました。

今回から、Python 2.6がシステムになく、”re”がロードできない状況でも起動・動作するように設定スクリプトAutoShade.pyを修正しました。

re(正規表現)やその他のPythonのモジュールを使用する場合は、個別にPython 2.6をインストールしてください。

GUIツールキットのQtの最新版、4.5のライセンスとしてLGPLが選択可能になりました。

First Qt Solutions available under LGPL — Qt – A cross-platform application and UI framework

商用でも使われるだけあってデザイナもそこそこ使いやすそうなので、これを機にまともに使ってみようか。
qmakeを覚えるのが面倒そうだけど…

ウィンドウが非アクティブになると、自動的にシェード状態(タイトルバーだけ見える状態)にする
AutoShade 1.01をリリースしました。

前回から使えるようになった非アクティブウィンドウの自動半透明化ですが、これは半透明化するためにレイヤードウィンドウスタイル(WS_EX_LAYERED)を設定しています。

ウィンドウにWS_EX_LAYEREDを設定すると描画が遅くなるため、今回のバージョンアップで元々レイヤードであるウィンドウ以外は解除時に非レイヤードに戻すようにしました。

ウィンドウが非アクティブになると、自動的にシェード状態(タイトルバーだけ見える状態)にする
AutoShade 1.00をリリースしました。

Pythonで記述出来る部分が増えました。

• ウィンドウアクティブ化の処理を行うactivateWindowコールバック
• ウィンドウ非アクティブ化の処理を行うunactivateWindowコールバック

また、シェード化から最前面化を独立し、さらに半透明化を追加しました。
これら3つを独立に設定できるので、ウィンドウが非アクティブになった際に単に半透明化するだけ、ということも可能です。

前回のエントリでは多数のファイルに対して正規表現をかける処理をC++とPythonで書いき、Pythonのほうが圧倒的に速いという結果になりました。

Pythonは書き方が収斂するので大してチューニングなどはしませんが、
C++では自由度が高いため書き殴ったコードを数万回繰り返すのでは、パフォーマンスを大きく落としそうです。

今回はC++の方の実装を少し修正し、またC#版も書いてみました。

結果は以下のようになりました。(単位は秒)

実験A、Bというのはデータセットの違いです。

• A: linuxのカーネルソースコード 2.6.28.7 約2.5万ファイル、323MB
• B: 日英対訳文対応付けデータ 約2000ファイル、144MB

また、1から3は検索するパターンの違い。ちょっと面倒なのでまたまとめ直すときにでも載せますが、

1. 軽い
2. ^.*$
3. 軽い物を3段

としています。

前回よりC++も改善し、Pythonとそう変わらないまでに向上しました。
C#はファイル数が少ない場合は性能が良いですが、増えると極端に遅くなるようです。

よく見たら生のgrepよりもPythonの方が速い…

しかしPythonはろくなGUI デザイナがないので困ります。wxPython用のXRCedやGladeは重いし落ちるしバグまみれだし、PyQtは4.5未満はQPLかGPLだし。

GUI grepツールの調査過程は一応一段落し、当初のもくろみ通り製作に入ろうとしています。
今は特に苦もなく使えそうなPython, C++, C#のどれを用いるか検討中。
大量のファイルへのアクセスと正規表現のマッチは割と重い処理になりそうなので、実際にコードを書いて比較しています。

まず生grep。find | xargs grep ‘…’。直接Cで書かれていることを考えると、最速の基準として考えて良さそうです。日英対訳文対応付けデータをデータセットとして実験していますが、1.1秒くらいで2000ファイル近くのスキャンが終わる。

次に、書きやすそうなところでPython (re)でやってみました。所詮LLだし、結果には全然期待していません。
ところがところが、何故かこれが滅茶苦茶速い。
特に最適化したコードの書き方でもないんですが、1.6秒くらいで終わる。殆どC同等の速さ。

そして生grepの次に速いだろうと予測していたC++の実験。
正規表現はboost.regex、Unicodeのエンコーディング変換はICU。同じコードを言語を変えて書くのは結構苦痛だなあと思いつつも、ICUとかはじめて使うので得ることもあるにはある。
何時間かかけていよいよ書き上がり、実行してみると…

20秒。絶望的に遅い。

さすがにこれはもう少し速くなるはず。ファイル読み込み、エンコーディング変換、正規表現で検索、と切り分けて原因を探す。
すると、どうやらファイルのリードでwhileなんかを使っていたのが効いていたようで、read(&buf, len)にしたら4秒にまで縮まりました。

しかしPythonの2倍以上かかるのはやはり不満。
文字コード変換・正規表現を両方オフにして、ファイル読み込みだけの時間を計ると0.5秒。
文字コード変換を加えると2.4秒、全部入りで4秒、という感じ。

ちなみにPythonでリードだけなら0.6秒、+変換で計ると1.3秒、全部で1.6秒。

まとめると下表のようになる。

つまり自分では手出しできない、ライブラリ使っている文字コード変換と正規表現が遅い。
UConverterは先に作ってるし、正規表現もコンパイル済みを使い回しているのに…

リードと変換を同時に行えば、文字列をパースする回数を減らせるので少し速くなるかもしれません。
しかしそれでも次の正規表現でがた落ち。

生grepを考えると頑張ってPythonを抜いても壁がすぐ近くにありそうなので、
C++は諦めてPythonで書くかもしれません。
より楽な言語で書けて嬉しいといえば嬉しいんですが、長年使っていたC++がこのざまというのは…

なんだかC#を評価する気力もなくなってきた。
実験のコードなどはたぶんそのうちおそらく公開します。

20090627 追記
C++とPythonの文字コード変換+正規表現速度比較ソース公開
ソースコード公開しました。

C#との比較も(忘れていたけれど)ありました。上のソースコードzipにも加えました。

IMクライアントPidginのプラグイン、
Random Buddy Icon Plugin 1.0.0を公開しました。
このプラグインを導入すると、一定時間間隔で指定ディレクトリ中からランダムに選んだ画像をBuddy Icon(”仲間アイコン”)に設定します。

特に用もなくアイコンを変えたいけど、手動は面倒という人にお勧めです。

それにしてもPidginのビルド環境を整えるのが面倒だった…なんだかよく分からないライブラリを10個くらい突っ込んで総量400MBにも達した。
プラグインだけ個別にビルド出来たらいいのに。

ウィンドウが非アクティブになると、自動的にシェード状態(タイトルバーだけ見える状態)にする
AutoShade 0.01 betaをリリースしました。

Pythonで記述出来る部分が増えました。

• ウィンドウ発見時に登録の可否を判定するためのコールバック
• ウィンドウ削除時に呼ぶコールバック
• ウィンドウシェード時に呼ぶコールバック (Falseを返すことで抑止可能)
• ウィンドウシェード解除時に呼ぶコールバック (Falseを返すことで抑止可能)

が新しく追加されました。