【问题标题】:benchmark a piece of code independent of CPU performance?对独立于 CPU 性能的一段代码进行基准测试?
【发布时间】:2010-11-12 17:17:07
【问题描述】:

我的目标是:我想测试一段代码(或函数)的性能,就像我在单元测试中测试该函数的正确性一样,假设输出这个标杆过程是一个“功能性能指标”,是“便携”的

我的问题是:我们通常通过使用计时器来计算代码执行期间经过的时间来对代码进行基准测试。并且该方法取决于硬件或O / S或其他东西。

我的问题是:有没有一种方法可以获得独立于主机(CPU/OS/等)性能的“功能性能指数”,或者如果不是“独立的” " 可以说它与某个固定值“相对”。这样“功能性能指标”的值在任何平台或硬件性能上仍然有效。

例如:FPI 值可以在

  • 执行单个调用所需的算术指令数
  • 与基准函数相比的浮点值,例如函数 B 的评分指数为 1.345(即性能比基准函数慢 1.345 倍)
  • 或其他值。

注意,FPI 值不需要在科学上正确、准确或准确,我只需要一个值来粗略概述该功能与其他功能相比的性能用同样的方法测试过。

【问题讨论】:

  • 如果你想知道在哪里优化代码,独立于CPU,你应该look here。

标签: c++ benchmarking performance measurement


【解决方案1】:

我认为您在这里寻找不可能的东西,因为现代计算机的性能是 CPU、缓存、内存控制器、内存等的复杂组合。

因此,一个(假设的)计算机系统可能会奖励使用巨大的查找表来简化算法,从而处理的 CPU 指令非常少。而另一个系统的内存相对于 CPU 内核可能要慢得多,因此会优先考虑执行大量处理但占用很少内存的算法。

因此,这两种算法的单一“品质因数”甚至无法传达在所有系统中哪个更好,更不用说更好了。

【讨论】:

  • 让我们采用在O(n) 中执行的算法A 和在O(n^2) 中执行的B,但在执行B 时不知何故使用更少的内存、更少的缓存未命中或其他导致特定平台的东西B 的表现优于 A。但我们大多期望 A 的表现优于 B(这在实施中并不总是正确的)。与n^2 相比,我们仍然有n 的比较值。这个值帮助用户(使用该功能的人)选择他应该使用哪一个。这是我想要的值,它并不总是正确的,为了准确无误,他应该对其进行基准测试。
  • 嗯,我想我明白你在说什么,但是 O(f(n)) 实际上总是 kf(n),如果你在两个完全不同的平台上比较相同的任务,'k' 的两个值可能比'n' 的两个值更易变。我不认为有一个广泛应用的系统比 big-O 更好,即使是 big-O 对它要求裁决的许多事情也不是很好。如果你想要一个数字,你可以说 O(1)= 0, O(n)=1, O(logn)=2, O(nlogn)=3 等等。
【解决方案2】:

您真正需要的可能是一个类似 tcov 的工具。

man tcov 说:

每个基本代码块(或每个 如果指定了 tcov 的 -a 选项,则行)以 执行的次数;有的线 未执行的以“#####”为前缀。一个基本块 是没有分支的连续代码段:每个 基本块中的语句执行相同数量的 次。

【讨论】:

    【解决方案3】:

    不,没有这样的事情。不同的硬件性能不同。你可以有两段​​不同的代码 X 和 Y,这样硬件 A 运行 X 比 Y 快,但硬件 B 运行 Y 比 X 快。没有绝对的性能规模,它完全取决于硬件(更不用说其他事情了操作系统和其他环境因素)。

    【讨论】:

    • 是的,我知道没有绝对的比例,但我需要的只是一个粗略的比较值,不需要在任何平台上总是更正,就像测量 O() 值一样在算法效率测量中。
    【解决方案4】:

    听起来你想要的是一个计算一段代码的Big-O Notation 的程序。我不知道是否可以以自动化方式执行此操作(停止问题等)。

    【讨论】:

      【解决方案5】:

      就像其他人提到的那样,这不是一项微不足道的任务,并且可能无法从中获得任何准确的结果。考虑几种方法:

      1. 基准函数 -- 虽然这看起来很有希望,但当您尝试比较不同类型的函数时,我想您会发现它不会很好地工作。例如,如果您的基准函数是 100% CPU 绑定的(如在一些复杂的数学计算中),那么它将与其他 CPU 绑定函数进行比较/扩展,但与 I/O 或内存绑定函数相比时会失败。仔细地将基准函数与一小组类似函数进行匹配可能会奏效,但很乏味/耗时。
      2. 指令数 -- 对于一个非常简单的处理器,可以计算每条指令的周期数并获得一个代码块将花费的总周期数的合理值,但使用当今的现代处理器绝非“简单”。借助分支预测和并行流水线,您不能只将指令周期相加并期望得到准确的结果。
      3. 手动计数 -- 这可能是您最好的选择,虽然它不是自动的,但它可能比其他方法更快地提供更好的结果。只需查看代码的 O() 顺序、函数读取/写入的内存量、输入/输出的文件字节数等……通过为每个函数/模块提供一些这样的统计信息,您应该能够粗略比较它们的复杂性。

      【讨论】:

        猜你喜欢
        • 2016-12-25
        • 2018-08-09
        • 1970-01-01
        • 2013-03-10
        • 1970-01-01
        • 1970-01-01
        • 2014-09-20
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多