問題タブ [pathos]

最近、研究用のクラスを含むプログラムを作成し、それを並列化しようとしました。Python 2.7 の multiprocessing.Process を JoinableQueue とマネージド データで使用すると、プログラムは最終的に無効なプロセスでハングします。

_calc_parallel は、他のいくつかのクラス メソッドを呼び出します。

http://bytes.com/topic/python/answers/552476-why-cant-you-pickle-instancemethodsの他の場所にある copy_reg オプションを使用して、この目的で multiprocessing.Pool を使用しようとさえしました。

ただし、pool.map_async は self._calc_parallel を呼び出していないようです。私は両方のケース (プロセスとプール) で何かを見落としていることを知っていますが、何が何であるかは正確にはわかりません。通常、40,000 を超える要素を処理しています。

助けてくれてありがとう。

アップデート

他のいくつかの投稿を読んだ後、pathos.multiprocessing も試しました。

そして、以前の試みと同様に、これもメソッドを呼び出さなくてもすばやく処理できるようです。

更新 2

コードを改良して、巨大なクラスをより小さく、より管理しやすいコンポーネントに分割することにしました。ただし、pathos.multiprocessing を使用すると、以前に投稿したように別の状況に遭遇します (リンクを参照)。私の新しいコードには、計算に使用できるオブジェクトがあり、そのメソッドを介して値を返す必要があります。

別の機能だと思っていましたfunc(dataobj, force)が、これも役に立たないようです。現在の速度では、単一のプロセッサでの完全な計算には 1000 時間以上かかると見積もっています。

アップデート 3 (2015 年 4 月 30 日)

@MikeMcKernsの有益な洞察のおかげで、私は可能な解決策に落ち着いたかもしれません. iMac (クアッド コア) またはクラスターの 16 コア ノードでは、結合のない粗粒度 (CG) システムの場合、2 倍itertools.imapが最適なソリューション (1000 CG サイト) のように思われることがわかりました。軌道フレームあたり約 5.2 秒で。結合の詳細 (水を表す 3000 の CG サイト) を含むシステムに移ると、iMac (1 コアを使用) でitertools.imap、pathos.ThreadingPool.uimap(4 スレッド) 約 85 秒/フレームでクロックインします。@MikeMcKerns のコメントで提案されているように、プロセス プール (4 コア x 2)/スレッド プール (4 スレッド) を試みると、計算時間が 2.5 倍に増加しました。16 コア クラスター (32 pp/16 tp) では、この CG システムも遅くなります (約 160 秒/フレーム)。iMac (1 コア/4 スレッド) 上の 42,778 サイトと多数の結合を備えた CG システムは、約 58 分/フレームのクロックを記録する可能性があります。クラスターの 16 コア ノードでこの大規模システムをまだテストしていませんが、プロセス プール/スレッド プールを使用してさらに高速化できるかどうかはわかりません。

例:

システムが大規模になればなるほど、マルチプロセッシングから得られるメリットが大きくなると思います。大規模な CG システム (42,778 サイト) は、0.02 秒/サイト (3000 CG サイト) または 0.05 秒/サイト (結合なしの 1000 サイト) と比較して、約 0.08 秒/サイトかかることがわかっています。

計算時間を短縮しようと努力しているうちに、一部の計算を削減できる領域 (global変数やアルゴリズムの変更など) を発見しましたが、本格的な multirpcoessing によってこれをさらに削減できれば、それは素晴らしいことです。

上記を実行すると、次のエラーが発生します。

これは、インタラクティブな IPython コンソール (Python 2.7 の Anaconda ディストリビューション) の Windows 7 64 ビット マシン上にありました。pathos バージョン 0.2a1.dev0 と Dill バージョン 0.2.2 を使用しています。このエラーは、「プール」を作成するたびに再現できるようです。

logging.logger などの重要なオブジェクトをピクルするときの頭痛の種を取り除くために、pathos.multiprocessing を使い始めました。ただし、新しいスレッドでインポートが利用できないという問題が発生しています。その結果、その新しいスレッドでそれらのモジュールを「再インポート」する必要があります。具体的には、このケースは次のエラーのために実行されません。

次のコードは、組み込みの multiprocessing モジュールの下では機能しますが、機能しません。

