如果是,这个 JMH 微基准测试是如何倾斜的?
How is this JMH microbenchmark skewed, if it is?
基准非常简单:
@State(Scope.Benchmark)
public class MathPowVsRawMultiplyTest
{
private static final double VICTIM;
static {
VICTIM = new Random(System.currentTimeMillis()).nextDouble();
}
double result;
@Benchmark
public void mathPow()
{
result = Math.pow(VICTIM, 2.0);
}
@Benchmark
public void rawMultiply()
{
result = VICTIM * VICTIM;
}
public static void main(final String... args)
throws RunnerException
{
final Options options = new OptionsBuilder()
.include(MathPowVsRawMultiplyTest.class.getCanonicalName())
.forks(1)
.warmupMode(WarmupMode.BULK)
.warmupIterations(1)
.measurementIterations(1)
.build();
new Runner(options).run();
}
}
当然,环境很重要,所以这里是:
- 这个 main() 运行 通过 IDEA 15.0.1;
- Ubuntu 15.10, x86_64;
- 甲骨文 JDK 1.8u65;
- 机器是戴尔 M3800、16 GiB RAM、8 CPU 内核,
/proc/cpuinfo
的第一段如下。
CPU信息:
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 60
model name : Intel(R) Core(TM) i7-4712HQ CPU @ 2.30GHz
stepping : 3
microcode : 0x1c
cpu MHz : 3235.722
cache size : 6144 KB
physical id : 0
siblings : 8
core id : 0
cpu cores : 4
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt
bugs :
bogomips : 4589.60
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:
基准测试结果:
Benchmark Mode Cnt Score Error Units
MathPowVsRawMultiplyTest.mathPow thrpt 2342955236.832 ops/s
MathPowVsRawMultiplyTest.rawMultiply thrpt 2375082332.164 ops/s
我还没有做的是尝试看看 JVM 可以为 Math.pow()
做哪些优化;但结果似乎很接近。
问题是我不太了解 JMH,因此我想知道:是我的基准完全有缺陷,还是 CPU/JIT 组合那么好?
您的基准测试完全有缺陷,因为编译器能够不断折叠来自 static final
字段的负载。您是否至少阅读了前几个示例,尤其是 JMHSample_10_ConstantFold and JMHSample_08_DeadCode?这是它做得更好的方式(但未实际验证,caveat emptor):
@State(Scope.Benchmark)
public class MathPowVsRawMultiplyTest {
private double v;
@Setup
public void setup {
v = new Random(System.currentTimeMillis()).nextDouble();
}
@Benchmark
public double mathPow() {
return Math.pow(v, 2.0);
}
@Benchmark
public void rawMultiply() {
return v * v;
}
}
还建议您将时间单位设置为纳秒(参见 @OutputTimeUnit
或 -tu
),并切换到平均时间测量而不是吞吐量(参见 @BenchmarkMode
或 -bm
).此外,对于像这样的纳米基准测试,您 需要 验证编译代码中的差异,例如 -prof perfasm
可用。
基准非常简单:
@State(Scope.Benchmark)
public class MathPowVsRawMultiplyTest
{
private static final double VICTIM;
static {
VICTIM = new Random(System.currentTimeMillis()).nextDouble();
}
double result;
@Benchmark
public void mathPow()
{
result = Math.pow(VICTIM, 2.0);
}
@Benchmark
public void rawMultiply()
{
result = VICTIM * VICTIM;
}
public static void main(final String... args)
throws RunnerException
{
final Options options = new OptionsBuilder()
.include(MathPowVsRawMultiplyTest.class.getCanonicalName())
.forks(1)
.warmupMode(WarmupMode.BULK)
.warmupIterations(1)
.measurementIterations(1)
.build();
new Runner(options).run();
}
}
当然,环境很重要,所以这里是:
- 这个 main() 运行 通过 IDEA 15.0.1;
- Ubuntu 15.10, x86_64;
- 甲骨文 JDK 1.8u65;
- 机器是戴尔 M3800、16 GiB RAM、8 CPU 内核,
/proc/cpuinfo
的第一段如下。
CPU信息:
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 60
model name : Intel(R) Core(TM) i7-4712HQ CPU @ 2.30GHz
stepping : 3
microcode : 0x1c
cpu MHz : 3235.722
cache size : 6144 KB
physical id : 0
siblings : 8
core id : 0
cpu cores : 4
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt
bugs :
bogomips : 4589.60
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:
基准测试结果:
Benchmark Mode Cnt Score Error Units
MathPowVsRawMultiplyTest.mathPow thrpt 2342955236.832 ops/s
MathPowVsRawMultiplyTest.rawMultiply thrpt 2375082332.164 ops/s
我还没有做的是尝试看看 JVM 可以为 Math.pow()
做哪些优化;但结果似乎很接近。
问题是我不太了解 JMH,因此我想知道:是我的基准完全有缺陷,还是 CPU/JIT 组合那么好?
您的基准测试完全有缺陷,因为编译器能够不断折叠来自 static final
字段的负载。您是否至少阅读了前几个示例,尤其是 JMHSample_10_ConstantFold and JMHSample_08_DeadCode?这是它做得更好的方式(但未实际验证,caveat emptor):
@State(Scope.Benchmark)
public class MathPowVsRawMultiplyTest {
private double v;
@Setup
public void setup {
v = new Random(System.currentTimeMillis()).nextDouble();
}
@Benchmark
public double mathPow() {
return Math.pow(v, 2.0);
}
@Benchmark
public void rawMultiply() {
return v * v;
}
}
还建议您将时间单位设置为纳秒(参见 @OutputTimeUnit
或 -tu
),并切换到平均时间测量而不是吞吐量(参见 @BenchmarkMode
或 -bm
).此外,对于像这样的纳米基准测试,您 需要 验证编译代码中的差异,例如 -prof perfasm
可用。