なぜscikit-learnのGridSearchCVが非常に多くのスレッドを生成するのですか

Question

現在実行中のGridSearchの出力はpstreeです。私はプロセスが進行中であることを知りたいと思っています。

├─bash─┬─perl───20*[bash───python─┬─5*[python───31*[{python}]]] 
│  │       └─11*[{python}]] 
│  └─tee 
└─bash───pstree 

私は関係のないものを削除しました。カッコはスレッドを意味します。

• 私はpythonジョブを開始するためにparallel -j 20を使用したため、perlの外観があります。ご覧のとおり、20*には20のプロセスがあります。
• bash各プロセスの前に、source activate venvのAnaconda仮想環境がアクティブ化されているためです。
• 各pythonプロセスの内部には、別の5つのpythonプロセス（5*）が生成されています。これは、n_jobs=5〜GridSearchCVと指定したためです。

私の理解はここで終わります。

質問は：誰もが、なぜグリッドサーチと一緒に別の11 Pythonのスレッド（11*[{python}]）がある、と31件のPythonのスレッド（31*[{python}]）は5グリッドサーチジョブの各内部で生成された説明することができますか？

更新は：興味があればあなたが簡単に再現するために、私は要旨にtest codeを包ん

：アップデート（2017年9月27日）GridSearchCV

Cs = 10 ** np.arange(-2, 2, 0.1) 
skf = StratifiedKFold(n_splits=10, shuffle=True, random_state=0) 
clf = LogisticRegression() 
gs = GridSearchCV(
    clf, 
    param_grid={'C': Cs, 'penalty': ['l1'], 
       'tol': [1e-10], 'solver': ['liblinear']}, 
    cv=skf, 
    scoring='neg_log_loss', 
    n_jobs=5, 
    verbose=1, 
    refit=True) 
gs.fit(Xs, ys) 

を呼び出すためのコードを追加しました。

Mac Proと複数のLinuxマシンで同じコードをテストし、@igrinisの結果を再現しましたが、Mac Proのみでした。 Linuxマシンでは、これまでとは違う数字が得られますが、一貫しています。したがって、生成されるスレッドの数は、GridSearchCVへの特定のデータフィードに依存する場合があります。

python─┬─5*[python───31*[{python}]] 
     └─3*[{python}] 

Mac ProおよびLinuxマシンでhomebrew/linuxbrewによってインストールされるpstreeは異なることに注意してください。ここで私は私が使用される正確なバージョンを投稿：

マック：

pstree $Revision: 2.39 $ by Fred Hucht (C) 1993-2015 
EMail: fred AT thp.uni-due.de 

のLinux：Mac版は、私が考えていたこれは、スレッドを表示するオプションを持っていないようです

pstree (PSmisc) 22.20 
Copyright (C) 1993-2009 Werner Almesberger and Craig Small 

なぜ彼らは結果に見えないのでしょうか。私はMac Pro上のスレッドを簡単に検査する方法を見つけていません。あなたが方法を知っている場合、コメントしてください。

アップデート（2017年10月12日）実験の別のセットでは

、私は環境変数OMP_NUM_THREADSを設定すると違いがあることを確認しました。

bash───python─┬─23*[python───63*[{python}]] 
       └─3*[{python}] 

ここでのLinux parallelなし使用：不明の利用が生み出さずに、上記のよう

はexport OMP_NUM_THREADS=1する前に、（この場合は63）多くのスレッドがあります。 n_jobs=23。

export OMP_NUM_THREADS=1以降、スレッドは生成されませんでしたが、3つのPythonプロセスがまだ存在していますが、その使用はまだ認識されていません。

bash───python─┬─23*[python] 
       └─3*[{python}] 

それは私のGridSearchCVの仕事の一部に誤りが発生するので、私が最初にOMP_NUM_THREADSに出くわした、エラーメッセージがsklearn.GridSearchCVドキュメントからこの

OMP: Error #34: System unable to allocate necessary resources for OMP thread: 
OMP: System error #11: Resource temporarily unavailable 
OMP: Hint: Try decreasing the value of OMP_NUM_THREADS. 

Answer 1

のようなものです：

n_jobs：int型、デフォルト= 1 並行して実行するジョブの数。

pre_dispatch：int、またはstring（任意） 並列実行中にディスパッチされるジョブの数を制御します。この数を減らすと、CPUが処理できるよりも多くのジョブがディスパッチされるときに、メモリ消費が爆発的に増加するのを防ぐのに役立ちます。このパラメータは、 なしです。この場合、すべてのジョブがただちに作成され、生成されます。ジョブのオンデマンドスポーンによる遅延を避けるため、軽量で高速実行のジョブに使用します。 生成された合計ジョブの正確な数を指定するint n_jobsの関数として式を指定する文字列私は適切に文書を理解していれば「2 * n_jobs」

に、GridSearchCVは、格子点の数として、スレッドの束を生成します、とだけ同時にn_jobsを実行します。私はあなたの40の可能な値のいくつかの種類の上限を信じています。 pre_dispatchの値で試してみてください。

私が信じている別の11スレッドは、同じレベルで表示されているように、GridSearchCV自体とは関係がありません。私はそれが他のコマンドの残りだと思う。

ところで、私はMacでこのような動作を観察していません（GridSearchCVによって5つのプロセスが生成されるのを見てください）。互換性のないライブラリに由来する可能性があります。 sklearnとnumpyを手動で更新してみてください。第二のコメントへ

└─┬= 00396 *** -fish 
    └─┬= 21743 *** python /Users/***/scratch_5.py 
    ├─── 21775 *** python /Users/***/scratch_5.py 
    ├─── 21776 *** python /Users/***/scratch_5.py 
    ├─── 21777 *** python /Users/***/scratch_5.py 
    ├─── 21778 *** python /Users/***/scratch_5.py 
    └─── 21779 *** python /Users/***/scratch_5.py 

答え：

実際にあなたのコードだ

は、ここに私のpstree出力（プライバシーのために削除されたパスの一部）です。

N = 50000 
Xs = np.concatenate((np.random.random(N) , 3+np.random.random(N))).reshape(-1, 1) 
ys = np.concatenate((np.zeros(N), np.ones(N))) 

100kサンプルは、約1分間CPUをビジーにするのに十分でした。