r - lme() 在 Revolution R 下运行的结果各不相同(应该归咎于 MKL？)

Question

更新(2014 年 8 月):我从来没有深入了解过这个问题，也从未在 Revolution 的论坛上得到任何反馈。然而，这个问题似乎已在 Revolution R 7.2(R 3.0.3，同样是学术版)中得到解决。我运行了数百次 lme() 测试，结果都与预期的一样。[ 更新结束 ]

我刚刚在一台新 PC 上安装了 Revolution R 7.0 (R 3.0.2) 的学术版本，但下面的代码得到了奇怪的结果。每次运行代码时，都会给出不同的结果。在 CRAN-R 下，结果总是相同的(我认为应该如此)。代码片段来自 test.data.table() 的测试 527版本 1.8.10，它指出了错误。

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

我得到类似下面的东西，但每次都不同。

> 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 文件是完全相同的)。

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

这适用于 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 产生相同的结果。

革命 R 的 sessionInfo() 输出:

> 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 的问题。)。

似乎其他人正在获取 inconsistent results with MKL as well .机器公差内的差异，即 all.equal()是 TRUE 而 identical()是假的。在我的案例中，不同的结果似乎意义重大。

我已经在 Revolution R 的论坛上发布了这个问题，如果我得到回复，我会在这里更新。我想此时我的问题应该修改为“何时使用 MKL BLAS 以及何时使用 CRAN-R BLAS”。这不是速度(*)的问题，而是一致和正确的结果。我将花更多时间寻找标准测试套件(不确定此处的术语？)以根据已知正确的输出检查 R 的输出。这是我喜欢的事情之一 data.table ，它有自己的测试对最终用户可见。我知道我不应该期望包含所有(甚至大多数)包的单个测试，而是至少涵盖基本功能的测试。

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

Answer 1

据猜测，Revo R 是在 CPU 内核上对其进行并行化，并且重新组合并行事物的算法并不总是具有关联性。换句话说，它取决于操作的顺序。如果线程以不同的顺序完成，如果内核必须做其他事情就会发生这种情况，那么结果就会以不同的顺序相加，并且 (a+b)+c 并不总是等于 a+(b+c) float 观点...

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