JDK8 LocalDate.toEpochDay的性能下降奇怪

Question

如果我们最终得到一个带JDK8的快速日期时间库,我很好奇.几乎所有的LocalDate计算都使用,toEpochDay所以我查看了源代码,如果我能做得更好,大量的分支和分支让我很好奇.

我消除了一些分支和除了一个分区以外的所有分支,但是加速比预期更差.所以我的第一个问题是如何使用多次除法的算法只需要大约30个周期(吞吐量).霍尔格的评论似乎回答了这个问题:一个小常数的除法得到了乘法的JIT.我是手动完成的,现在我一直在以原来的实施方式击败原因2.

该基准是非常简单的,只是想迭代虽然随机数组LocalDateS和转换他们每个人toEpochDay.尽管具有随机性,但结果非常一致.数组的大小是一个参数,我的主要问题是2000到30000之间的大幅减速来自何处.应该有一些减速因为数据不再适合L1缓存,但两种算法的内存访问完全相同(即,只date从数组中获取).

仍然存在的问题是:如何在迭代数组时,同一函数的两个简单的无内存访问实现的行为会发生变化？原始算法的速度比我的慢得多.

我的算法在这里可能不值得复制,它没有文档记录,与原版一样神秘,而且只有一个非常基本的测试.

Answer 1

那是因为算法中没有划分。所有 / 4 都被轮班替换。所有 / 100 实际上都是 * 0.01。这些划分是为了便于阅读（呵呵）。我不确定这种优化是否发生在字节码发射或 JIT 编译期间，查看类文件并找出答案会很有趣。