gpt4 book ai didi

java - 通过 JMH 进行的 sun.misc.Unsafe.compareAndSwap 测量中的奇怪行为

转载 作者:搜寻专家 更新时间:2023-10-31 19:27:45 24 4
gpt4 key购买 nike

我决定使用不同的锁定策略来衡量增量,并为此目的使用 JMH。我正在使用 JMH 检查吞吐量和平均时间以及检查正确性的简单自定义测试。有六种策略:

  • 原子计数
  • 读写锁定计数
  • 与 volatile 同步
  • 没有volatile的同步块(synchronized block)
  • sun.misc.Unsafe.compareAndSwap
  • sun.misc.Unsafe.getAndAdd
  • 不同步计数

基准代码:

@State(Scope.Benchmark)
@BenchmarkMode({Mode.Throughput, Mode.AverageTime})
@OutputTimeUnit(TimeUnit.MICROSECONDS)
@Fork(1)
@Warmup(iterations = 5)
@Measurement(iterations = 5)
public class UnsafeCounter_Benchmark {
public Counter unsync, syncNoV, syncV, lock, atomic, unsafe, unsafeGA;

@Setup(Level.Iteration)
public void prepare() {
unsync = new UnsyncCounter();
syncNoV = new SyncNoVolatileCounter();
syncV = new SyncVolatileCounter();
lock = new LockCounter();
atomic = new AtomicCounter();
unsafe = new UnsafeCASCounter();
unsafeGA = new UnsafeGACounter();
}

@Benchmark
public void unsyncCount() {
unsyncCounter();
}

@CompilerControl(CompilerControl.Mode.DONT_INLINE)
public void unsyncCounter() {
unsync.increment();
}

@Benchmark
public void syncNoVCount() {
syncNoVCounter();
}

@CompilerControl(CompilerControl.Mode.DONT_INLINE)
public void syncNoVCounter() {
syncNoV.increment();
}

@Benchmark
public void syncVCount() {
syncVCounter();
}

@CompilerControl(CompilerControl.Mode.DONT_INLINE)
public void syncVCounter() {
syncV.increment();
}

@Benchmark
public void lockCount() {
lockCounter();
}

@CompilerControl(CompilerControl.Mode.DONT_INLINE)
public void lockCounter() {
lock.increment();
}

@Benchmark
public void atomicCount() {
atomicCounter();
}

@CompilerControl(CompilerControl.Mode.DONT_INLINE)
public void atomicCounter() {
atomic.increment();
}

@Benchmark
public void unsafeCount() {
unsafeCounter();
}

@CompilerControl(CompilerControl.Mode.DONT_INLINE)
public void unsafeCounter() {
unsafe.increment();
}

@Benchmark
public void unsafeGACount() {
unsafeGACounter();
}

@CompilerControl(CompilerControl.Mode.DONT_INLINE)
public void unsafeGACounter() {
unsafeGA.increment();
}

public static void main(String[] args) throws RunnerException {
Options baseOpts = new OptionsBuilder()
.include(UnsafeCounter_Benchmark.class.getSimpleName())
.threads(100)
.jvmArgs("-ea")
.build();

new Runner(baseOpts).run();
}
}

和基准测试结果:

JDK 8u20

Benchmark                                         Mode  Samples   Score    Error   Units
o.k.u.u.UnsafeCounter_Benchmark.atomicCount thrpt 5 42.178 ± 17.643 ops/us
o.k.u.u.UnsafeCounter_Benchmark.lockCount thrpt 5 24.044 ± 2.264 ops/us
o.k.u.u.UnsafeCounter_Benchmark.syncNoVCount thrpt 5 22.849 ± 1.344 ops/us
o.k.u.u.UnsafeCounter_Benchmark.syncVCount thrpt 5 20.235 ± 2.027 ops/us
o.k.u.u.UnsafeCounter_Benchmark.unsafeCount thrpt 5 12.460 ± 1.326 ops/us
o.k.u.u.UnsafeCounter_Benchmark.unsafeGACount thrpt 5 39.106 ± 2.966 ops/us
o.k.u.u.UnsafeCounter_Benchmark.unsyncCount thrpt 5 93.076 ± 9.674 ops/us
o.k.u.u.UnsafeCounter_Benchmark.atomicCount avgt 5 2.604 ± 0.133 us/op
o.k.u.u.UnsafeCounter_Benchmark.lockCount avgt 5 4.161 ± 0.546 us/op
o.k.u.u.UnsafeCounter_Benchmark.syncNoVCount avgt 5 4.440 ± 0.523 us/op
o.k.u.u.UnsafeCounter_Benchmark.syncVCount avgt 5 5.073 ± 0.439 us/op
o.k.u.u.UnsafeCounter_Benchmark.unsafeCount avgt 5 9.088 ± 5.964 us/op
o.k.u.u.UnsafeCounter_Benchmark.unsafeGACount avgt 5 2.611 ± 0.164 us/op
o.k.u.u.UnsafeCounter_Benchmark.unsyncCount avgt 5 1.047 ± 0.050 us/op

