共有ライブラリ化とインストール可能化パッチ
上記パッチをsourceforgeに登録して頂きました。ありがとうございます > masahase様
URLはこちら:https://sourceforge.jp/tracker/index.php?func=detail&aid=11559&group_id=2587&atid=9605
これまでは開発者ローカルのディレクトリに置くことを想定していましたが、システムにインストールして使うこともありそうですね。次のバージョンあたりでうまく取り込みたいと思います。ありがとうございました。
マニュアルの英訳を完了
マニュアルの英訳を完了しました。それに伴い、バージョンを0.4として、新たにリリースしました。プログラム自身の変更はありません。
もうちょっと宣伝しないとなぁ…。英語圏にも。
Intel Threading Building Blocksと実行粒度
以前の日記でIntel Threading Building Blocks(以下TBB)について書いたが、その実行形態についてちょっと考えてみた。
TBBでは、(ソースを追いかけてみると)ループの並列化なんかも最終的にはタスクに落ちる様子。TBBにおける「タスク」とは、特定のクラス("class task")を継承したクラスのインスタンスで、それを"spawn()"という関数に渡すと、タスククラス中の"execute()"というメソッドを並列に実行してくれる、という形になっている。
なんか、リファレンスカウントの設定とか、インスタンスをnewするときに、メモリアロケータを指定していたりするけど、本質的にはそれだけ。
spawn()は適当なデータ構造(ツリー?)にタスクを登録する。で、スレッドがそこからタスクを取り出しては実行する("execute()"を呼び出す)という形態なんだろう。
で、これの何が嬉しいかだが、やはりタスクのオーバヘッドが小さいことだろう。タスクといいながら、実体はただのクラスのインスタンスなので。
タスクのオーバヘッドが小さいと、実行粒度を小さくすることができる。その結果、比較的小さい処理でも並列に実行して、速度を稼ぐことができる。
…ということはあんまり主張していないのかな?チュートリアルでは、それより、負荷分散がうまく行くことを利点にあげている。
しかし、こういう実行形態だと、このタスクがブロックすると、まずいことになる。スレッドは、
- ツリー?からタスクを取り出す
- execute()を呼び出す。
- 終了したら次のタスクを取り出す
- 以下繰り返し
という処理を行っているのだとすると、"execute()"を呼び出す所でブロックしてしまうと、ツリーに他に実行可能なタスクがあってもそのスレッドは動作を停止してしまうからである。
チュートリアルにもこう書いてある:
The task scheduler is intended for high-performance algorithms composed from non-blocking tasks. It still works if the tasks rarely block. However, if threads block frequently, there is a performance loss when using the task scheduler because while the thread is blocked, it is not working on any tasks.
TBBはfuture(PARDSで言うSync
PARDSでも(簡単に)TBBと同じような形式のタスクをサポートすることはできるけど、あんまり気がすすまないなぁ。forkを使ったアドレス空間の分離も使えなくなるし。プログラマの負担になるだけだよなぁ…
Version 0.31リリース
最近リリースしてなかったので、小変更ですがリリースしました。
主な変更点は、共有メモリとしてmmapの利用をサポートしたことで、Mac OS Xではこれがデフォルトになります。
また、n-queens問題を解くプログラムをサンプルとして追加しました。
また、英語マニュアルを更新しました。
URLはhttps://sourceforge.jp/projects/pards/files/です。
また、リリースしていなくても、http://cvs.sourceforge.jp/cgi-bin/viewcvs.cgi/pards/pards.tar.gz?view=tar からcheck inしたファイルの最新版をtar.gzとしてダウンロードできます。
Windows実装
とりあえず、CreateFileMappingとMapViewOfFileによる共有メモリと、CreateSemaphore, OpenSemaphore, WaitForSingleObjectによるセマフォについては、動作を確認。
んー、これで一応実現できるんじゃないか?
forkされたプロセスはWin32サブシステムに接続できていないけど。
Win32 APIのすべてがWin32サブシステムへの接続を要求するわけでは無いようなので(単にNative APIへのラッパになっている様子:上記のAPIもそう)、一応実用になるかも。File I/OもWin32 API経由で子プロセスから実行できるみたいだし。いや、不具合がある可能性は否定できないけど。