Interlocked.Exchange <t>比Interlocked.CompareExchange <t>慢?

时间:2018-01-26 21:51:29

标签: c# .net .net-core compare-and-swap interlocked

我在优化程序时遇到了一些奇怪的性能结果,这些结果显示在以下BenchmarkDotNet基准测试中:

string _s, _y = "yo";

[Benchmark]
public void Exchange() => Interlocked.Exchange(ref _s, null);

[Benchmark]
public void CompareExchange() => Interlocked.CompareExchange(ref _s, _y, null);

结果如下:

BenchmarkDotNet=v0.10.10, OS=Windows 10 Redstone 3 [1709, Fall Creators Update] (10.0.16299.192)
Processor=Intel Core i7-6700HQ CPU 2.60GHz (Skylake), ProcessorCount=8
Frequency=2531248 Hz, Resolution=395.0620 ns, Timer=TSC
.NET Core SDK=2.1.4
  [Host]     : .NET Core 2.0.5 (Framework 4.6.26020.03), 64bit RyuJIT
  DefaultJob : .NET Core 2.0.5 (Framework 4.6.26020.03), 64bit RyuJIT

          Method |      Mean |     Error |    StdDev |
---------------- |----------:|----------:|----------:|
        Exchange | 20.525 ns | 0.4357 ns | 0.4662 ns |
 CompareExchange |  7.017 ns | 0.1070 ns | 0.1001 ns |

似乎Interlocked.Exchange的速度是Interlocked.CompareExchange的两倍 - 这令人困惑,因为它应该做的工作少了。除非我错了,否则两者都应该是CPU操作。

有没有人对这可能发生的原因有一个很好的解释?这是CPU操作中的实际性能差异还是.NET Core包装它们的一些问题?

如果出现这种情况,最好避免Interlocked.Exchange()并尽可能使用Interlocked.CompareExchange()

编辑:另一件奇怪的事情:当我使用int或long而不是字符串运行相同的基准测试时,我或多或少地获得相同的运行时间。另外,我使用BenchmarkDotNet的反汇编诊断程序来查看正在生成的程序集,并发现了一些有趣的内容:使用int / long版本我可以清楚地看到xchg和cmpxchg指令,但是我看到调用了Interlocked.Exchange/Interlocked的字符串。 CompareExchange方法......!

EDIT2:coreclr中打开的问题:https://github.com/dotnet/coreclr/issues/16051

2 个答案:

答案 0 :(得分:7)

跟进我的评论,这似乎是Exchange的泛型重载问题。

如果完全避免泛型过载(将_s_y的类型更改为object),性能差异就会消失。

问题仍然存在,为什么解决泛型重载只会减慢Exchange的速度。阅读Interlocked源代码,似乎在CompareExchange<T>中实施了一个黑客攻击,以加快速度。 CompareExchange<T>上的源代码评论如下:

 * CompareExchange<T>
 * 
 * Notice how CompareExchange<T>() uses the __makeref keyword
 * to create two TypedReferences before calling _CompareExchange().
 * This is horribly slow. Ideally we would like CompareExchange<T>()
 * to simply call CompareExchange(ref Object, Object, Object); 
 * however, this would require casting a "ref T" into a "ref Object", 
 * which is not legal in C#.
 * 
 * Thus we opted to cheat, and hacked to JIT so that when it reads
 * the method body for CompareExchange<T>() it gets back the
 * following IL:
 *
 *     ldarg.0 
 *     ldarg.1
 *     ldarg.2
 *     call System.Threading.Interlocked::CompareExchange(ref Object, Object, Object)
 *     ret
 *
 * See getILIntrinsicImplementationForInterlocked() in VM\JitInterface.cpp
 * for details.

Exchange<T>中没有任何类似的评论,它也使用了“可怕的慢”__makeref,所以这可能是你看到这种意想不到的行为的原因。

所有这些当然是我的解释,你实际上需要.NET团队中的某个人来确认我的怀疑。

答案 1 :(得分:0)

现在已在.Net Core的较新版本中修复:

https://github.com/dotnet/coreclr/issues/16051