7

重複の可能性:
R 限定の並列処理

R マルチコアでいくつかのコードを作成し、24 コア マシンで実行しています。実際には12コアしかありませんが、ハイパースレッド化されているため、24コアあるように見えます.

奇妙なのは、すべてのスレッドが同じシングル コアで実行されていることです。そのため、それぞれが単一のコアで実行され、利用可能なすべてのコアを噛み砕くのではなく、わずかな量の CPU しか使用しません。

簡単にするために、4 つのスレッドを実行しています。

mclapply( 1:30, function(size) {
    # time consuming stuff that is cpu bound (think "forecast.ets" et al)
}, mc.cores = 4, mc.preschedule = F )

これを実行する前に、1 つのコアで実行されている R プロセスが既に存在し、そのコアの容量を 100% 使用しています。

ここに画像の説明を入力

次に、「マルチコア プロセス」を起動すると、4 つの余分なスレッドが同じコアをめぐって戦います!:

ここに画像の説明を入力

...つまり、それぞれが 1 つのコアの 12%、つまり利用可能な処理能力の約 1% を取得しますが、それぞれが 1 つのコアの 100% を取得できるはずです。また、もう一方の R プロセスは、コアの 50% しか取得できなくなりました。

OSはUbuntu 12.04 64bitです。ハードウェアはインテルです。R はバージョン 2.15.2 の「トリック オア トリート」です。

考え?(降雪を使用できることはわかっていますが、変数がたくさんあるので、すべてを使用する必要はありませんsfExport!)

編集:ああ、どこかにグローバルロックがあると思いますか?それでも、2 つの完全に別個の R プロセス間で競合が発生するのはなぜでしょうか? それぞれがコアの CPU の 100% を使用して、2 つの R プロセスを並列で問題なく実行できます。

Edit2: Dirk のポインターのおかげで、私は openblas を再構築しました。

ここに画像の説明を入力

4

1 に答える 1

8

考えられる問題は、プロセスが1つのコアに固執するようにCPUアフィニティを設定するOpenBLASパッケージの考えられる副作用です。議論についてはRlimitedでの並列処理を参照し、修正されたr-sig-hpcリストの詳細な議論へのリンクを参照してください。

于 2012-10-29T17:58:47.197 に答える