按活动类型分析程序答案

【问题标题】：Profiling program by type of activity按活动类型分析程序
【发布时间】：2011-06-23 16:27:33
【问题描述】：

典型分析器的输出是代码中的函数列表，按程序运行时每个函数所用的时间排序。

这很好，但有时我更感兴趣的是程序大部分时间在做什么，而不是EIP 大部分时间在哪里。

我假设的分析器的一个示例输出是：

Waiting for file IO - 19% of execution time.
Waiting for network -  4% of execution time
Cache misses        - 70% of execution time.
Actual computation  -  7% of execution time.

有这样的分析器吗？是否可以从“标准”分析器得出这样的输出？

我正在使用 Linux，但我很高兴听到其他系统的任何解决方案。

【问题讨论】：

是否有工具可以获取分析器数据并将其放入此表单中？
你想在什么操作系统上运行它？ Solaris 和 Mac OS X 似乎有这样的工具。
感谢您选择了加起来为 100% 的示例百分比 :-)

标签： c++ c profiling

【解决方案1】：

这仅适用于 Solaris，但 dtrace 可以监控几乎所有类型的 I/O、开/关 CPU、特定功能的时间、睡眠时间等。我不确定它是否可以确定缓存未命中，假设你意思是 CPU 缓存 - 我不确定 CPU 是否提供了该信息。

【讨论】：

Mac OS X 的 Instruments 也可以做到这一点——我认为它甚至可以建立在 DTrace 之上。

【解决方案2】：

请看at this和this。

考虑任何线程。在任何时刻，它都在做某事，而且它是有原因的，而缓慢可以定义为它出于不良原因而花费的时间——它不需要花费那个时间。

在某个时间点对线程进行快照。可能是缓存未命中、指令中、语句中、函数中、从另一个函数中的调用指令调用、从另一个函数中调用，等等，直到call _main。这些步骤中的每一个都有一个原因，对代码的检查就会发现。

如果这些步骤中的任何一个都不是一个很好的理由并且可以避免，那么不需要花费那个时间。

也许在那个时候磁盘正在绕到某个扇区，所以可以启动一些数据流，所以可以填充缓冲区，因此可以在函数中满足读取语句，并且该函数从在另一个函数中调用站点，从另一个函数调用站点，依此类推，直到 call _main，或者任何恰好是线程顶部的东西。

重复上一点 1。

因此，找到瓶颈的方法是找出代码何时因为糟糕的原因而花费时间，而找到它的最佳方法是对其状态进行快照。 EIP，或任何其他微小的状态，不会这样做，因为它不会告诉你为什么。

很少有分析器“明白”。这样做的是挂钟时间堆栈采样器，它按代码行（而不是按功能）报告活动时间百分比（不是时间量，尤其是不是“自我”或“独占” " time.) 一个是Zoom，还有其他的。

查看 EIP 在哪里闲逛就像试图用秒针在时钟上显示时间。测量函数就像试图在时钟上显示一些数字丢失的时间。只在 CPU 时间而不是在阻塞时间进行分析，就像试图在一个随机停止运行很长时间的时钟上判断时间一样。关注测量精度就像试图将您的午餐时间精确到秒。

这不是一个神秘的话题。

【讨论】：

您介绍了经典的统计抽样方法，并注意通过随机均匀抽样可以获得更准确的结果，这比仅在调用函数时抽样要好，如gprof是正在做。附带说明一下，我不确定在这种情况下均匀采样是否会带来这样的优势，因为无论如何您都在进行过采样，因此在每个函数调用中采样就绰绰有余了。当然，你会得到更糟糕的结果——但你的分析器会更简单，也许这是值得的。但我不明白的是，这如何回答我的问题？
@Elazar：我相信一个问题的有效答案是质疑前提（从法律上讲:-)。前提是为了了解程序大部分时间在做什么，某些特定的输出是有帮助的，这就是我所质疑的。就方法而言，没有经典的方法。调用方法时的采样不是采样。（它被称为检测。）采样必须与程序状态不相关，因为如果它是相关的，那么它很容易遗漏大问题（例如遗漏所有 IO，正如您在 gprof 和 VS 分析器中看到的那样）。随机抽样堆栈。
迈克，我的意思是统计中的抽样。您在某个时刻测量程序状态。 Instrumentation 只是一种以非统一方式对程序进行采样的方法，goo.gl/3mSJ0 是另一种非标准的采样方式。我的意思是，尽管插桩不是均匀采样，但它对您的程序进行了足够频繁的采样，这样您就可以有效地每隔 2 毫秒就有一个样本，因此它也足够有用。您将知道哪些代码块是您的有效采样率的瓶颈。均匀抽样比较好，但非均匀抽样也不是没用。
关于我的问题用例的问题。有时你想让一个程序运行得更快，但你没有它的源代码，或者你不想改变它。使用我所描述的输出，可以帮助您以更少的开发人员资源加快速度（该程序有 70% 的时间等待磁盘 IO？让我将相关文件移动到内存磁盘或 SSD。太多的缓存未命中？让我添加内存，或确保它单独运行等...）。看看 Mark 的博客 goo.gl/Zn569 ，他试图以与我的想法类似的方式对程序进行剖析，以便找到闭源程序中的瓶颈。
@Elazar：关于统计，我在分析器诞生之前就一直在做这个并思考它，最近我发现了一个我认为非常有用的概念，Rule of Succession。此外，我知道这是违反直觉的，但高采样频率，即使是在随机时间，也对发现问题没有实质性帮助。关于您的用例，您提出了一个很好的观点。没有源的情况我没有想到。