大多数测量结果如我所料,除了 UnsafeCounter_Benchmark.unsafeCount,它使用 sun.misc.Unsafe.compareAndSwapLongwhile 循环。它是最慢的锁定。

public void increment() {
long before = counter;
while (!unsafe.compareAndSwapLong(this, offset, before, before + 1L)) {
before = counter;
}
}

我认为低性能是因为 while 循环和 JMH 引起了更高的争用,但是当我通过 Executors 检查正确性时,我得到了我预期的数字:

Counter result: UnsyncCounter 97538676
Time passed in ms:259
Counter result: AtomicCounter 100000000
Time passed in ms:1805
Counter result: LockCounter 100000000
Time passed in ms:3904
Counter result: SyncNoVolatileCounter 100000000
Time passed in ms:14227
Counter result: SyncVolatileCounter 100000000
Time passed in ms:19224
Counter result: UnsafeCASCounter 100000000
Time passed in ms:8077
Counter result: UnsafeGACounter 100000000
Time passed in ms:2549

正确性测试代码:

public class UnsafeCounter_Test {
static class CounterClient implements Runnable {
private Counter c;
private int num;

public CounterClient(Counter c, int num) {
this.c = c;
this.num = num;
}

@Override
public void run() {
for (int i = 0; i < num; i++) {
c.increment();
}
}
}

public static void makeTest(Counter counter) throws InterruptedException {
int NUM_OF_THREADS = 1000;
int NUM_OF_INCREMENTS = 100000;
ExecutorService service = Executors.newFixedThreadPool(NUM_OF_THREADS);
long before = System.currentTimeMillis();
for (int i = 0; i < NUM_OF_THREADS; i++) {
service.submit(new CounterClient(counter, NUM_OF_INCREMENTS));
}
service.shutdown();
service.awaitTermination(1, TimeUnit.MINUTES);
long after = System.currentTimeMillis();
System.out.println("Counter result: " + counter.getClass().getSimpleName() + " " + counter.getCounter());
System.out.println("Time passed in ms:" + (after - before));
}

public static void main(String[] args) throws InterruptedException {
makeTest(new UnsyncCounter());
makeTest(new AtomicCounter());
makeTest(new LockCounter());
makeTest(new SyncNoVolatileCounter());
makeTest(new SyncVolatileCounter());
makeTest(new UnsafeCASCounter());
makeTest(new UnsafeGACounter());
}
}

我知道这是非常糟糕的测试,但在这种情况下,Unsafe CAS 比 Sync 变体快两倍,一切都按预期进行。有人可以澄清所描述的行为吗?有关详细信息,请参阅 GitHub 存储库:Bench , Unsafe CAS counter

最佳答案

大声思考:人们通常会完成 90% 的乏味工作,而将 10%(乐趣开始的地方)留给其他人,这很了不起!好吧,我正在享受所有的乐趣!

让我先在我的 i7-4790K、8u40 EA 上重复这个实验:

Benchmark                                 Mode  Samples    Score    Error   Units
UnsafeCounter_Benchmark.atomicCount thrpt 5 47.669 ± 18.440 ops/us
UnsafeCounter_Benchmark.lockCount thrpt 5 14.497 ± 7.815 ops/us
UnsafeCounter_Benchmark.syncNoVCount thrpt 5 11.618 ± 2.130 ops/us
UnsafeCounter_Benchmark.syncVCount thrpt 5 11.337 ± 4.532 ops/us
UnsafeCounter_Benchmark.unsafeCount thrpt 5 7.452 ± 1.042 ops/us
UnsafeCounter_Benchmark.unsafeGACount thrpt 5 43.332 ± 3.435 ops/us
UnsafeCounter_Benchmark.unsyncCount thrpt 5 102.773 ± 11.943 ops/us

确实,unsafeCount 测试似乎有些可疑。确实,在验证之前,您必须假设所有数据都是可疑的。对于 nanobenchmarks,您必须验证生成的代码,看看您是否真的测量了您想要测量的东西。在 JMH 中,使用 -prof perfasm 可以非常快速地实现。事实上,如果您查看 unsafeCount 中 HitTest 的区域,您会注意到一些有趣的事情:

  0.12%    0.04%    0x00007fb45518e7d1: mov    0x10(%r10),%rax    
