« クラスメンバ渡しと引数渡し | メイン | SQLite の VFS »

2008年01月14日

思う事/思い付いた事:: マルチスレッドとアトミック/インターロック

    

ムービーでは、特に気にせずクリティカルセクションでロックをかけて処理しているが、Windows のクリティカルセクションはかなり遅いらしい。
これはいくつかの文書で見かける。
そして、クリティカルセクションではなく、可能ならインターロック系のメソッドを使うとかなり改善するとも。
インターロック系のメソッドは、InterlockedIncrement や InterlockedDecrement、InterlockedCompareExchange など。
Linux なら、atomic.h の atomic_inc や atomic_dec、atomic_compare_and_swap が該当するもののようだ。
これらは boost の atomic_count_win32.hpp や atomic_count_linux.hpp で使われている。

アトミック/インターロックを使ってプログラムを書く際の触り(?)の部分は、Lock-freeとWait-freeアルゴリズム ( Wikipedia ) に軽く書かれている。
このような方法を使えば、確かにロックせずに動く。
が、ムービーの場合は、処理の単位が大きいので、ロックする方法でもさして問題にはならないような気もする。
まあ、デコーダーの内部処理をマルチスレッド化する際は気にかけた方が良さそうだ。

参考 :
カプコン×インテル。「ロスト プラネット」のマルチスレッド最適化対談
【GDC07】ゲーム開発者はさらなるマルチコア化に備えよ その時の資料 PDF
false sharing の問題 については、OpenMP による共有メモリ並列プログラミング に説明がある。

このようなことを総合すると CUDA や PS3 の SPE のように、コードとデータをパッケージ化して、コアに処理を依頼するような形のプログラミングモデルに向かっているのだろうか?
CUDA で、GPU用に書いたソースコードとCPU用のソースコードが共用できるのであれば、GPU も CPU もわけ隔てなく、空いているコアへ処理を依頼することなども出来そうだが。



投稿者 Takenori : 2008年01月14日 22:17




comments powered by Disqus
Total : Today : Yesterday : なかのひと