lme()不同的结果各自在Revolution R下运行(应归咎于MKL吗?) [英] lme() different results each run under Revolution R (MKL to blame?)

问题描述

更新(2014年8月):我从来没有深入了解这一点，也从未在Revolution的论坛上得到任何反馈.但是，该问题似乎已在Revolution R 7.2(R 3.0.3，又是学术版本)中得到修复.我将lme()测试运行了几百次，都按预期产生了相等的结果.[更新结束]

Update (Aug 2014): I never got to the bottom of this, and never got any feedback on Revolution's forum. This issue, however, seems to have been fixed in Revolution R 7.2 (with R 3.0.3, again the academic version). I ran the lme() test below a few hundred times, all produced equal results, as expected.[end of update]

我刚刚在新PC上安装了Revolution R 7.0(R 3.0.2)的学术版，并且下面的代码得到了奇怪的结果.每次运行代码，它都会给出不同的结果.在CRAN-R下，结果始终是相同的(正如我认为的那样).该代码段来自test.data.table()版本1.8.10的测试527，将我指出了该错误.

I just installed the academic version of Revolution R 7.0 (R 3.0.2) on a new PC and am getting strange results for the code below. Every time the code is run, it gives different results. Under CRAN-R the result is always the same (as I think it should be). The code snippet is from test 527 from test.data.table() version 1.8.10, which pointed me to the error.

library(nlme)
all.equal(lme(distance ~ age, data=Orthodont), lme(distance ~ age, data=Orthodont))

我得到类似下面的内容，但是每次都不同.

I get something like below, but different every time.

> all.equal(lme(distance ~ age, data=Orthodont), lme(distance ~ age, data=Orthodont))
[1] "Component 4: Component 2: Component 1: Mean relative difference: 1.774149e-08"
[2] "Component 7: Mean relative difference: 0.0003335902"

有趣"的事情是，nlme程序包(其中是lme()的一部分)本身是相同的，我已卸载并重新安装以确保(该程序包的nlme_3.1-113.zip文件已被删除) -for-bit相同).

The 'fun' thing is that the nlme package (of which lme() is part) itself is identical, I uninstalled and reinstalled to be sure (the nlme_3.1-113.zip file of the package is bit-for-bit identical).

我还不了解.任何指针或想法，将不胜感激.我也曾在Revolutions的论坛上发帖，但这里的人口似乎比这里少得多...

I do not know enough yet to go under the hood. Any pointers or ideas would be appreciated. I have also posted on Revolutions's forum but it seems much less populated than here...

如果要安装在64位Windows 8.1、64位R和Intel i7-4770 CPU之下.当前版本的Revolution R(R 3.0.2)和之前的版本(2.15.3)都会产生意外的行为(对我而言). CRAN-R 3.0.1和3.0.2产生相同的结果.

This is under 64-bit Windows 8.1, 64-bit R as well, Intel i7-4770 CPU if it matters. Both the current version of Revolution R (R 3.0.2) and the previous (2.15.3) produce the unexpected (for me) behavior. CRAN-R 3.0.1 and 3.0.2 produce identical results.

Revolution R的sessionInfo()输出:

sessionInfo() output for Revolution R:

> sessionInfo()
R version 3.0.2 (2013-09-25)
Platform: x86_64-w64-mingw32/x64 (64-bit)

locale:
[1] LC_COLLATE=English_United States.1252 
[2] LC_CTYPE=English_United States.1252   
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C                          
[5] LC_TIME=English_United States.1252    

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
[1] nlme_3.1-113     Revobase_7.0.0   RevoMods_7.0.0   RevoScaleR_7.0.0
[5] lattice_0.20-24  rpart_4.1-3     

loaded via a namespace (and not attached):
[1] codetools_0.2-8   foreach_1.4.1     grid_3.0.2        iterators_1.0.6  
[5] pkgXMLBuilder_1.0 revoIpe_1.0       tools_3.0.2       XML_3.98-1.1   

更新1: 我已经追查了这个问题(遵循下面的答案和评论中的一些指针)到Revolution R使用英特尔MKL BLAS库这一事实.如果我切换到CRAN提供的BLAS库，问题就消失了. (注意:我自己编译R的知识还不够，因此我还没有测试过OpenBLAS和其他替代产品.在Revolution R中，只需重命名两个dll-s.).

UPDATE 1: I have traced the issue (following some of the pointers from the answer & comments below) to the fact that Revolution R uses the Intel MKL BLAS library. If I switch to the BLAS library supplied by CRAN, the issues go away. (Note: I do not know enough to compile R myself, so I have not tested OpenBLAS and the other alternatives. In Revolution R it is just a matter of renaming two dll-s.).

似乎其他人得到了与MKL不一致的结果好.机器收费之间存在差异，即all.equal()为TRUE，而identical()为FALSE.在我的情况下，不同的结果似乎非常有意义.

It would seem that other people are getting inconsistent results with MKL as well. The differences there are within machine tollerance, i.e. all.equal() is TRUE while identical() is FALSE. The different results in my case seem to be meaningfully large.

我已经在Revolution R的论坛上发布了此问题，如果得到回应，将在这里进行更新.我想在这一点上，我的问题应修改为何时使用MKL BLAS，何时使用CRAN-R BLAS".这不是速度(*)的问题，而是一致和正确结果的问题.我将花更多时间寻找标准测试套件(此处不确定术语吗?)，以将R的输出与已知正确的输出进行比较.这是我喜欢data.table的事情之一，它具有自己的测试对最终用户可见.我知道我不应该期望包含所有(或什至大多数)软件包的单一测试，而是至少涵盖基本功能的东西.

I have posted this issue on Revolution R's forum and will update here if I get a response. I suppose at this point my question should be modified as "when to use MKL BLAS and when CRAN-R BLAS". It is not an issue of speed(*) but of consistent and correct results. I will spend some more time looking for a standard test suite (not sure of the terminology here?) to check the output of R against known-to-be-correct output. This is one of the things I love about data.table, it has its own test visible to the end-user. I am aware than I should not expect a single test encompassing all (or even most) packages, but something covering the base functionality at least.

(*)速度取决于具体的工作流程.在这种特殊情况下，CRAN BLAS比MKL(都运行单线程)要快.在其他工作中，Revolution R的速度要快得多，这就是我要研究它的原因.

(*) Speed is dependent on the concrete workflow. In this particular case the CRAN BLAS is faster than MKL (both run single-threaded). In other work, Revolution R has been substantially faster, that's why I am looking into it.

推荐答案

在一个猜测中，Revo R正在通过CPU内核对其进行并行化，并且重组并行事物的算法并不总是关联的.换句话说，它取决于操作顺序.如果线程以不同的顺序完成(如果核心必须做其他事情，则可能发生)，那么结果将以不同的顺序累加，并且(a + b)+ c并不总是等于浮动中的a +(b + c)点...

At a guess, Revo R is parallelising it over CPU cores and the arithmetic in recombining parallel things isn't always associative. In other words, it depends on the order of operations. If the threads finish in different orders, which can happen if the cores have to do something else, then results get added up in a different order and (a+b)+c is not always equal to a+(b+c) in floating point...

要检查一下，有什么方法可以告诉Revo R仅使用一个CPU内核?

To check, is there some way you can tell Revo R to only use one CPU core?

这篇关于lme()不同的结果各自在Revolution R下运行(应归咎于MKL吗?)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！