17.03% 23.44% 0x00007fb45518e7d5: test %eax,0x17318825(%rip)
0.21% 0.07% 0x00007fb45518e7db: mov 0x18(%r10),%r11 ; getfield offset
30.33% 10.77% 0x00007fb45518e7df: mov %rax,%r8
0.00% 0x00007fb45518e7e2: add $0x1,%r8
0.01% 0x00007fb45518e7e6: cmp 0xc(%r10),%r12d ; typecheck
0x00007fb45518e7ea: je 0x00007fb45518e80b ; bail to v-call
0.83% 0.48% 0x00007fb45518e7ec: lock cmpxchg %r8,(%r10,%r11,1)
33.27% 25.52% 0x00007fb45518e7f2: sete %r8b
0.12% 0.01% 0x00007fb45518e7f6: movzbl %r8b,%r8d
0.03% 0.04% 0x00007fb45518e7fa: test %r8d,%r8d
0x00007fb45518e7fd: je 0x00007fb45518e7d1 ; back branch

翻译:a) offset 字段在每次迭代时都会被重新读取——因为 CAS 内存效应意味着 volatile 读取,因此需要悲观地重新读取该字段; b) 有趣的是 unsafe 字段被重新读取以进行类型检查——出于同样的原因。

这就是为什么高性能代码应该是这样的:

--- a/utils bench/src/main/java/org/kirmit/utils/unsafe/concurrency/UnsafeCASCounter.java       
+++ b/utils bench/src/main/java/org/kirmit/utils/unsafe/concurrency/UnsafeCASCounter.java
@@ -5,13 +5,13 @@ import sun.misc.Unsafe;

public class UnsafeCASCounter implements Counter {
private volatile long counter = 0;
- private final Unsafe unsafe = UnsafeHelper.unsafe;
- private long offset;
- {
+ private static final Unsafe unsafe = UnsafeHelper.unsafe;
+ private static final long offset;
+ static {
try {
offset = unsafe.objectFieldOffset(UnsafeCASCounter.class.getDeclaredField("counter"));
} catch (NoSuchFieldException e) {
- e.printStackTrace();
+ throw new IllegalStateException("Whoops!");
}
}

如果这样做,unsafeCount 的性能会立即提升:

Benchmark                              Mode  Samples   Score    Error   Units
UnsafeCounter_Benchmark.unsafeCount thrpt 5 9.733 ± 0.673 ops/us

...考虑到错误范围,现在已经非常接近同步测试了。如果您现在查看 -prof perfasm,这是一个 unsafeCount 循环:

  0.08%    0.02%    0x00007f7575191900: mov    0x10(%r10),%rax       
28.09% 28.64% 0x00007f7575191904: test %eax,0x161286f6(%rip)
0.23% 0.08% 0x00007f757519190a: mov %rax,%r11
0x00007f757519190d: add $0x1,%r11
0x00007f7575191911: lock cmpxchg %r11,0x10(%r10)
47.27% 23.48% 0x00007f7575191917: sete %r8b
0.10% 0x00007f757519191b: movzbl %r8b,%r8d
0.02% 0x00007f757519191f: test %r8d,%r8d
0x00007f7575191922: je 0x00007f7575191900

这个循环很紧凑,似乎没有什么能让它走得更快。我们大部分时间都在加载“更新的”值并实际对它进行 CAS 处理。但是我们争吵很多!为了弄清楚争用是否是主要原因,让我们添加退避:

--- a/utils bench/src/main/java/org/kirmit/utils/unsafe/concurrency/UnsafeCASCounter.java       
+++ b/utils bench/src/main/java/org/kirmit/utils/unsafe/concurrency/UnsafeCASCounter.java
@@ -20,6 +21,7 @@ public class UnsafeCASCounter implements Counter {
long before = counter;
while (!unsafe.compareAndSwapLong(this, offset, before, before + 1L)) {
before = counter;
+ Blackhole.consumeCPU(1000);
}
}

...运行:

Benchmark                                 Mode  Samples    Score    Error   Units
UnsafeCounter_Benchmark.unsafeCount thrpt 5 99.869 ± 107.933 ops/us

瞧。我们在循环中做了更多的工作,但这使我们免于争吵。我之前在 "Nanotrusting the Nanotime" 中尝试过对此进行解释,返回那里并阅读更多有关基准测试方法的信息可能会很好,尤其是在测量重量级操作时。这突出了整个实验中的陷阱,而不仅仅是 unsafeCount

针对 OP 和感兴趣的读者的练习:解释为什么 unsafeGACountatomicCount 比其他测试执行得更快。您现在拥有了工具。

附言在具有 C (C < N) 个线程的机器上运行 N 个线程是愚蠢的:您可能认为您与 N 个线程“争用”,但实际上您只是在运行和“争用”C 个线程。当人们在 4 核机器上做 1000 个线程时,特别有趣...

附言时间检查:10 分钟做分析和额外的实验,20 分钟写下来。您浪费了多少时间手工复制结果? ;)

关于java - 通过 JMH 进行的 sun.misc.Unsafe.compareAndSwap 测量中的奇怪行为,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/26995856/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com