ただし、次のコードは pathos.multiprocessing で機能します。

次の例では

コードの両方の部分は、次の出力を出力する必要があります (明らかに、必ずしも同じ順序であるとは限りません)。

これはコードベースの残りの部分と一致しているため、コードの最初のスニペットのいくつかのバリエーションを使用できるようにしたいと考えています。ただし、どんな助けでも大歓迎です。

この質問は非常に一般的であり、十分に明確ではない可能性があるため、事前に謝罪する必要があります. 問題は、それ自体がいくつかのサブタスクにプロセスのプールを使用し、大量の I/O 操作を行う Python 関数をどのように並行して実行するかということです。それは有効なタスクですか？

もう少し情報を提供しようと思います。test_reduce()たとえば、並列に実行する必要があるプロシージャがあります。私はそれを行うためにいくつかの方法を試しましたが (以下を参照)、それらすべてが失敗する理由を理解するための知識が不足しているようです。

このtest_reduce()手順は多くのことを行います。それらのいくつかは、他のものよりも質問に関連しています（以下にリストします）：

• multiprocessingモジュール(sic!)、つまりpool.Poolインスタンスを使用します。
• MongoDB 接続を使用し、
• libs に大きく依存してnumpyおり、scikit-learn
• コールバックとラムダを使用し、
• ライブラリを使用して、dillいくつかのものをピクルスにします。

multiprocessing.dummy.Pool最初に（スレッドプールのようです）を使用しようとしました。このプールの具体的な内容と、なぜ「ダミー」なのかはわかりません。すべてが機能し、結果が得られました。問題はCPU負荷です。並列化されたセクションでtest_reduce()は、すべてのコアで 100% でした。同期セクションの場合、ほとんどの場合、約 40 ～ 50% でした。このタイプの「並列」実行の全体的な速度が向上したとは言えません。

次に、この手順のmultiprocessing.pool.Poolインスタンスを自分のデータに使用しようとしました。map以下で失敗しました。

cPickle私はそれが原因であると推測しpathos、はるかに高度な pickler を使用するライブラリを見つけましたdill。ただし、失敗することもあります。

さて、このエラーは私がまったく理解していないものです。プールで機能する場合、プロシージャからの出力がないstdoutため、何が起こっているのかを推測するのは困難です。私が知っている唯一のことはtest_reduce()、マルチプロセッシングが使用されていない場合に正常に実行されることです。

では、これほど重くて複雑なものをどのように並行して実行するのでしょうか?

私のメインコードの例である次のコードではpathos.multiprocessing、ループの反復速度を上げるために使用しようとしました。マルチプロセッシングで実装された各反復の出力は2-D 配列です。クラスメソッドで使用したかったので、pathos.multiprocessing代わりに使用しました。のメソッドを使用して出力をリストに収集しましたが、空のリストが返されます。失敗する理由がわからないmultiprocessingapipepathos.multiprocessing

なにか提案を？

短い短いバージョン:

インスタンス メソッドを使用するコードの並列化に問題があります。

より長いバージョン:

この python コードでは、次のエラーが発生します。

これは、私が抱えている実際の問題の単純化されたバージョンです。

ここでの推奨事項により、pathos.multiprocessing を使用しています: Multiprocessing: Pool and pickle Error -- Pickling Error: Can't pickle <type 'instancemethod'>: attribute lookup __builtin__.instancemethod failed

pathos.multiprocessing を使用する前は、次のエラーが発生していました。

dill を評価していますが、このシナリオが処理されるかどうかを知りたいです。Python プロセスでモジュールを正常にインポートするケースがあります。dill を使用してシリアライズし、そのモジュールを含まない別の sys.path を持つ別のプロセスにそのモジュールをロードできますか? 現在、インポートに失敗していますが、何か間違っている可能性があります。

例を次に示します。foo.py モジュールのパスが sys.path にあるこのスクリプトを実行します。

ここで、PYTHONPATH に foo.py のディレクトリがない場所でこのスクリプトを実行します。

次のスタック トレースで失敗します。

では、2 つのプロセス間で同じ python パスが必要な場合、python モジュールをシリアル化する意味は何ですか? または、言い換えれば、「import foo」呼び出しを行うよりも、ディル経由で foo をロードする利点はありますか?