Oracle 声称其对 R 的 graalvm 实现（称为“FastR”）比普通 R （https://www.graalvm.org/r/）快 40 倍。然而，我运行了这个超级简单（但很现实）的 4 行测试程序，GraalVM/FastR 不仅没有快 40 倍，实际上还慢了 10 倍！
x <- 1:300000/300000
mu <- exp(-400*(x-0.6)^2)+
5*exp(-500*(x-0.75)^2)/3+2*exp(-500*(x-0.9)^2)
y <- mu+0.5*rnorm(300000)
t1 <- system.time(fit1 <- smooth.spline(x,y,spar=0.6))
t1
在 FASTR 中，t1 返回此值：
user system elapsed
0.870 0.012 0.901
在原来的正常 R 中，我得到了这个结果：
user system elapsed
0.112 0.000 0.113
如您所见，即使对于这个简单的（即 4 行代码，没有额外/特殊库导入等） ，FAST R 也非常慢。我在 Google Cloud 上的 16 核 VM 上对此进行了测试。想法？（仅供参考：我快速浏览了 smooth.spline 代码，它确实调用了 Fortran，但根据 Oracle 营销网站，GraalVM/FastR 甚至比 Fortran-R 代码还要快。）
=====================================
编辑：根据下面 Ben Bolker 和 user438383 的评论，我修改了代码以包含一个 for 循环，以便代码运行更长时间，并且我有时间监控 CPU 使用情况。修改后的代码如下：
x <- 1:300000/300000
mu <- exp(-400*(x-0.6)^2)+
5*exp(-500*(x-0.75)^2)/3+2*exp(-500*(x-0.9)^2)
y <- mu+0.5*rnorm(300000)
forloopfunction <- function(xTrain, yTrain) {
for (x in 1:100) {
smooth.spline(xTrain, yTrain, spar=0.6)
}
}
t1 <- system.time(fit1 <-forloopfunction(x,y))
t1
现在，正常的 R 为 t1 返回这个：
user system elapsed
19.665 0.008 19.667
而 FastR 返回：
user system elapsed
76.570 0.210 77.918
所以，现在，FastR 只慢了 4 倍，但这仍然相当慢。（我可以接受 5% 甚至 10% 的差异，但这是 400% 的差异。）此外，我检查了 cpu 的使用情况。正常 R 在整个 19 秒内仅使用 1 个内核（100%）。然而，令人惊讶的是，FastR 在大约 78 秒内使用了 100% 到 300% 的 CPU 使用率（即 1 个全核和 3 个全核）。因此，我认为可以相当合理地得出结论，至少对于这个测试（这恰好是我非常简单的场景的实际测试），FastR 至少慢 4 倍，同时消耗约 1 到 3 倍的 CPU 内核。特别是考虑到我没有导入任何 FASTR 团队可能没有时间正确分析的特殊库（即我只使用 R 附带的 vanilla R 代码），我认为有 至少在速度方面，FASTR 实现并不完全正确。（我还没有测试过准确性，但我认为这现在没有实际意义。）有没有其他人经历过类似的事情，或者是否有人知道需要对 FASTR 进行任何“神奇”配置才能获得其声称的速度（或至少类似，即 +- 5% 速度到正常 R)？（或者也许我可以解决一些已知的 FASTR 限制，即不使用普通的 fortran 二进制文件等，但使用这些特殊的等）即 +- 5% 速度到正常 R)？（或者也许我可以解决一些已知的 FASTR 限制，即不使用普通的 fortran 二进制文件等，但使用这些特殊的等）即 +- 5% 速度到正常 R)？（或者也许我可以解决一些已知的 FASTR 限制，即不使用普通的 fortran 二进制文件等，但使用这些特殊的等）