2012-03-21 8 views
6

こんにちは、MCパッケージを使用して、plyrのライブラリのddplyを使用しようとしています。それは計算をスピードアップしているようではありません。これは私が実行するコードです:plyrを持つマルチコア、MC

require(doMC) 
registerDoMC(4) 
getDoParWorkers() 
##> 4 
test <- data.frame(x=1:10000, y=rep(c(1:20), 500)) 
system.time(ddply(test, "y", mean)) 
    # user system elapsed 
    # 0.015 0.000 0.015 
system.time(ddply(test, "y", mean, .parallel=TRUE)) 
    # user system elapsed 
    # 223.062 2.825 1.093 

アイデアはありますか?

+3

実行している実際の計算に応じて、 'data.table'パッケージは実際にそれらを高速化するかもしれません。すべての美徳のために、 'plyr'パッケージの' split-apply-combine '実装は実際にはかなり遅いですが、 'data.table'はまずスピードのために設計されています。 (もしあなたが興味をそそられているなら、できるだけ多くの出発点を得るために '[r] [data.table] plyr'のようなものをSOで検索してください)。 –

+0

ジョシュさん、ありがとうございました。 – Alex

答えて

10

mean機能は、分割されたセクションを各コアに配布して結果を取得するのに必要な通信コストに対して速すぎます。

これは、分散コンピューティングでは一般的な「問題」です。彼らはコスト(ノード間の通信)と利益(複数のコアを使用する)があることを忘れるため、すべてをより速く実行することを期待しています。

plyrでの並列処理に特有のこと:複数のコアで機能が実行されるだけです。分割と結合は依然として1つのコア上で行われているため、適用する関数は、plyr関数を並列に使用するとメリットを得るには非常に計算量が必要です。

+0

これは単なる例です。私が持っている実際のデータフレームは、2000グループの400万行です。パラレルのコードと返りのないコードは同じ時間です。 – Alex

+1

@Alex:もしあなたのdata.frameが巨大ならば、関数を適用するのではなく、 'ddply'で費やされた時間の大部分が分割して結合するので、あなたの関数はより計算的に集中する必要があります。 –

+0

私は..参照するので、それが配布する部分は関数の実際のアプリケーションです..それはまだ1コアで分割しますか? – Alex

1

ジョシュアさんの答えに続けて、この操作を迅速化したい場合は修正があります。それはMap-reduceのイデオロギーに触発され、私はサンプルデータセットでPOCをやっていました。

私は降雪ライブラリを使用しました。あなたはdoMCでもうまくいくと思います。私たちは今、分散方式で分割結合ルーチンを行っていることを考えると

# On my phone, please pardon typos/bugs 

test <- data.frame(x=1:1000000, y=rep(c(1:20), 500)) 

testList = list() 
testList[[1]] <- test[c(1:250000),] 
testList[[2]] <- test[c(250001:500000),] 
testList[[3]] <- test[c(500001:750000),] 
testList[[4]] <- test[c(750001:1000000),] 

# Write a function for the above - Need to find optimum number of splits 

sfInit(parallel = TRUE, cpus=4) 
sfCluster(plyr) 
meanList = sfClusterSpplyLB(testList, function(x) ddply(test, "y", mean)) 

sfStop() 

aggregate(meanList, by=list(y), FUN=mean) 

このかもしれない助けます。これは、スプリットのサイズが同じで、合計、最小/最大、カウントなどで機能する場合に機能しますが、これを使用できない操作がいくつかあります。

関連する問題