Java 8u40 Math.round() 很慢
Java 8u40 Math.round() very slow
我有一个用 Java 8 编写的相当简单的爱好项目，它在其中一种操作模式中广泛使用重复的 Math.round() 调用。例如，一种这样的模式通过 ExecutorService 产生 4 个线程并排队 48 个 运行 可用任务，每个 运行 类似于以下代码块 2^31 次：
int3 = Math.round(float1 + float2);
int3 = Math.round(float1 * float2);
int3 = Math.round(float1 / float2);
事实并非如此（涉及数组和嵌套循环），但您明白了。无论如何，在 Java 8u40 之前，类似于上述的代码可以在 AMD A10-7700k 上在大约 13 秒内完成约 1030 亿个指令块的完整 运行。使用 Java 8u40 执行相同的操作大约需要 260 秒。没有更改代码，什么都没有，只是 Java 更新。
有没有其他人注意到 Math.round() 变得越来越慢，尤其是当它被重复使用时？就好像 JVM 在它不再做之前进行了某种优化。也许它在 8u40 之前使用 SIMD 而不是现在？
编辑： 我已经完成了对 MVCE 的第二次尝试。您可以在这里下载第一次尝试：
https://www.dropbox.com/s/rm2ftcv8y6ye1bi/MathRoundMVCE.zip?dl=0
第二次尝试如下。我的第一次尝试已从 post 中删除，因为它被认为太长，并且很容易被 JVM 删除死代码优化（这显然在 8u40 中发生得更少）。
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
public class MathRoundMVCE
{
static long grandtotal = 0;
static long sumtotal = 0;
static float[] float4 = new float[128];
static float[] float5 = new float[128];
static int[] int6 = new int[128];
static int[] int7 = new int[128];
static int[] int8 = new int[128];
static long[] longarray = new long[480];
final static int mil = 1000000;
public static void main(String[] args)
{
initmainarrays();
OmniCode omni = new OmniCode();
grandtotal = omni.runloops() / mil;
System.out.println("Total sum of operations is " + sumtotal);
System.out.println("Total execution time is " + grandtotal + " milliseconds");
}
public static long siftarray(long[] larray)
{
long topnum = 0;
long tempnum = 0;
for (short i = 0; i < larray.length; i++)
{
tempnum = larray[i];
if (tempnum > 0)
{
topnum += tempnum;
}
}
topnum = topnum / Runtime.getRuntime().availableProcessors();
return topnum;
}
public static void initmainarrays()
{
int k = 0;
do
{
float4[k] = (float)(Math.random() * 12) + 1f;
float5[k] = (float)(Math.random() * 12) + 1f;
int6[k] = 0;
k++;
}
while (k < 128);
}
}
class OmniCode extends Thread
{
volatile long totaltime = 0;
final int standard = 16777216;
final int warmup = 200000;
byte threads = 0;
public long runloops()
{
this.setPriority(MIN_PRIORITY);
threads = (byte)Runtime.getRuntime().availableProcessors();
ExecutorService executor = Executors.newFixedThreadPool(threads);
for (short j = 0; j < 48; j++)
{
executor.execute(new RoundFloatToIntAlternate(warmup, (byte)j));
}
executor.shutdown();
while (!executor.isTerminated())
{
try
{
Thread.sleep(100);
}
catch (InterruptedException e)
{
//Do nothing
}
}
executor = Executors.newFixedThreadPool(threads);
for (short j = 0; j < 48; j++)
{
executor.execute(new RoundFloatToIntAlternate(standard, (byte)j));
}
executor.shutdown();
while (!executor.isTerminated())
{
try
{
Thread.sleep(100);
}
catch (InterruptedException e)
{
//Do nothing
}
}
totaltime = MathRoundMVCE.siftarray(MathRoundMVCE.longarray);
executor = null;
Runtime.getRuntime().gc();
return totaltime;
}
}
class RoundFloatToIntAlternate extends Thread
{
int i = 0;
int j = 0;
int int3 = 0;
int iterations = 0;
byte thread = 0;
public RoundFloatToIntAlternate(int cycles, byte threadnumber)
{
iterations = cycles;
thread = threadnumber;
}
public void run()
{
this.setPriority(9);
MathRoundMVCE.longarray[this.thread] = 0;
mainloop();
blankloop();
}
public void blankloop()
{
j = 0;
long timer = 0;
long totaltimer = 0;
do
{
timer = System.nanoTime();
i = 0;
do
{
i++;
}
while (i < 128);
totaltimer += System.nanoTime() - timer;
j++;
}
while (j < iterations);
MathRoundMVCE.longarray[this.thread] -= totaltimer;
}
public void mainloop()
{
j = 0;
long timer = 0;
long totaltimer = 0;
long localsum = 0;
int[] int6 = new int[128];
int[] int7 = new int[128];
int[] int8 = new int[128];
do
{
timer = System.nanoTime();
i = 0;
do
{
int6[i] = Math.round(MathRoundMVCE.float4[i] + MathRoundMVCE.float5[i]);
int7[i] = Math.round(MathRoundMVCE.float4[i] * MathRoundMVCE.float5[i]);
int8[i] = Math.round(MathRoundMVCE.float4[i] / MathRoundMVCE.float5[i]);
i++;
}
while (i < 128);
totaltimer += System.nanoTime() - timer;
for(short z = 0; z < 128; z++)
{
localsum += int6[z] + int7[z] + int8[z];
}
j++;
}
while (j < iterations);
MathRoundMVCE.longarray[this.thread] += totaltimer;
MathRoundMVCE.sumtotal = localsum;
}
}
长话短说，此代码在 8u25 中的性能与在 8u40 中的性能大致相同。如您所见，我现在将所有计算的结果记录到数组中，然后将循环的定时部分之外的这些数组求和到一个局部变量，然后在外部循环结束时将其写入静态变量。
8u25以下：总执行时间为261545毫秒
8u40以下：总执行时间为266890毫秒
测试条件同上。因此，看起来 8u25 和 8u31 正在执行 8u40 停止执行的死代码删除，导致代码在 8u40 中变为 "slow down"。这并不能解释每一个突然出现的奇怪的小东西，但这似乎是其中的大部分。作为额外的奖励，这里提供的建议和答案给了我灵感来改进我的爱好项目的其他部分，对此我非常感激。谢谢大家！
基于OP的MVCE
- 可能会进一步简化
- 将
int3 = 语句更改为 int3 += 以减少删除死代码的机会。 int3 = 从 8u31 到 8u40 的差异是慢 3 倍。使用 int3 += 差异仅慢 15%。
- 打印结果以进一步减少死代码删除优化的可能性
代码
public class MathTime {
static float[][] float1 = new float[8][16];
static float[][] float2 = new float[8][16];
public static void main(String[] args) {
for (int j = 0; j < 8; j++) {
for (int k = 0; k < 16; k++) {
float1[j][k] = (float) (j + k);
float2[j][k] = (float) (j + k);
}
}
new Test().run();
}
private static class Test {
int int3;
public void run() {
for (String test : new String[] { "warmup", "real" }) {
long t0 = System.nanoTime();
for (int count = 0; count < 1e7; count++) {
int i = count % 8;
int3 += Math.round(float1[i][0] + float2[i][0]);
int3 += Math.round(float1[i][1] + float2[i][1]);
int3 += Math.round(float1[i][2] + float2[i][2]);
int3 += Math.round(float1[i][3] + float2[i][3]);
int3 += Math.round(float1[i][4] + float2[i][4]);
int3 += Math.round(float1[i][5] + float2[i][5]);
int3 += Math.round(float1[i][6] + float2[i][6]);
int3 += Math.round(float1[i][7] + float2[i][7]);
int3 += Math.round(float1[i][8] + float2[i][8]);
int3 += Math.round(float1[i][9] + float2[i][9]);
int3 += Math.round(float1[i][10] + float2[i][10]);
int3 += Math.round(float1[i][11] + float2[i][11]);
int3 += Math.round(float1[i][12] + float2[i][12]);
int3 += Math.round(float1[i][13] + float2[i][13]);
int3 += Math.round(float1[i][14] + float2[i][14]);
int3 += Math.round(float1[i][15] + float2[i][15]);
int3 += Math.round(float1[i][0] * float2[i][0]);
int3 += Math.round(float1[i][1] * float2[i][1]);
int3 += Math.round(float1[i][2] * float2[i][2]);
int3 += Math.round(float1[i][3] * float2[i][3]);
int3 += Math.round(float1[i][4] * float2[i][4]);
int3 += Math.round(float1[i][5] * float2[i][5]);
int3 += Math.round(float1[i][6] * float2[i][6]);
int3 += Math.round(float1[i][7] * float2[i][7]);
int3 += Math.round(float1[i][8] * float2[i][8]);
int3 += Math.round(float1[i][9] * float2[i][9]);
int3 += Math.round(float1[i][10] * float2[i][10]);
int3 += Math.round(float1[i][11] * float2[i][11]);
int3 += Math.round(float1[i][12] * float2[i][12]);
int3 += Math.round(float1[i][13] * float2[i][13]);
int3 += Math.round(float1[i][14] * float2[i][14]);
int3 += Math.round(float1[i][15] * float2[i][15]);
int3 += Math.round(float1[i][0] / float2[i][0]);
int3 += Math.round(float1[i][1] / float2[i][1]);
int3 += Math.round(float1[i][2] / float2[i][2]);
int3 += Math.round(float1[i][3] / float2[i][3]);
int3 += Math.round(float1[i][4] / float2[i][4]);
int3 += Math.round(float1[i][5] / float2[i][5]);
int3 += Math.round(float1[i][6] / float2[i][6]);
int3 += Math.round(float1[i][7] / float2[i][7]);
int3 += Math.round(float1[i][8] / float2[i][8]);
int3 += Math.round(float1[i][9] / float2[i][9]);
int3 += Math.round(float1[i][10] / float2[i][10]);
int3 += Math.round(float1[i][11] / float2[i][11]);
int3 += Math.round(float1[i][12] / float2[i][12]);
int3 += Math.round(float1[i][13] / float2[i][13]);
int3 += Math.round(float1[i][14] / float2[i][14]);
int3 += Math.round(float1[i][15] / float2[i][15]);
}
long t1 = System.nanoTime();
System.out.println(int3);
System.out.println(String.format("%s, Math.round(float), %s, %.1f ms", System.getProperty("java.version"), test, (t1 - t0) / 1e6));
}
}
}
}
结果
adam@brimstone:~$ ./jdk1.8.0_40/bin/javac MathTime.java;./jdk1.8.0_40/bin/java -cp . MathTime
1.8.0_40, Math.round(float), warmup, 6846.4 ms
1.8.0_40, Math.round(float), real, 6058.6 ms
adam@brimstone:~$ ./jdk1.8.0_31/bin/javac MathTime.java;./jdk1.8.0_31/bin/java -cp . MathTime
1.8.0_31, Math.round(float), warmup, 5717.9 ms
1.8.0_31, Math.round(float), real, 5282.7 ms
adam@brimstone:~$ ./jdk1.8.0_25/bin/javac MathTime.java;./jdk1.8.0_25/bin/java -cp . MathTime
1.8.0_25, Math.round(float), warmup, 5702.4 ms
1.8.0_25, Math.round(float), real, 5262.2 ms
观察
- 对于 Math.round(float) 的简单使用，我发现在我的平台上没有性能差异 (Linux x86_64)。只有基准有所不同，正如 Ivan 的回答和 Marco13 的评论所指出的那样，我以前的幼稚和不正确的基准只暴露了优化行为的差异。
- 8u40 在消除死代码方面不如以前的版本积极，这意味着在某些极端情况下会执行更多代码，因此速度较慢。
- 8u40 预热时间稍长，但一旦 "there"，速度会更快。
来源分析
令人惊讶的是 Math.round(float) 是一个纯粹的 Java 实现而不是原生的，8u31 和 8u40 的代码是相同的。
diff jdk1.8.0_31/src/java/lang/Math.java jdk1.8.0_40/src/java/lang/Math.java
-no differences-
public static int round(float a) {
int intBits = Float.floatToRawIntBits(a);
int biasedExp = (intBits & FloatConsts.EXP_BIT_MASK)
>> (FloatConsts.SIGNIFICAND_WIDTH - 1);
int shift = (FloatConsts.SIGNIFICAND_WIDTH - 2
+ FloatConsts.EXP_BIAS) - biasedExp;
if ((shift & -32) == 0) { // shift >= 0 && shift < 32
// a is a finite number such that pow(2,-32) <= ulp(a) < 1
int r = ((intBits & FloatConsts.SIGNIF_BIT_MASK)
| (FloatConsts.SIGNIF_BIT_MASK + 1));
if (intBits < 0) {
r = -r;
}
// In the comments below each Java expression evaluates to the value
// the corresponding mathematical expression:
// (r) evaluates to a / ulp(a)
// (r >> shift) evaluates to floor(a * 2)
// ((r >> shift) + 1) evaluates to floor((a + 1/2) * 2)
// (((r >> shift) + 1) >> 1) evaluates to floor(a + 1/2)
return ((r >> shift) + 1) >> 1;
} else {
// a is either
// - a finite number with abs(a) < exp(2,FloatConsts.SIGNIFICAND_WIDTH-32) < 1/2
// - a finite number with ulp(a) >= 1 and hence a is a mathematical integer
// - an infinity or NaN
return (int) a;
}
}
Casual benchmarking: you benchmark A, but actually measure B, and
conclude you've measured C.
现代 JVM 过于复杂，并且进行了各种优化。如果您尝试测量一小段代码，如果不非常非常详细地了解 JVM 正在做什么，要正确地完成它真的很复杂。
许多基准测试的罪魁祸首是死代码消除：编译器足够聪明，可以推断出一些计算是多余的，并完全消除它们。请阅读以下幻灯片 http://shipilev.net/talks/jvmls-July2014-benchmarking.pdf。为了 "fix" Adam 的微基准测试（我仍然不明白它在测量什么，而且这个 "fix" 没有考虑预热、OSR 和许多其他微基准测试陷阱）我们必须打印结果系统输出的计算：
int result = 0;
long t0 = System.currentTimeMillis();
for (int i = 0; i < 1e9; i++) {
result += Math.round((float) i / (float) (i + 1));
}
long t1 = System.currentTimeMillis();
System.out.println("result = " + result);
System.out.println(String.format("%s, Math.round(float), %.1f ms", System.getProperty("java.version"), (t1 - t0)/1f));
结果：
result = 999999999
1.8.0_25, Math.round(float), 5251.0 ms
result = 999999999
1.8.0_40, Math.round(float), 3903.0 ms
与原始 MVCE 示例相同 "fix"
It took 401772 milliseconds to complete edu.jvm.runtime.RoundFloatToInt. <==== 1.8.0_40
It took 410767 milliseconds to complete edu.jvm.runtime.RoundFloatToInt. <==== 1.8.0_25
如果你想衡量 Math#round 的实际成本，你应该这样写（基于 jmh）
package org.openjdk.jmh.samples;
import org.openjdk.jmh.annotations.*;
import org.openjdk.jmh.runner.Runner;
import org.openjdk.jmh.runner.RunnerException;
import org.openjdk.jmh.runner.options.Options;
import org.openjdk.jmh.runner.options.OptionsBuilder;
import org.openjdk.jmh.runner.options.VerboseMode;
import java.util.Random;
import java.util.concurrent.TimeUnit;
@State(Scope.Benchmark)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@Warmup(iterations = 3, time = 5, timeUnit = TimeUnit.SECONDS)
@Measurement(iterations = 3, time = 5, timeUnit = TimeUnit.SECONDS)
public class RoundBench {
float[] floats;
int i;
@Setup
public void initI() {
Random random = new Random(0xDEAD_BEEF);
floats = new float[8096];
for (int i = 0; i < floats.length; i++) {
floats[i] = random.nextFloat();
}
}
@Benchmark
public float baseline() {
i++;
i = i & 0xFFFFFF00;
return floats[i];
}
@Benchmark
public int round() {
i++;
i = i & 0xFFFFFF00;
return Math.round(floats[i]);
}
public static void main(String[] args) throws RunnerException {
Options options = new OptionsBuilder()
.include(RoundBench.class.getName())
.build();
new Runner(options).run();
}
}
我的结果是：
1.8.0_25
Benchmark Mode Cnt Score Error Units
RoundBench.baseline avgt 6 2.565 ± 0.028 ns/op
RoundBench.round avgt 6 4.459 ± 0.065 ns/op
1.8.0_40
Benchmark Mode Cnt Score Error Units
RoundBench.baseline avgt 6 2.589 ± 0.045 ns/op
RoundBench.round avgt 6 4.588 ± 0.182 ns/op
为了找到问题的根本原因，您可以使用https://github.com/AdoptOpenJDK/jitwatch/。为了节省时间，我可以说 Math#round 的 JITted 代码的大小在 8.0_40 中增加了。对于小方法几乎不引人注意，但是如果方法太长 sheet 机器代码会污染指令缓存。
不是一个确定的答案，但也许是另一个小贡献。
最初，我作为 遍历了整个链（有关详细信息，请参阅历史记录），跟踪并比较字节码，实现了 运行 次 - 尽管正如评论中指出的那样，在我的测试（在 Win7/8 上）和 "usual microbenchmark best practices" 中，性能差异并不像原始问题和第一个答案的第一个版本中建议的那样显着。
但是， 有所不同，所以我创建了另一个小测试：
public class MathRoundPerformance {
static final int size = 16;
static float[] data = new float[size];
public static void main(String[] args) {
for (int i = 0; i < size; i++) {
data[i] = i;
}
for (int n=1000000; n<=100000000; n+=5000000)
{
long t0 = System.nanoTime();
int result = runTest(n);
long t1 = System.nanoTime();
System.out.printf(
"%s, Math.round(float), %s, %s, %.1f ms\n",
System.getProperty("java.version"),
n, result, (t1 - t0) / 1e6);
}
}
public static int runTest(int n) {
int result = 0;
for (int i = 0; i < n; i++) {
int i0 = (i+0) % size;
int i1 = (i+1) % size;
result += Math.round(data[i0] + data[i1]);
result += Math.round(data[i0] * data[i1]);
result += Math.round(data[i0] / data[i1]);
}
return result;
}
}
计时结果（省略部分细节）已
...
1.8.0_31, Math.round(float), 96000000, -351934592, 504,8 ms
....
1.8.0_40, Math.round(float), 96000000, -351934592, 544,0 ms
我运行 使用热点反汇编程序 VM 的示例，使用
java -server -XX:+UnlockDiagnosticVMOptions -XX:+TraceClassLoading
-XX:+LogCompilation -XX:+PrintInlining -XX:+PrintAssembly
MathRoundPerformance
重要的是当程序结束时优化完成（或者至少，似乎完成）。这意味着最后一次调用 runTest 方法的结果会打印出来 ，而不会 在两次调用之间进行任何额外的 JIT 优化。
我试图通过查看生成的机器代码来找出差异。两个版本的大部分生成代码是相同的。但是由于最近添加的 , the number of instructions did increase in 8u40. I compared the source code of the Hotspot versions u20 and u40. I thought that there might be subtle differences in the intrinsics for floatToRawIntBits, but these files did not change. I considered that the checks for AVX or SSE4.2 可能会以一种不幸的方式影响机器代码的生成，但是......我的汇编程序知识不如我希望的那样好，因此，我不能在这里明确声明。总的来说，生成的机器码看起来主要是 reordered（也就是说，主要是 structurally 改变了），但是手动比较转储是一件痛苦的事……眼睛（地址都不同，即使 指令 大体相同）。
（我想在这里转储为 runTest 方法生成的机器代码的结果，但是一个答案有 30k 的奇怪限制）
我会尝试进一步分析和比较机器代码转储和热点代码。但最终，很难将矛头指向导致性能下降的 "the" 变化 - 就执行速度较慢的机器代码而言，以及导致变化的热点变化而言机器代码。
我有一个用 Java 8 编写的相当简单的爱好项目，它在其中一种操作模式中广泛使用重复的 Math.round() 调用。例如，一种这样的模式通过 ExecutorService 产生 4 个线程并排队 48 个 运行 可用任务，每个 运行 类似于以下代码块 2^31 次：
int3 = Math.round(float1 + float2);
int3 = Math.round(float1 * float2);
int3 = Math.round(float1 / float2);
事实并非如此（涉及数组和嵌套循环），但您明白了。无论如何，在 Java 8u40 之前，类似于上述的代码可以在 AMD A10-7700k 上在大约 13 秒内完成约 1030 亿个指令块的完整 运行。使用 Java 8u40 执行相同的操作大约需要 260 秒。没有更改代码，什么都没有，只是 Java 更新。
有没有其他人注意到 Math.round() 变得越来越慢，尤其是当它被重复使用时？就好像 JVM 在它不再做之前进行了某种优化。也许它在 8u40 之前使用 SIMD 而不是现在？
编辑： 我已经完成了对 MVCE 的第二次尝试。您可以在这里下载第一次尝试：
https://www.dropbox.com/s/rm2ftcv8y6ye1bi/MathRoundMVCE.zip?dl=0
第二次尝试如下。我的第一次尝试已从 post 中删除，因为它被认为太长，并且很容易被 JVM 删除死代码优化（这显然在 8u40 中发生得更少）。
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
public class MathRoundMVCE
{
static long grandtotal = 0;
static long sumtotal = 0;
static float[] float4 = new float[128];
static float[] float5 = new float[128];
static int[] int6 = new int[128];
static int[] int7 = new int[128];
static int[] int8 = new int[128];
static long[] longarray = new long[480];
final static int mil = 1000000;
public static void main(String[] args)
{
initmainarrays();
OmniCode omni = new OmniCode();
grandtotal = omni.runloops() / mil;
System.out.println("Total sum of operations is " + sumtotal);
System.out.println("Total execution time is " + grandtotal + " milliseconds");
}
public static long siftarray(long[] larray)
{
long topnum = 0;
long tempnum = 0;
for (short i = 0; i < larray.length; i++)
{
tempnum = larray[i];
if (tempnum > 0)
{
topnum += tempnum;
}
}
topnum = topnum / Runtime.getRuntime().availableProcessors();
return topnum;
}
public static void initmainarrays()
{
int k = 0;
do
{
float4[k] = (float)(Math.random() * 12) + 1f;
float5[k] = (float)(Math.random() * 12) + 1f;
int6[k] = 0;
k++;
}
while (k < 128);
}
}
class OmniCode extends Thread
{
volatile long totaltime = 0;
final int standard = 16777216;
final int warmup = 200000;
byte threads = 0;
public long runloops()
{
this.setPriority(MIN_PRIORITY);
threads = (byte)Runtime.getRuntime().availableProcessors();
ExecutorService executor = Executors.newFixedThreadPool(threads);
for (short j = 0; j < 48; j++)
{
executor.execute(new RoundFloatToIntAlternate(warmup, (byte)j));
}
executor.shutdown();
while (!executor.isTerminated())
{
try
{
Thread.sleep(100);
}
catch (InterruptedException e)
{
//Do nothing
}
}
executor = Executors.newFixedThreadPool(threads);
for (short j = 0; j < 48; j++)
{
executor.execute(new RoundFloatToIntAlternate(standard, (byte)j));
}
executor.shutdown();
while (!executor.isTerminated())
{
try
{
Thread.sleep(100);
}
catch (InterruptedException e)
{
//Do nothing
}
}
totaltime = MathRoundMVCE.siftarray(MathRoundMVCE.longarray);
executor = null;
Runtime.getRuntime().gc();
return totaltime;
}
}
class RoundFloatToIntAlternate extends Thread
{
int i = 0;
int j = 0;
int int3 = 0;
int iterations = 0;
byte thread = 0;
public RoundFloatToIntAlternate(int cycles, byte threadnumber)
{
iterations = cycles;
thread = threadnumber;
}
public void run()
{
this.setPriority(9);
MathRoundMVCE.longarray[this.thread] = 0;
mainloop();
blankloop();
}
public void blankloop()
{
j = 0;
long timer = 0;
long totaltimer = 0;
do
{
timer = System.nanoTime();
i = 0;
do
{
i++;
}
while (i < 128);
totaltimer += System.nanoTime() - timer;
j++;
}
while (j < iterations);
MathRoundMVCE.longarray[this.thread] -= totaltimer;
}
public void mainloop()
{
j = 0;
long timer = 0;
long totaltimer = 0;
long localsum = 0;
int[] int6 = new int[128];
int[] int7 = new int[128];
int[] int8 = new int[128];
do
{
timer = System.nanoTime();
i = 0;
do
{
int6[i] = Math.round(MathRoundMVCE.float4[i] + MathRoundMVCE.float5[i]);
int7[i] = Math.round(MathRoundMVCE.float4[i] * MathRoundMVCE.float5[i]);
int8[i] = Math.round(MathRoundMVCE.float4[i] / MathRoundMVCE.float5[i]);
i++;
}
while (i < 128);
totaltimer += System.nanoTime() - timer;
for(short z = 0; z < 128; z++)
{
localsum += int6[z] + int7[z] + int8[z];
}
j++;
}
while (j < iterations);
MathRoundMVCE.longarray[this.thread] += totaltimer;
MathRoundMVCE.sumtotal = localsum;
}
}
长话短说，此代码在 8u25 中的性能与在 8u40 中的性能大致相同。如您所见，我现在将所有计算的结果记录到数组中，然后将循环的定时部分之外的这些数组求和到一个局部变量，然后在外部循环结束时将其写入静态变量。
8u25以下：总执行时间为261545毫秒
8u40以下：总执行时间为266890毫秒
测试条件同上。因此，看起来 8u25 和 8u31 正在执行 8u40 停止执行的死代码删除，导致代码在 8u40 中变为 "slow down"。这并不能解释每一个突然出现的奇怪的小东西，但这似乎是其中的大部分。作为额外的奖励，这里提供的建议和答案给了我灵感来改进我的爱好项目的其他部分，对此我非常感激。谢谢大家！
基于OP的MVCE
- 可能会进一步简化
- 将
int3 =语句更改为int3 +=以减少删除死代码的机会。int3 =从 8u31 到 8u40 的差异是慢 3 倍。使用int3 +=差异仅慢 15%。 - 打印结果以进一步减少死代码删除优化的可能性
代码
public class MathTime {
static float[][] float1 = new float[8][16];
static float[][] float2 = new float[8][16];
public static void main(String[] args) {
for (int j = 0; j < 8; j++) {
for (int k = 0; k < 16; k++) {
float1[j][k] = (float) (j + k);
float2[j][k] = (float) (j + k);
}
}
new Test().run();
}
private static class Test {
int int3;
public void run() {
for (String test : new String[] { "warmup", "real" }) {
long t0 = System.nanoTime();
for (int count = 0; count < 1e7; count++) {
int i = count % 8;
int3 += Math.round(float1[i][0] + float2[i][0]);
int3 += Math.round(float1[i][1] + float2[i][1]);
int3 += Math.round(float1[i][2] + float2[i][2]);
int3 += Math.round(float1[i][3] + float2[i][3]);
int3 += Math.round(float1[i][4] + float2[i][4]);
int3 += Math.round(float1[i][5] + float2[i][5]);
int3 += Math.round(float1[i][6] + float2[i][6]);
int3 += Math.round(float1[i][7] + float2[i][7]);
int3 += Math.round(float1[i][8] + float2[i][8]);
int3 += Math.round(float1[i][9] + float2[i][9]);
int3 += Math.round(float1[i][10] + float2[i][10]);
int3 += Math.round(float1[i][11] + float2[i][11]);
int3 += Math.round(float1[i][12] + float2[i][12]);
int3 += Math.round(float1[i][13] + float2[i][13]);
int3 += Math.round(float1[i][14] + float2[i][14]);
int3 += Math.round(float1[i][15] + float2[i][15]);
int3 += Math.round(float1[i][0] * float2[i][0]);
int3 += Math.round(float1[i][1] * float2[i][1]);
int3 += Math.round(float1[i][2] * float2[i][2]);
int3 += Math.round(float1[i][3] * float2[i][3]);
int3 += Math.round(float1[i][4] * float2[i][4]);
int3 += Math.round(float1[i][5] * float2[i][5]);
int3 += Math.round(float1[i][6] * float2[i][6]);
int3 += Math.round(float1[i][7] * float2[i][7]);
int3 += Math.round(float1[i][8] * float2[i][8]);
int3 += Math.round(float1[i][9] * float2[i][9]);
int3 += Math.round(float1[i][10] * float2[i][10]);
int3 += Math.round(float1[i][11] * float2[i][11]);
int3 += Math.round(float1[i][12] * float2[i][12]);
int3 += Math.round(float1[i][13] * float2[i][13]);
int3 += Math.round(float1[i][14] * float2[i][14]);
int3 += Math.round(float1[i][15] * float2[i][15]);
int3 += Math.round(float1[i][0] / float2[i][0]);
int3 += Math.round(float1[i][1] / float2[i][1]);
int3 += Math.round(float1[i][2] / float2[i][2]);
int3 += Math.round(float1[i][3] / float2[i][3]);
int3 += Math.round(float1[i][4] / float2[i][4]);
int3 += Math.round(float1[i][5] / float2[i][5]);
int3 += Math.round(float1[i][6] / float2[i][6]);
int3 += Math.round(float1[i][7] / float2[i][7]);
int3 += Math.round(float1[i][8] / float2[i][8]);
int3 += Math.round(float1[i][9] / float2[i][9]);
int3 += Math.round(float1[i][10] / float2[i][10]);
int3 += Math.round(float1[i][11] / float2[i][11]);
int3 += Math.round(float1[i][12] / float2[i][12]);
int3 += Math.round(float1[i][13] / float2[i][13]);
int3 += Math.round(float1[i][14] / float2[i][14]);
int3 += Math.round(float1[i][15] / float2[i][15]);
}
long t1 = System.nanoTime();
System.out.println(int3);
System.out.println(String.format("%s, Math.round(float), %s, %.1f ms", System.getProperty("java.version"), test, (t1 - t0) / 1e6));
}
}
}
}
结果
adam@brimstone:~$ ./jdk1.8.0_40/bin/javac MathTime.java;./jdk1.8.0_40/bin/java -cp . MathTime
1.8.0_40, Math.round(float), warmup, 6846.4 ms
1.8.0_40, Math.round(float), real, 6058.6 ms
adam@brimstone:~$ ./jdk1.8.0_31/bin/javac MathTime.java;./jdk1.8.0_31/bin/java -cp . MathTime
1.8.0_31, Math.round(float), warmup, 5717.9 ms
1.8.0_31, Math.round(float), real, 5282.7 ms
adam@brimstone:~$ ./jdk1.8.0_25/bin/javac MathTime.java;./jdk1.8.0_25/bin/java -cp . MathTime
1.8.0_25, Math.round(float), warmup, 5702.4 ms
1.8.0_25, Math.round(float), real, 5262.2 ms
观察
- 对于 Math.round(float) 的简单使用，我发现在我的平台上没有性能差异 (Linux x86_64)。只有基准有所不同，正如 Ivan 的回答和 Marco13 的评论所指出的那样，我以前的幼稚和不正确的基准只暴露了优化行为的差异。
- 8u40 在消除死代码方面不如以前的版本积极，这意味着在某些极端情况下会执行更多代码，因此速度较慢。
- 8u40 预热时间稍长，但一旦 "there"，速度会更快。
来源分析
令人惊讶的是 Math.round(float) 是一个纯粹的 Java 实现而不是原生的，8u31 和 8u40 的代码是相同的。
diff jdk1.8.0_31/src/java/lang/Math.java jdk1.8.0_40/src/java/lang/Math.java
-no differences-
public static int round(float a) {
int intBits = Float.floatToRawIntBits(a);
int biasedExp = (intBits & FloatConsts.EXP_BIT_MASK)
>> (FloatConsts.SIGNIFICAND_WIDTH - 1);
int shift = (FloatConsts.SIGNIFICAND_WIDTH - 2
+ FloatConsts.EXP_BIAS) - biasedExp;
if ((shift & -32) == 0) { // shift >= 0 && shift < 32
// a is a finite number such that pow(2,-32) <= ulp(a) < 1
int r = ((intBits & FloatConsts.SIGNIF_BIT_MASK)
| (FloatConsts.SIGNIF_BIT_MASK + 1));
if (intBits < 0) {
r = -r;
}
// In the comments below each Java expression evaluates to the value
// the corresponding mathematical expression:
// (r) evaluates to a / ulp(a)
// (r >> shift) evaluates to floor(a * 2)
// ((r >> shift) + 1) evaluates to floor((a + 1/2) * 2)
// (((r >> shift) + 1) >> 1) evaluates to floor(a + 1/2)
return ((r >> shift) + 1) >> 1;
} else {
// a is either
// - a finite number with abs(a) < exp(2,FloatConsts.SIGNIFICAND_WIDTH-32) < 1/2
// - a finite number with ulp(a) >= 1 and hence a is a mathematical integer
// - an infinity or NaN
return (int) a;
}
}
Casual benchmarking: you benchmark A, but actually measure B, and conclude you've measured C.
现代 JVM 过于复杂，并且进行了各种优化。如果您尝试测量一小段代码，如果不非常非常详细地了解 JVM 正在做什么，要正确地完成它真的很复杂。 许多基准测试的罪魁祸首是死代码消除：编译器足够聪明，可以推断出一些计算是多余的，并完全消除它们。请阅读以下幻灯片 http://shipilev.net/talks/jvmls-July2014-benchmarking.pdf。为了 "fix" Adam 的微基准测试（我仍然不明白它在测量什么，而且这个 "fix" 没有考虑预热、OSR 和许多其他微基准测试陷阱）我们必须打印结果系统输出的计算：
int result = 0;
long t0 = System.currentTimeMillis();
for (int i = 0; i < 1e9; i++) {
result += Math.round((float) i / (float) (i + 1));
}
long t1 = System.currentTimeMillis();
System.out.println("result = " + result);
System.out.println(String.format("%s, Math.round(float), %.1f ms", System.getProperty("java.version"), (t1 - t0)/1f));
结果：
result = 999999999
1.8.0_25, Math.round(float), 5251.0 ms
result = 999999999
1.8.0_40, Math.round(float), 3903.0 ms
与原始 MVCE 示例相同 "fix"
It took 401772 milliseconds to complete edu.jvm.runtime.RoundFloatToInt. <==== 1.8.0_40
It took 410767 milliseconds to complete edu.jvm.runtime.RoundFloatToInt. <==== 1.8.0_25
如果你想衡量 Math#round 的实际成本，你应该这样写（基于 jmh）
package org.openjdk.jmh.samples;
import org.openjdk.jmh.annotations.*;
import org.openjdk.jmh.runner.Runner;
import org.openjdk.jmh.runner.RunnerException;
import org.openjdk.jmh.runner.options.Options;
import org.openjdk.jmh.runner.options.OptionsBuilder;
import org.openjdk.jmh.runner.options.VerboseMode;
import java.util.Random;
import java.util.concurrent.TimeUnit;
@State(Scope.Benchmark)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@Warmup(iterations = 3, time = 5, timeUnit = TimeUnit.SECONDS)
@Measurement(iterations = 3, time = 5, timeUnit = TimeUnit.SECONDS)
public class RoundBench {
float[] floats;
int i;
@Setup
public void initI() {
Random random = new Random(0xDEAD_BEEF);
floats = new float[8096];
for (int i = 0; i < floats.length; i++) {
floats[i] = random.nextFloat();
}
}
@Benchmark
public float baseline() {
i++;
i = i & 0xFFFFFF00;
return floats[i];
}
@Benchmark
public int round() {
i++;
i = i & 0xFFFFFF00;
return Math.round(floats[i]);
}
public static void main(String[] args) throws RunnerException {
Options options = new OptionsBuilder()
.include(RoundBench.class.getName())
.build();
new Runner(options).run();
}
}
我的结果是：
1.8.0_25
Benchmark Mode Cnt Score Error Units
RoundBench.baseline avgt 6 2.565 ± 0.028 ns/op
RoundBench.round avgt 6 4.459 ± 0.065 ns/op
1.8.0_40
Benchmark Mode Cnt Score Error Units
RoundBench.baseline avgt 6 2.589 ± 0.045 ns/op
RoundBench.round avgt 6 4.588 ± 0.182 ns/op
为了找到问题的根本原因，您可以使用https://github.com/AdoptOpenJDK/jitwatch/。为了节省时间，我可以说 Math#round 的 JITted 代码的大小在 8.0_40 中增加了。对于小方法几乎不引人注意，但是如果方法太长 sheet 机器代码会污染指令缓存。
不是一个确定的答案，但也许是另一个小贡献。
最初，我作为
但是， 有所不同，所以我创建了另一个小测试：
public class MathRoundPerformance {
static final int size = 16;
static float[] data = new float[size];
public static void main(String[] args) {
for (int i = 0; i < size; i++) {
data[i] = i;
}
for (int n=1000000; n<=100000000; n+=5000000)
{
long t0 = System.nanoTime();
int result = runTest(n);
long t1 = System.nanoTime();
System.out.printf(
"%s, Math.round(float), %s, %s, %.1f ms\n",
System.getProperty("java.version"),
n, result, (t1 - t0) / 1e6);
}
}
public static int runTest(int n) {
int result = 0;
for (int i = 0; i < n; i++) {
int i0 = (i+0) % size;
int i1 = (i+1) % size;
result += Math.round(data[i0] + data[i1]);
result += Math.round(data[i0] * data[i1]);
result += Math.round(data[i0] / data[i1]);
}
return result;
}
}
计时结果（省略部分细节）已
...
1.8.0_31, Math.round(float), 96000000, -351934592, 504,8 ms
....
1.8.0_40, Math.round(float), 96000000, -351934592, 544,0 ms
我运行 使用热点反汇编程序 VM 的示例，使用
java -server -XX:+UnlockDiagnosticVMOptions -XX:+TraceClassLoading
-XX:+LogCompilation -XX:+PrintInlining -XX:+PrintAssembly
MathRoundPerformance
重要的是当程序结束时优化完成（或者至少，似乎完成）。这意味着最后一次调用 runTest 方法的结果会打印出来 ，而不会 在两次调用之间进行任何额外的 JIT 优化。
我试图通过查看生成的机器代码来找出差异。两个版本的大部分生成代码是相同的。但是由于最近添加的
（我想在这里转储为 runTest 方法生成的机器代码的结果，但是一个答案有 30k 的奇怪限制）
我会尝试进一步分析和比较机器代码转储和热点代码。但最终，很难将矛头指向导致性能下降的 "the" 变化 - 就执行速度较慢的机器代码而言，以及导致变化的热点变化而言机器代码。