Question

使用scalacl plugin是否有任何缺点？

我打算在我的项目中使用scala。我在scala中编写了一些代码来查看它的执行时间。

(1 to 1000000).map(1 + _).sum

1。没有插件

编译成这样的东西：

BoxesRunTime.unboxToInt(((TraversableOnce)Predef..MODULE$.intWrapper(1).to(1000000).map(new MyScala..anonfun.1(), IndexedSeq..MODULE$.canBuildFrom())).sum(Numeric.IntIsIntegral..MODULE$));

并在大约375毫秒内运行

2。使用scalacl插件

 int i = 1;
 int j = 1000000;
 int k = j;
 int m = i;
 for (VectorBuilder localVectorBuilder = new VectorBuilder(); m <= k;) {
     int n = m;
     localVectorBuilder.$plus$eq(BoxesRunTime.boxToInteger(1 + n));
     m += 1;
 }
 int a =  BoxesRunTime.unboxToInt(localVectorBuilder.result().sum(Numeric.IntIsIntegral..MODULE$));

259 ms

Answer 1

我能想到的可能缺点：

1）循环优化似乎很有效，开发人员似乎非常称职，但是在“关于ScalaCL”屏幕中用粗体字母表示“ ScalaCL还没有生产就绪！”。换句话说，你可能会引入错误和不稳定的可能性很小

2）你需要记住每次使用插件编译，否则你可能会突然发现你有性能问题。您无法确定插件是否会在中期或长期维护/兼容

3）您可能会依赖其优化，导致您编写低效的代码，而识别和手动优化瓶颈可能会导致整体代码更快。换句话说，它实际上可以“纸上裂缝”

4）这是一个额外的库依赖项，增加了构建文件的复杂性

你问了缺点，但与专业人士相比，这些都很小。就个人而言，我毫不犹豫地将循环优化用于个人项目;还不太确定cl-collections（我试过它们，发现我的GPU比我的CPU慢一点 - 显然它取决于可用的硬件），但我认为该项目有一个美好的未来，无论是单独的还是并入标准的编译器和库。对于某些代码，我已经看到了一些非常引人注目的加速（最多快20倍）。

具有数组性能的Scala操作（scalacl插件）

1 个答案: