函数编程的数字粉碎性能(用java 8)

Question

我在C/Fotran/numpy中做了一些数值/物理模拟，我使用Java (特别是正在处理中和jMonkey )来实现代码原型过程中的实时交互。

最近，我读到了Java 8的新特性，即：

• Lambda表达式(观看这段视频 )
• 提出的支持并行性、异构计算( GPGPU、OpenCL )的称为苏门答腊项目。

在我看来，这似乎有点矛盾-功能编程和数字性能。也许只是我天真的偏见。

典型的论点是：

函数样式声明使代码比严格的顺序循环和可变数据类型更易于并行化，并使编译器具有更大的优化透明性。

好的，从理论上讲，这是有意义的，但在实践中，在诸如haskell、Erlang、Clojure和List这样的函数编程语言中，常见的破坏数字的操作似乎要比C或Java等命令式语言慢得多。这可能与您为抽象付出大量操作的事实有关--函数构造与机器代码和处理器的工作方式相差太远。这就是为什么我对函数式编程从来不感兴趣。

所以我的问题是：

• Java 8中的函数式编程有什么可期待的?我是否应该关心并尝试学习我感兴趣的领域是否是性能关键的数字代码？
• 是否存在使用函数结构而不是循环的普通命令式代码的性能损失？(我指的是简单的任务，如质数测试或计算dot_product )

Answer 1

1. Java 8提供了一些简洁的语法结构，通用和可靠，但功能不强，不是魔法般的快流执行/并行化框架。但是它并没有真正意义上的JIT编译，而是内联的改进，而这些改进对于大量的代码来说是有用的。例如，Java7的匿名类比lambdas ( 但不是慢一点 )丑陋得多。

因此，对您的问题的回答是:不，如果您对Java 7和性能不感兴趣，那么编写代码的便利性就是考虑的问题。

1. 在非常简单的情况下，当代码非常热时，可能会更改JVM标志以进行更深层次的内联，理想情况下，这是没有损失的。但除此之外，还有一些(虽然不是很大的)处罚。即使JIT确实执行内联，在大多数情况下，它也不会完美地折叠机器代码。

价值类型建议可能会更有趣，但很难说它什么时候会在Java中出现(如果有的话)。

Answer 2

我已经发现，新的功能特性不是最优化的做事方法，而是一种让老化的Java语言更有生命力的方法。实际上，我试图在我的工作环境中避免使用函数语法，直到代码质量工具等通常能够解析它。

使用功能特性很好，但是为什么不选择一种一开始就有功能的语言，比如Scala。或者至少比Java更现代一些，比如Ruby。

当然，新的语法很好，但是仍然感觉像是在XML文件中编写yaml。它本身看起来很好，但也有点可笑，当它周围的一切都是旧的风格。