2008-05-13

2ちゃんねる Pythonのお勉強 Part26よりParallel Python関係の議論抜粋

Pythonのお勉強 Part26
からの抜粋。なんともタイムリーなことに、Parallel Pythonが話題になっている。
この議論で288が指摘している事は、やはり的を得ているのではないだろうか。
Python->C/C++という移植で10倍速くなるなんてことは珍しくない。
(例えば、C++からMecabを利用した時の速度は驚異的ですらあるが、Pythonから利用した場合はちょっとのんびりとしたものになってしまう。)
numpyがうまくハマっているPythonスクリプトとかなら別ですけど。

で、以下その議論抜粋です。。。。
---------------------

169 :デフォルトの名無しさん:2008/05/06(火) 21:31:30
threadって計算速度の向上に効果ある?
a = b1 + b2の計算を(a,b1,b2はarray)
b1とb2をthreadで計算して,
それぞれ計算終了後に足すというプログラムを作ったんだけど,
普通にb1とb2をメインスレッドで順番に求めて足した方が早かった...

ちなみにb1とb2の計算はダミーのforループ10000回です.

244 :デフォルトの名無しさん:2008/05/10(土) 04:27:34
>>169
Parallel Python というパッケージがあるのを知ったので参考までに紹介しとく。
http://www.parallelpython.com/
スレッドじゃなく複数プロセスで並列実行する仕組みらしい。
Python のみで実装されていて非常にシンプルなパッケージ構成になっている。
マルチコア環境の場合はスレッドモジュール風に使える。
クラスタ環境では各ノードで計算サーバ(ppserver.py)をしておく仕組みになっている。
応用プログラムはどちらの環境でも同じにできるっぽい。

手元の共有メモリマシンで付属サンプル(sum_primes.py)を実行したら下のようになった。
素数の和を計算するプログラムなのでプロセス間通信はほとんどないけど、
並列化のオーバヘッドはあるわけで、なかなか良好な結果だと思う。

並列度,実行時間(秒),速度向上率
1,  17.54,  1.000
2,  8.781,  1.998
4,  4.424,  3.965
8,  2.261,  7.759

245 :169:2008/05/10(土) 13:53:14
>>244
おおお,サンクス!
早速いじってみまふ。

280 :244:2008/05/10(土) 23:51:28
引続き Parallel Python をいじってみたんだけども、このシステムはマスタワーカモデルを前提にしているみたいだ。
つまり、マスタが仕事の集合を持っていて、有限個のワーカに1つずつ仕事を割り当てる。仕事を終えたワーカは
マスタから新しい仕事をもらって処理する。これを仕事の集合が空になるまで続ける。

ワーカ間で通信をする機能は提供されていないし、特定のワーカ(たとえば特定のリモートホスト上のppserver.py)に
特定の仕事を割り当てることもできないっぽい。Parallel Python が有効かどうかは実現したい並列アルゴリズムが
マスタワーカモデルに適合するかどうかに依る希ガス。

283 :デフォルトの名無しさん:2008/05/11(日) 00:40:31
>>280
具体的には、どういう用途に使えそうなんですか?

285 :デフォルトの名無しさん:2008/05/11(日) 01:34:00
>>283
最も適しているのは並列処理の分野で embarrassingly parallel と呼ばれるカテゴリに属する種々の計算、
すなわち入力データを複数の独立した部分に分割できて、各部分について他から独立して計算が行なえる
タイプの用途に適している。
http://en.wikipedia.org/wiki/Embarrassingly_parallel
Wikipediaに例があがっている。フラクタル計算とか3DCGのレンダリング(例:レイトレーシング)とか力任せの
暗号解読とか色々ある。

並列処理って概して複雑で長時間計算し続ける必要のある応用が多い。そういう応用には C とか Fortran を
使うことがほとんどなんだけど、きちんと動くようになるまでの開発時間が長くてデバッグがたいへんだったりする。
そういう並列プログラムの試作(プロトタイピング)に Python が使えたらいいなーと個人的には思っている。

288 :デフォルトの名無しさん:2008/05/11(日) 09:43:58
>>285
PythonでCPU8個使って並列計算するよりCで書いたプログラムの方が速そうだったり。。。

289 :デフォルトの名無しさん:2008/05/11(日) 09:57:09
>>288
何言ってんだ?

290 :デフォルトの名無しさん:2008/05/11(日) 10:28:52
>>289
あ?ヤンのかコラ


295 :デフォルトの名無しさん:2008/05/11(日) 14:39:25
>>285
自分も並列化するときのプロトタイプとしてPythonの並列環境を使ってみたいと
考えているんだけれど、今のところプロトタイプとしての感触はどう?

データ分割の楽な問題ってCとかFORTRANでもOpenMPを注意深く使うだけでも早くなる事が
多いし、MPIでも慣れれば苦労せずに書けるけれど、そうでない、スレーブ間での通信が必要
とかうまく分割できないとかそういう問題はMPIでやろうとするとデバッグが(;゚д゚)
なことになりがちで、そういう用途にPythonのプロトタイプが役に立つなら素晴らしいと思う
実はC並列版とそれほど速度とメモリ使用量が変わらないとかなら最高
C並列版より速ければ神

296 :デフォルトの名無しさん:2008/05/11(日) 16:53:12
Parallel Python だけど pp.Server.__scheduler() を適当に書き直せばワーカと仕事の対応(割り当て)を
ユーザ側で決められそうな希ガス。問題はワーカ間のプロセス間通信。これが一番面倒なところなんで
自前で実装となると Parallel Python を使ううまみがほとんどない・・・。

やっぱ MPI の Python バインディングあたりが一番現実的な解かなー。でもなんか気が重いんだなー。
もっと Python らしく lightweight なソリューションがないかなー。

>>288
Python の並列プログラムより C の逐次プログラムの方が速そうってことだよね。
そういうことは十分(多分頻繁に)あると思われ。

>>295
残念ながらまだ並列プログラムのプロトタイプ用途には使えてなくて感触を得るところまでいってない。
理由は単純で、Python で手軽に並列プログラミングを実現できる道具を見つけられていないから。
>>209に書いたようにいろいろ試してるんだけどなかなか・・・。

ただ、個人的には Python を並列化のプロトタイピングに使うのは大いに有望だと思っている。
プロトタイピングの場合、欲しいのは並列度やデータ量を上げたときの実行時間の変化であって、
実行速度が多少遅くて実験に時間がかかるとしても知りたいことは分かるはずだから。
プロセス間通信にソケットを使うとすると、データ量が大きくなれば Python でも C 等と同じぐらいの
速度が出る(ハズ)。演算量が多い部分に numpy 等の C/Fortran で書かれた数値カーネルを使うことに
すれば、プロトタイピング用途には十分な速度とメモリ使用量が得られるのではと思う。