[解決済み】Python 3におけるConcurrent.futuresとマルチプロセシングの比較

質問

Python 3.2導入 コンカレントフューチャーズ これは、旧来のスレッド機能と マルチプロセシング モジュールがあります。

CPUに拘束されるタスクにこれを使用する場合、旧来のマルチプロセッシングモジュールと比較して、どのような利点と欠点がありますか？

この記事 は、より使いやすくなっていると思いますが、そうでしょうか？

どのように解決するのですか？

を呼び出すことはありません。 concurrent.futures より高度なものです。 よりシンプルに このインターフェースは、並列化の基本的なギミックとしてマルチスレッドとマルチプロセスのどちらを使用しても、ほとんど同じように動作します。

つまり、「よりシンプルなインターフェイス」のほぼすべての例と同じように、トレードオフが関係しているのです：学習曲線が浅く、その理由の大部分は、利用できるものが非常に少ないことです。 への しかし、選択肢が少ないため、リッチなインターフェースにはないフラストレーションを感じるかもしれません。

CPU拘束のタスクに関しては、あまりに仕様が不十分で、あまり意味のあることは言えません。 CPython の CPU バインドタスクでは、高速化のチャンスを得るには、複数のスレッドではなく、複数のプロセスが必要です。 しかし、どの程度の速度向上が得られるかは、ハードウェアやOSの詳細、特に特定のタスクがどの程度のプロセス間通信を必要とするかに依存します。 プロセス間並列化の仕組みはすべてOSのプリミティブに依存しており、それを利用するための高レベルのAPIは、最終的な速度の主要な要因ではありません。

編集：例

参照した記事で紹介されている最終的なコードですが、動作させるために必要なimport文を追加しています。

from concurrent.futures import ProcessPoolExecutor
def pool_factorizer_map(nums, nprocs):
    # Let the executor divide the work among processes by using 'map'.
    with ProcessPoolExecutor(max_workers=nprocs) as executor:
        return {num:factors for num, factors in
                                zip(nums,
                                    executor.map(factorize_naive, nums))}

以下は、まったく同じことを multiprocessing の代わりに

import multiprocessing as mp
def mp_factorizer_map(nums, nprocs):
    with mp.Pool(nprocs) as pool:
        return {num:factors for num, factors in
                                zip(nums,
                                    pool.map(factorize_naive, nums))}

を使用することができることに注意してください。 multiprocessing.Pool オブジェクトをコンテキストマネージャとして使うことが Python 3.3 で追加されました。

どちらが作業しやすいかについては、基本的に同じです。

一つ違うのは Pool は、非常に多くの異なる方法をサポートしているので、それがいかに簡単であるかに気づかないかもしれません。 できる を使いこなすには、かなり上達する必要があります。

繰り返しになりますが、こうしたさまざまな方法があることは強みであり弱みでもあります。 状況によっては柔軟性が求められるので、長所でもあります。 弱点は、quot;できれば1つの明白な方法しかないことです"。 可能であれば）以下の方法のみにこだわるプロジェクト。 concurrent.futures は、その最小限のAPIをどのように使うかについて、無償の新規性がないため、おそらく長期的には保守しやすくなる。