誰でもRevol RのLU分解の異常な動作を説明できますか？

Question

単純なマトリックスベンチマークテストでは、Revolution AnalyticsR 2.13.2の のLU分解は行列乗算に比べて約5倍遅いことが示されています。 理論と長年の実践は、LUがA*Aの時間の1/3~2/3でなければならないことを示しています。

Revo RとMatlabはこのテストではインテルの数学カーネルを使用しています。 R 2.14.1はカーネルを使用していません。すべてが64ビットです。

以下の表2に異常が示されています。これは約A*Aで正規化された表1である。他の（明らかな）異常がありますが、LUが最も目立つものです。

     Table 1 (secs) 

        A*A  LU  A\b Det Inv 
---------------------------------------------------- 
R 2.14.1   0.757 0.43 0.45 0.20 1.11 
Revo R 2.13.2  0.063 0.35 0.11 0.03 0.14 
Matlab 2011b  0.062 0.08 0.10 0.07 0.16 
---------------------------------------------------- 
Averaged over 20 runs on a 1000x1000 random matrix 


         Table 2 (normalized) 

        A*A  LU  A\b Det Inv 
---------------------------------------------------- 
R 2.14.1    1  0.57 0.19 0.26 1.47 
Revol R 2.13.2  1  4.67* 1.58 1.33 2.17 
Matlab 2011b   1  0.67 1.72 0.61 1.68 
---------------------------------------------------- 
Note: x = A\b in Matlab is x <- solve(A,b) in R. 

---

UPDATE：私はサイモンUrbanekのアドバイスに従い、lu(A)でLUP = expand(lu(Matrix(A)));を交換しました。 RevoのR行は

Dell Precision 690, 2 x Intel® Xeon® E53405 CPU @ 2.33GHz, 
16GB ram, 2 Processors, 8 Cores and 8 Threads, 
Windows 7 Prof., 64-bit 

テーブルが含まれている作業中のレポートおよび使用されるコードの上に今秒の時間

    Revol R 2.13.2 

       A*A LU  A\b Det Inv 
      --------------------------------- 
    time  0.104 0.107 0.110 0.042 0.231 
    norm time 1.000 1.034 1.060 0.401 2.232 

---

あるhereです。

---

UPDATE 2：

私はマトリックス分解についてのみをテストするために、マトリックスのベンチマークを変更しました。これらは、他のすべてのマトリックスアルゴリズムが構築されている基盤です。これらが不安定な場合、他のすべてのアルゴリズムも不安定になります。 Core i7プロセッサは、それは高い需要を検知した場合、最大3.5GHzのへのクロック速度を増加させるインテルのターボブーストがあります

は、私は新しいブランド

Lenovo ThinkPad X220, Intel Core i7-2640M CPU @ 2.80GHz, 
8GB ram, 1 Processor, 2 Cores and 4 Threads 
Windows 7 Professional, 64-bit. 

注に変更されました。私が知る限り、Turbo Boostは3つのシステムのいずれにおいてもプログラム（mer）制御下にはありません。

これらの変更により、結果がより有用になります。

      Table 3. Times(secs) 

        A*A chol(A) lu(A) qr(A) svd(A) eig(A) Total 
----------------------------------------------------------------------------- 
R 2.14.1   0.904 0.157 0.260 0.568 4.260 6.967 13.11 
Revol R 2.13.2 0.121 0.029 0.062 0.411 1.623 3.265  5.51 
Matlab 2011b  0.061 0.014 0.033 0.056 0.342 0.963  1.47  
----------------------------------------------------------------------------- 
        Times(secs) averaged over 20 runs 



          Table 4. Times(normalized) 

        A*A chol(A) lu(A) qr(A) svd(A) eig(A) Total 
---------------------------------------------------------------------------- 
R 2.14.1   1.000 0.174 0.288 0.628 4.714 7.711 14.52 
Revol R 2.13.2 1.000 0.237 0.515 3.411 13.469 27.095 45.73 
Matlab 2011b  1.000 0.260 0.610 0.967 5.768 16.774 25.38 
---------------------------------------------------------------------------- 
        Times(secs) averaged over 20 runs 

表4から、擬似異常が消滅し、すべてのシステムが理論通りに動作することがわかります。

      Table 5. Times/Matlab Times 

        A*A chol(A) lu(A) qr(A) svd(A) eig(A) Total 
---------------------------------------------------------------------------- 
R 2.14.1   15  11   8  10  12  7  9 
Revol R 2.13.2  2  2   2  7  5  3  4 
---------------------------------------------------------------------------- 
         Rounded to the nearest integer 

---

Answer 1

FWIWあなたは分解の時間を計測していますが、行列のすべての時間を変換することによって作成オーバーヘッドていません。定期的にR：

# actual lu call 
> system.time(lu(A)) 
    user system elapsed 
    0.136 0.000 0.139 
# your code 
> system.time(expand(lu(Matrix(A)))) 
    user system elapsed 
    0.536 0.000 0.537 

あなたはオーバーヘッドを自分で作成しています。これは特に分解が速いときに重要です。また、使用しているBLASによってR自体のパフォーマンスが大きく変化するため、「R」のパフォーマンスについてはあいまいです。

（サイドノートとして - あなたのベンチマークでsystem.timeを使用することをお勧めします - また、あなたに関心のmicrobenchmark Rパッケージすることができる）