java - 函数式编程的 Number-Crushing 性能(使用 java 8)

Question

我主要在 C/Fotran/numpy 中进行一些数值/物理模拟，我使用 Java(尤其是 Processing 和 jMonkey)只是为了在代码原型(prototype)制作过程中获得一些实时交互。

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

• Lambda 表达式(观看this video)
• 提议支持并行、异构计算(GPGPU、OpenCL)称为 sumatra项目

对我来说，这似乎有点矛盾——函数式编程和数值性能。也许这只是我幼稚的偏见。

典型的论点是这样的:

Functional style declarations make the code easier to paralelize and give compiler greater optimization oppurtinities than strictly sequential loops and mutable data types

好吧，理论上它是有道理的，但在实践中，常见的 Number-Crushing 操作在 haskell、Erlang、Clojure 和 List 等函数式编程语言中似乎比在 C 或 Java 等命令式语言中慢得多。这可能与您为抽象支付大量操作这一事实有关 - 功能结构与机器代码和处理器的工作方式相去甚远。这就是我从未对函数式编程感兴趣的原因。

所以我的问题是:

• 对 Java 8 中的函数式编程有什么期望。如果我感兴趣的领域是性能关键型数字代码，我应该关心并尝试学习吗？
• 使用函数式构造 代替带有循环的普通命令式代码是否会导致性能损失？ (我的意思是在简单的任务中，例如测试素数或计算 dot_product)

Answer 1

1. Java 8 带来了一些漂亮而简洁的语法结构，通用且可靠，但不是很实用并且 not magically fast流式执行/并行化框架。但它没有真正重要的 JIT 编译，内联改进可能对数字压缩代码有用。例如，Java 7 的匿名类比 lambda 丑陋得多，but not slower .
   
   因此，您的问题的答案是:不，如果您对 Java 7 和性能不感兴趣，那么关注的不是编码便利性。

2. 在足够简单的情况下，当代码非常热时，可能更改了 JVM 标志以进行更深层次的内联，理想情况下，没有惩罚。但否则会有一些(虽然不是很大)惩罚。即使 JIT 执行内联，在大多数情况下它也不会完美地折叠机器代码。

Value types proposal promise 在数字压缩方面会更有趣，但很难说它何时会出现在 Java 中(如果有的话)。