我如何获得一致的标准基准，或在不同的跑步中解释结果

Question

我正在尝试优化一些代码，使用criteria来尝试比较，例如，向函数添加INLINE杂注的效果。但我发现重新编译/运行之间的结果并不一致。

我需要知道如何在不同的运行中获得一致的结果，以便进行比较，或者如何评估基准是否可靠，即（我想）如何解释差异的细节、"时钟调用的成本"等。

关于我的具体案例的详细信息

这与我上面的主要问题正交，但在我的特定情况下，有几件事可能会导致不一致：

1. 我尝试使用whnfIO对IO操作进行基准测试，因为本例中使用whnf的方法不起作用。

2. 我的代码使用并发

3. 我有很多标签和垃圾打开

示例输出

这两者都来自相同的代码，以完全相同的方式编译。我直接在下面运行了第一次，做了一个更改并进行了另一个基准测试，然后恢复并再次运行第一次代码，使用进行编译

ghc --make -fforce-recomp -threaded -O2 Benchmark.hs

首次运行：

estimating clock resolution...                                      
mean is 16.97297 us (40001 iterations)                              
found 6222 outliers among 39999 samples (15.6%)                     
  6055 (15.1%) high severe                                          
estimating cost of a clock call...                                  
mean is 1.838749 us (49 iterations)                                 
found 8 outliers among 49 samples (16.3%)                           
  3 (6.1%) high mild                                                
  5 (10.2%) high severe                                             
benchmarking actors/insert 1000, query 1000                         
collecting 100 samples, 1 iterations each, in estimated 12.66122 s  
mean: 110.8566 ms, lb 108.4353 ms, ub 113.6627 ms, ci 0.950         
std dev: 13.41726 ms, lb 11.58487 ms, ub 16.25262 ms, ci 0.950      
found 2 outliers among 100 samples (2.0%)                           
  2 (2.0%) high mild                                                
variance introduced by outliers: 85.211%                            
variance is severely inflated by outliers                           
benchmarking actors/insert 1000, query 100000                       
collecting 100 samples, 1 iterations each, in estimated 945.5325 s  
mean: 9.319406 s, lb 9.152310 s, ub 9.412688 s, ci 0.950            
std dev: 624.8493 ms, lb 385.4364 ms, ub 956.7049 ms, ci 0.950      
found 6 outliers among 100 samples (6.0%)                           
  3 (3.0%) low severe                                               
  1 (1.0%) high severe                                              
variance introduced by outliers: 62.576%                            
variance is severely inflated by outliers

第二次运行，慢3倍：

estimating clock resolution...
mean is 51.46815 us (10001 iterations)
found 203 outliers among 9999 samples (2.0%)
  117 (1.2%) high severe
estimating cost of a clock call...
mean is 4.615408 us (18 iterations)
found 4 outliers among 18 samples (22.2%)
  4 (22.2%) high severe
benchmarking actors/insert 1000, query 1000
collecting 100 samples, 1 iterations each, in estimated 38.39478 s
mean: 302.4651 ms, lb 295.9046 ms, ub 309.5958 ms, ci 0.950
std dev: 35.12913 ms, lb 31.35431 ms, ub 42.20590 ms, ci 0.950
found 1 outliers among 100 samples (1.0%)
variance introduced by outliers: 84.163%
variance is severely inflated by outliers
benchmarking actors/insert 1000, query 100000
collecting 100 samples, 1 iterations each, in estimated 2644.987 s
mean: 27.71277 s, lb 26.95914 s, ub 28.97871 s, ci 0.950
std dev: 4.893489 s, lb 3.373838 s, ub 7.302145 s, ci 0.950
found 21 outliers among 100 samples (21.0%)
  4 (4.0%) low severe
  3 (3.0%) low mild
  3 (3.0%) high mild
  11 (11.0%) high severe
variance introduced by outliers: 92.567%
variance is severely inflated by outliers

我注意到，如果我按"时钟呼叫的估计成本"来衡量，这两个基准相当接近。我应该这样做才能得到一个实数进行比较吗？

Answer 1

虽然这里肯定没有足够的信息来确定每个问题，但我有一些建议可能会有所帮助。

