8

このビットのコード ( R Benchmark 2.5から適応) が、反復回数が増えるにつれて (平均して) ますます遅くなる理由を理解するのに苦労しています。

require(Matrix)  
c <- 0;
for (i in 1:100) {
  a <- new("dgeMatrix", x = rnorm(3250 * 3250), Dim = as.integer(c(3250, 3250)))
  b <- as.double(1:3250)

  invisible(gc())
  timing <- system.time({
    c <- solve(crossprod(a), crossprod(a, b))
  })
  print(timing)

  rm(a, b, c)
}

以下はサンプル出力で、実行ごとにわずかに異なります。

私が理解しているように、ある反復から次の反復まで何も保存されるべきではありませんが、タイミングは最初の数ループの 1 秒から後のループの 4 秒以上までゆっくりと増加します。これを引き起こしている原因と、どうすれば修正できるか分かりますか?

for ループを *apply に切り替えると、同様の結果が得られるようです。

コードが最適化されていないことは知っていますが、広く使用されているベンチマークからのものであり、この動作の原因によっては、結果に深刻な偏りがあることを示している可能性があります (デフォルトでは 3 回しか繰り返されません)。

Mac OS 10.8.4 で R バージョン 3.0.1 (x86_64) を 16 GB RAM (多くは無料) で実行しています。BLAS は OpenBLAS です。

4

2 に答える 2

1

1 つの解決策は、コンパイラ パッケージを使用してコードをバイト コードにコンパイルすることです。これにより、反復ごとに同じコンパイル済みコードが呼び出されるため、奇妙なタイミングの問題が解消されます。また、コードを高速化する必要があります。コードでコンパイラを有効にするには、次の 2 行を含めます。

library(compiler)
enableJIT(3)

コードをコンパイルしても問題が解消されない場合は、疑わしい問題のセットが絞り込まれます。

于 2013-07-10T17:33:20.113 に答える
0

おそらく、for ループ内のコードを関数にしてみてください。このようにして、ある実行が別の実行に影響を与える可能性はまったくありません。また、過度の rm() および gc() の使用によって引き起こされる混乱を取り除きます。

require(Matrix)

NewFun <- function() {
    a <- new("dgeMatrix", x = rnorm(3250 * 3250), Dim = as.integer(c(3250, 3250)))
    b <- as.double(1:3250)
    timing <- system.time({
        c <- solve(crossprod(a), crossprod(a, b))
    })
    print(timing)
}

for (i in 1:100) {
    NewFun()
}
于 2013-07-10T14:45:31.570 に答える