【问题标题】:How to profile optimized c code lines如何分析优化的 c 代码行
【发布时间】:2016-08-01 13:02:46
【问题描述】:

为什么我不能逐行获取优化代码的分析数据?为什么我在排队?我知道有编译器优化,但每条装配线都有与之匹配的 c 源代码。我知道我可以对函数进行分析,但我想检查每行花费了多少时间。 我需要知道何时完成指令提取以及需要多少个周期,以及在何处完成数据提取以及(显然 - )加快代码速度。

【问题讨论】:

  • 如果一条指令或数据获取需要 X%(如 30%)的时间,每个随机暂停将以 X% 的概率落在它上面。例如,您可以使用 GDB 对优化代码执行此操作。然后,将其追溯到有罪的代码行。 (注意这不是测量周期,它是精确定位昂贵的指令。X% 越大,需要的样本越少。)如果你真的需要知道周期,试试 valgrind 或类似的东西。

标签: c profiling profiler


【解决方案1】:

虽然组装线确实有关于源线的信息,但/您的分析器不会将关于指令的信息合并回关于线的信息。

【讨论】:

    【解决方案2】:

    这将被否决,因为我不同意你的问题。 如果你这样做是因为你想加速代码,那么在已经被优化器打乱的代码中搜索速度问题是错误的。**

    有两种加速,可以修复(例如,太多的new,用相同的参数重复调用一个函数,点击DB然后扔掉结果、错误的算法、地下日志记录、过多的文件打开/关闭、不必要的锁定等),以及 编译器 可以修复的问题。 编译器无法解决你的速度问题,你做它做的事情也不容易。

    要找到可以修复的类型,请将它们视为要使用调试器找到的错误。 Here's a simple method that works. 它告诉您有关代码行的信息,以及更多信息。 使用 -O0 执行此操作,即关闭编译器的优化器。 如您所见,优化器不会让您更容易找到速度问题 - 反而会更难。

    当你找不到更多可以修复的加速器时,打开 -O3,让编译器发挥它的魔力。

    附:既然你喜欢数学,check here.

    ** 我知道很多人说相反,但这是课堂上的回声,来自可能非常聪明但在“战壕”方面经验不足的讲师。 这是基于一厢情愿的想法,即代码已经几乎是最优的。

    【讨论】:

      猜你喜欢
      • 2011-01-24
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多