解释标准结果

被识别为异常值的样本的问题是，标准无法真正判断它们是因为垃圾数据而成为异常值，还是因为某种正当原因而不同的有效数据。它可能强烈暗示它们是垃圾（"方差严重膨胀"线），但这真正意味着你需要调查你的测试环境、测试或应用程序本身，以确定异常值的来源。在这种情况下，它几乎肯定是由系统负载引起的（基于您提供的其他信息）。

您可能有兴趣阅读BOS发布的标准，该标准更详细地解释了它的工作原理，并举例说明了系统负载如何影响基准测试过程。

我非常怀疑"一个时钟呼叫的估计成本"的差异。请注意，异常值的比例很高（在两次运行中），这些异常值具有"高度严重"的影响。我认为这意味着所采用的时钟计时标准是垃圾（可能在两次运行中都是垃圾），使得其他一切都不可靠。正如@DanielFischer所建议的，关闭其他应用程序可能有助于解决这个问题。最坏的情况可能是硬件问题。如果关闭了所有其他应用程序，但时钟计时仍然不可靠，则可能需要在其他系统上进行测试。

如果在同一个系统上运行多个测试，那么每次运行的时钟计时和成本应该相当一致。如果它们不是，则某些因素会影响时间，从而导致数据不可靠。

除此之外，这里有两个随机的想法可能是一个因素。

CPU负载

线程运行时可能对CPU负载敏感。默认RTS值适用于许多应用程序，除非您的系统负载过重。问题是垃圾收集器中有几个关键部分，因此，如果Haskell运行时资源不足（因为它与其他应用程序争夺CPU或内存），那么等待这些部分时，所有进度都可能被阻止。我看到这会影响性能2.5倍，这或多或少与你看到的三倍差异一致。

即使您在垃圾收集器方面没有问题，来自其他应用程序的高CPU负载也会扭曲您的结果，如果可能的话，应该消除这种情况。

如何诊断

• 使用top或其他系统实用程序检查CPU负载
• 使用+RTS -s运行。在静力学的底部，寻找这些线

-RTS的输出

gc_alloc_block_sync: 0
whitehole_spin: 0
gen[0].sync: 0
gen[1].sync: 0

非零值表示垃圾收集器中的资源争用。此处的值较大表示存在严重问题。

如何修复

• 关闭其他应用程序
• 指定您的可执行文件应使用少于所有内核的内核（例如，8内核框上的+RTS -N6或+RTS -N7）
• 禁用并行垃圾收集（使用+RTS -qg）。我通常通过留下一个自由的核心比禁用并行收集器有更好的结果，但YMMV

I/O

如果您正在进行基准测试的函数正在进行任何类型的I/O（磁盘、网络等），那么在解释结果时需要非常小心。磁盘I/O可能会导致性能的巨大差异。如果对100个样本运行相同的函数，则在第一次运行后，控制器可能会缓存任何I/O。或者，如果在两次运行之间访问了另一个文件，您可能需要进行头部查找。其他I/O通常也不会更好。

如何诊断

• 您可能已经知道您的函数是否正在执行I/O
• 像lsof这样的工具可以帮助追踪神秘的I/O性能

如何修复

• 模拟I/O。创建一个ramdisk。除了实际进入硬盘驱动器之外的任何东西
• 如果您真的必须对实际的I/O操作进行基准测试，请尽量减少来自其他应用程序的干扰。也许使用专用驱动器。关闭其他应用程序。一定要收集多个样本，并注意它们之间的差异

Answer 2

在Linux>2.6上，有一个名为"cpusets"的方便功能，可以用来为某些进程保留CPU核心。当然，这只能帮助减少共享CPU使用量的差异，但我发现它在这方面非常有效。

以下是我当前的工作流程（需要cpuset包）：

$ # Reserve virtual cores 0 and 1, corresponding to a full physical CPU core
$ sudo cset shield -k on -c 0-1
$ # Run benchmarks with my usual user
$ sudo cset shield --user=$USER -e -- stack bench 
$ # Release the CPU cores
$ sudo cset shield --reset

以下是cset命令的教程。