如何優化R性能

我正在嘗試瞭解最近的性能基準。我們有一個較大的腳本，在Redhat Linux機器上，性能比規格可比的Windows 7筆記本電腦慢50％。 Linux機器使用kvm進行虛擬化，並將16個內核分配給4個內核。該腳本不是密集型的，但有很多循環。主要是想知道是否有可用於優化的R編譯選項或者可能有助於使其更具可比性的任何內核編譯器選項。任何指針將不勝感激。我會試着讓另一臺機器使用原料金屬進行測試，以便進行更好的比較。如何優化R性能

Peformance comparisons

這些是我使用的編譯的Linux機器R上的配置標誌。我已經嘗試了很多，這似乎削減了大型數據集中綠色執行時間的12秒。基本上我用這些選項從2.087秒到1.48秒。

./configure CFLAGS="-O3 -g -std=gnu99" CXXFLAGS="-O3 -g" FFLAGS="-O2 -g" LDFLAGS="-Bdirect,--hash-stype=both,-Wl,-O1" --enable-R-shlib --without-x --with-cairo --with-libpng --with-jpeglib

更新1

劇本尚未優化。另一組實際上正在研究腳本，並且已經提出使用apply函數的請求，但不知道這是如何解釋時間差異的。

配置文件的頂部看起來像這樣。大多數這些功能稍後將使用應用功能進行優化，但現在它在兩臺機器上都將蘋果標記爲蘋果。

"eval.with.vis"     8.66 100.00  0.12  1.39 
"source"       8.66 100.00  0.00  0.00 
"["        5.38  62.12  0.16  1.85 
"GenerateQCC"      5.30  61.20  0.00  0.00 
"[.data.frame"      5.20  60.05  2.40 27.71 
"ZoneCalculation"     5.12  59.12  0.02  0.23 
"cbind"       3.22  37.18  0.34  3.93 
"[["        2.26  26.10  0.38  4.39 
"[[.data.frame"     1.88  21.71  0.82  9.47

我的第一個懷疑，我將很快測試以及與我的發現更新是KVM Linux虛擬化是難辭其咎的。這個腳本的內存密集程度很高，並且由於大量的數組操作和R被拷貝傳遞（當然這對於malloc來說），這可能會導致問題。由於虛擬機沒有直接訪問內存控制器，並且必須與其他虛擬機共享，所以很可能導致問題。我今天晚些時候會得到一臺原始機器，並會隨着我的發現而更新。

謝謝大家的快速更新。

更新2

我們原先認爲的性能問題的原因是通過與VM超線程造成的，但是這竟然是不正確的，性能是一個裸機在同一比較。

我們後來意識到windows筆記本電腦正在使用32位版本的R進行計算。這使我們嘗試了64位版本的R，結果在相同的腳本上比32位慢了140％。這使我想到64位可能比R的32位版本慢140％的可能性？

我們所看到的是，32

的Windows 32位執行時間48秒的Windows 64位執行時間2.33秒。

Linux 64位執行時間2.15秒。 Linux 32位執行時間<正在進行>（在RHEL 6.3 x86_64上構建了32位版本，但未看到使用32位版本RHEL 6重新加載性能的改進。3）

我發現這個鏈接，但它只解釋了一些64位機器上15-20％的命中。

http://www.hep.by/gnu/r-patched/r-admin/R-admin_51.html

對不起，我不能合法地發佈腳本。

來源

2012-10-02 Chris Hinshaw

您提到了4個核心：Unix作業是否並行化，Windows不是？這可能是開銷太大了嗎？ –

兩臺機器上的腳本都是一樣的。它確實需要進行優化。有相當多的部分在數據框中使用[]偏移，而不是使用apply函數。我已經研究過使用並行庫來加速代碼的這些部分，但除非Windows有某些功能默認啓用並行優化，否則腳本沒有平行部分。筆記本電腦有8個vs 4個內核，但該腳本沒有使用所有內核。感謝您的觀察，但我不認爲這種差異是由於在這種情況下的流程分配。 –

我會考慮將帖子的標題更改爲反映您正在嘗試（並最終從下面的答案中獲得成功）的內容，以便跨平臺**優化R使用**。就目前而言，我可能會把這個問題看作是另一個問題：「如何讓我的R代碼更快地運行[例如，通過向量化，避免重複分配，使用'data.table'等等]？」題。 –

問題已解決，它是由非優化的BLAS庫引起的。

這篇文章是一個很好的幫助。使用ATLAS非常有幫助。

http://www.cybaea.net/Blogs/Data/Faster-R-through-better-BLAS.html

來源

2013-01-05 19:47:32

查看Writing R Extensions手冊中「剖析」部分。

從30,000英尺，你不能說別的 - 你需要分析信息。「普遍共識」（我認爲這是用引號括起來的，因爲你無法真正概括這些東西）是Linux在內存管理和文件訪問方面往往更好，所以我對你的結果有點驚訝。

來源

2012-10-02 14:18:31

我已經添加了配置文件更新的輸出，供您閱讀。您會注意到該腳本尚未優化爲使用應用功能，並且我已要求組織將其更改爲在其大型數據集上使用apply。 –

建築R與--enable-R-shlib可能會導致性能損失。這在R Installation and Administration，Appendix B, Section 1中討論。這可以解釋10-20％的變化。其他來源可能來自「可比規格」的差異。

來源

2012-10-02 14:20:56

我沒有看到超過1％至5％的罰款。你現在是否是BDR代理人要求禁止動態鏈接？ ;-) –

@DirkEddelbuettel：不，我只是在釣魚，因爲OP沒有提供足夠的信息來做更多的猜測。 –

其實不知道爲什麼，但是在添加--enable-R-shlib後，我看到了顯着的性能改進。我禁用了它，時間從1.48增加到了2.14，這比原來的運行還要高。這完全讓我無法防範，但我跑了兩次，以確保兩次運行的時間相同。我都嘗試啓用靜態存檔，希望這也會更快，並且與shlib選項一致。很奇怪 –

如何優化R性能

回答

相關問題