我们最近有一个性能基准,我试图理解。我们有一个大型脚本,在Redhat Linux机器上的性能比在规格相当的Windows 7笔记本电脑上慢50%。 linux机器使用kvm进行虚拟化,并分配了4个内核和16GB内存。该脚本不是密集型的,但有很多for循环。主要是我想知道是否有任何可用于优化的R编译选项或任何可能有助于使其更具可比性的内核编译器选项。任何指针将不胜感激。我将尝试使用另一台机器并使用原始金属进行测试,以便更好地进行比较。
这些是我用来在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),这可能会导致问题。由于VM无法直接访问内存控制器,并且必须与其他VM共享,因此很可能会导致问题。我将在今天晚些时候获得一台原始机器,并将根据我的发现进行更新。
感谢大家的快速更新。
更新2
我们原本以为性能问题的原因是由VM的超线程引起的,但事实证明这是不正确的,并且在裸机上的性能相当。
我们后来意识到Windows笔记本电脑正在使用32位版本的R进行计算。这导致我们尝试64位版本的R,结果比同一个完全相同的脚本上的32位慢约140%。这让我想到64位可能比32位版本的R慢~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
抱歉,我不能合法地发布脚本。
答案 0 :(得分:1)
查看关于"剖析"的部分。在Writing R Extensions手册中。
从30,000英尺起,您无法说出其他许多内容 - 您将需要分析信息。 "普遍共识" (我把它放在引号中,因为你可以真正概括这些事情)是Linux在内存管理和文件访问方面做得更好,所以我对你的结果感到有些惊讶。
答案 1 :(得分:1)
使用--enable-R-shlib
构建R会导致性能下降。 R Installation and Administration中Appendix B, Section 1讨论了这一点。仅这一点就可以解释10-20%的变化。其他来源可能来自“可比规格”的差异。
答案 2 :(得分:1)
问题已解决,它是由未优化的BLAS库引起的。
这篇文章很有帮助。使用ATLAS是一个很好的帮助。
http://www.cybaea.net/Blogs/Data/Faster-R-through-better-BLAS.html