3

私はHaskellで半明示的な並列処理を読んでいて、混乱しています。

      パー :: a -> b -> b

このアプローチにより、Haskell プログラムのすべての部分式を並列に評価することで、自動的に並列化を行うことができると言われています。しかし、このアプローチには次の欠点があります。

1) 作業の小さな項目が多すぎるため、効率的にスケジュールを立てることができません。私が理解しているように、Haskell プログラムのすべての行に par 関数を使用すると、あまりにも多くのスレッドが作成され、まったく実用的ではありません。そうですか?

2) このアプローチでは、並列処理はソース プログラム内のデータの依存関係によって制限されます。私の理解が正しければ、すべての部分式が独立していなければならないということです。同様に、par 関数では、a と b は独立している必要があります。

3) Haskell ランタイム システムは、式 a の値を計算するためのスレッドを必ずしも作成しません。代わりに、親スレッドとは異なるスレッドで実行される可能性があるスパークを作成します。

だから、私の質問は次のとおりです。最終的に、ランタイム システムは a を計算するスレッドを作成しますか? または、式 b を計算するために式 a が必要な場合、システムは a を計算するための新しいスレッドを作成しますか? そうでなければ、そうはなりません。これは本当ですか?

私は Haskell の初心者なので、私の質問はまだ基本的なものかもしれません。ご回答有難うございます。

4

2 に答える 2

3
  1. はい。それで合っています。計算する式ごとにスパークを作成しても、何も得られません。火花が多すぎます。これを管理しようとするのがData Parallel Haskellです。DPH は、ネストされた計算を適切なサイズのチャンクに分割し、並列で計算できるようにする方法です。これはまだ調査中の作業であり、おそらく主流の消費の準備ができていないことに注意してください.

  2. 繰り返しますが、あなたは正しいです。a が b に依存している場合、b が b の計算を開始できるようにするために必要なだけ a を計算する必要があります。

  3. うん。スレッドには、いくつかの代替手段と比較して、実際にはかなり高いオーバーヘッドがあります。火花はサンクに似ていますが、時間とは無関係に計算できます。

いいえ、RTS は a を計算するスレッドを作成しません。RTS が実行する必要があるスレッドの数 ( +RTS -N66 スレッド) を決定することができ、それらはプログラムの実行中維持されます。

par火花を発生させるだけです。火花は糸ではありません。スパークはワーク プールを占有し、スケジューラはワーク スティーリングを実行します。つまり、スレッドがアイドル状態になると、プールからスパークを取得して計算します。

于 2013-09-01T20:16:34.977 に答える