如何获得一致的标准基准,或跨运行解释结果？

Question

我正在尝试优化一些代码,使用标准来尝试比较,例如,将INLINEpragma 添加到函数的效果.但我发现重新编译/运行之间的结果并不一致.

我需要知道如何使结果在运行中保持一致,以便我可以比较它们,或者如何评估基准是否可靠,即(我猜)如何解释方差的细节,"成本时钟呼叫"等

我的具体案例详情

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

1. 我正在尝试使用基准测试IO操作,whnfIO因为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 -s输出

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

非零值表示垃圾收集器中的资源争用.这里的大数值表明存在严重问题.

怎么修

• 关闭其他应用程序
• 指定您的可执行文件应使用少于所有核心(例如,+RTS -N6或+RTS -N7在8核盒子上)
• 禁用并行垃圾收集(带+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。