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

时间：2012-07-29 19:26:58

标签： haskell benchmarking criterion

我尝试优化某些代码，使用标准尝试比较，例如，将INLINE pragma添加到函数中的效果。但是我发现重新编译/运行之间的结果并不一致。

我需要知道如何让结果在运行中保持一致，以便我可以比较它们，或者如何评估基准是否可靠，即（我猜）如何解释有关方差的详细信息，＆ ＃34;时钟通话费用＆＃34;等等。

我的具体案例详情

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

  1. 我尝试使用IO对whnfIO行为进行基准测试，因为在this example中使用whnf的方法无效。

  2. 我的代码使用并发

  3. 我有很多标签和废话

    4. 示例输出

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

    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

    我注意到，如果我按照＆＃34;估计的时钟通话费用进行扩展＆＃34;两个基准相当接近。这是我应该做些什么来获得一个真实的数字进行比较？

2 个答案:

答案 0 :(得分：13)

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

解释标准结果

标识为异常值的样本的问题在于，标准无法确定它们是否是异常值，因为它们是垃圾数据，或者它们是由于某些正当理由而有效的有效数据。它可以强烈暗示它们是垃圾（“差异严重膨胀”线），但这实际意味着您需要调查测试环境，测试或应用程序本身以确定异常值的来源。在这种情况下，它几乎肯定是由系统负载引起的（基于您提供的其他信息）。

您可能有兴趣阅读BOS的announcement of criterion，它解释了它的工作原理，并详细介绍了系统负载如何影响基准测试过程的一些示例。

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

如果您在同一系统上运行多个测试，则时钟时间和成本在运行之间应该相当一致。如果不是，则会影响时间，导致数据不可靠。

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

CPU负载

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

即使您没有垃圾收集器的问题，来自其他应用程序的高CPU负载也会使您的结果出现偏差，如果可能的话应该将其消除。

如何诊断

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

-RTS -s output 

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操作进行基准测试，请尽量减少来自其他应用程也许使用专用驱动器。关闭其他应用。绝对收集多个样本，并注意它们之间的差异。

答案 1 :(得分：4)

在Linux上＆gt; 2.6这里有一个方便的功能叫做＆＃34; cpusets＆＃34;可用于为某些进程保留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

Here是cset命令的教程。

相关问题
最新问题