java怎么修改加速_Duff的设备能加速Java代码吗？

使用库存Sun 1.6编译器和JRE / JIT，使用Duff的设备示例的大量展开来展开循环是一个好主意吗？ 或者它最终是代码混淆，没有性能优势？

我使用的Java分析工具对于逐行CPU使用的信息比valgrind少，所以我希望通过其他人的经验来增加测量。

请注意，当然，你不能完全编写Duff的设备，但你可以做基本的展开，这就是我想知道的。

short stateType = data.getShort(ptr);

switch (stateType) {

case SEARCH_TYPE_DISPATCH + 16:

if (c > data.getChar(ptr + (3 << 16) - 4)) {

ptr += 3 << 16;

}

case SEARCH_TYPE_DISPATCH + 15:

if (c > data.getChar(ptr + (3 << 15) - 4)) {

ptr += 3 << 15;

}

...

通过许多其他价值观。

我不明白你修改过的问题。 达夫的装置并不仅仅意味着堕落。 隔行循环是关键部分。

你为什么不......测试一下？ 像往常一样用循环编写一个版本。 使用展开的循环编写版本。 编写一个框架，每次执行一百万次(或其他)。 了解优化尝试带来的性能提升(如果有)。

没有最佳答案???O.o

它是否是一个好主意(它不是)并不重要，因为它不会编译。

编辑：这在JLS中明确提到：

A trick known as Duff's device can be used in C or C++ to unroll the loop, but this is not valid code in the Java programming language:

或者，更直接地(来自同一部分)：

Great C hack, Tom, but it's not valid here.

编辑：回答你的更多(太)一般性问题，通常没有。 您通常应该依赖JIT。

对不起，我没有提出非常不明确的问题。

您忽略了Java为面向堆栈的虚拟机编译为字节码的事实。 无论您在Java级别尝试什么样的低级优化技巧，都基本上无效。 当JIT编译器为目标体系结构生成程序集时，就会发生真正的优化，这个程序在大多数情况下都无法控制或关注。

你应该在更大的图片上进行优化。 让JIT编译器处理低级优化。

+1"看大图"

我不是在忽视它，我问你这件事。