15

我正在尝试优化一些代码，使用标准来尝试比较，例如，将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

我注意到，如果我按“时钟呼叫的估计成本”进行缩放，这两个基准相当接近。这是我应该做的以获得一个实数进行比较吗？

4

2 回答 2

14

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

解释标准结果

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

您可能有兴趣阅读 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 会导致性能上的巨大差异。如果您对 100 个样本运行相同的函数，则在第一次运行后，控制器可能会缓存任何 I/O。或者，如果在运行之间访问了另一个文件，您可能必须进行头部搜索。其他 I/O 通常也好不到哪里去。

如何诊断

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

怎么修

  • 模拟 I/O。创建一个虚拟磁盘。除了实际进入硬盘驱动器等之外的任何东西。
  • 如果您确实必须对实际 I/O 操作进行基准测试，请尽量减少来自其他应用程序的干扰。也许使用专用驱动器。关闭其他应用程序。一定要采集多个样本，注意它们之间的差异。
于 2012-07-30T15:17:42.270 回答
4

在 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是命令的教程。

于 2017-02-21T22:31:21.647 回答