需要分析帮助
我有一个分析问题 - 假设我有以下代码...
void main()
{
well_written_function();
badly_written_function();
}
void well_written_function()
{
for (a small number)
{
highly_optimised_subroutine();
}
}
void badly_written_function()
{
for (a wastefully and unnecessarily large number)
{
highly_optimised_subroutine();
}
}
void highly_optimised_subroutine()
{
// lots of code
}
如果我在 vtune (或其他分析器)下运行它,则很难发现有什么问题。所有热点都将出现在已优化的标记为“//大量代码”的部分中。 badly_writing_function() 不会以任何方式突出显示,即使它是所有问题的原因。
vtune 是否有某些功能可以帮助我找到问题?
是否有某种模式可以让我找到 badly_writing_function() 及其所有子函数所花费的时间?
I have a profiling issue - imagine I have the following code...
void main()
{
well_written_function();
badly_written_function();
}
void well_written_function()
{
for (a small number)
{
highly_optimised_subroutine();
}
}
void badly_written_function()
{
for (a wastefully and unnecessarily large number)
{
highly_optimised_subroutine();
}
}
void highly_optimised_subroutine()
{
// lots of code
}
If I run this under vtune (or other profilers) it is very hard to spot that anything is wrong. All the hotspots will appear in the section marked "// lots of code" which is already optimised. The badly_written_function() will not be highlighted in any way even though it is the cause of all the trouble.
Is there some feature of vtune that will help me find the problem?
Is there some sort of mode whereby I can find the time taken by badly_written_function() and all of its sub-functions?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
这通常称为“调用图配置文件”,我相当确定 Visual Studio 会这样做。
That's usually known as a "callgraph profile", and I'm fairly sure Visual Studio will do that.
推出您自己的非常简单分析器并不难。插入 main():
其中:
现在不可否认的是,在您的简单示例中使用此 profileCpuUsage() 并没有增加太多好处。它的缺点是要求您通过在合适的位置调用 profileCpuUsage() 来手动检测代码。
但优点包括:
一件棘手的不可移植的事情是定义函数 realElapsedTime() ,以便它提供足够的粒度来获取有效时间。这通常对我有用(在 CYGWIN 下使用 Windows API):
对于纯 Unix,有一个共同点:
realElapsedTime() 给出挂钟时间,而不是进程时间,这通常是我想要的。
还有其他不太便携的方法可以使用 RDTSC 实现更细的粒度;例如,参见 http://en.wikipedia.org/wiki/Time_Stamp_Counter 及其链接,但我还没有尝试过这些。
编辑: ravenspoint 的非常好的答案似乎与我的没有太大不同。 而且他的答案使用了漂亮的描述性字符串,而不仅仅是丑陋的数字,这让我经常感到沮丧。但这只需大约十几行就可以解决(但这几乎使行数翻倍!)。
请注意,我们希望避免使用 malloc(),而且我什至对 strcmp() 有点怀疑。所以切片的数量永远不会增加。哈希冲突只是被标记,而不是被解决:人工分析器可以通过手动将切片数量从 30 增加或通过更改描述来解决此问题。 未经测试
另一点是,通常您会希望针对发布版本禁用此分析;这也适用于 ravenspoint 的答案。这可以通过使用邪恶宏来定义它的技巧来完成:
如果这样做,您当然需要在定义中添加括号以禁用禁用宏:
Rolling your own very simple profiler is not that hard. Insert into main():
where:
Now admittedly in your simple example using this profileCpuUsage() doesn't add much benefit. And it has disadvantage of requiring you to manually instrument your code by calling profileCpuUsage() at suitable locations.
But advantages include:
One tricky non-portable thing is to define the function realElapsedTime() so that it provides enough granularity to get valid times. This generally works for me (using the Windows API under CYGWIN):
For straight Unix there is the common:
realElapsedTime() gives wall-clock time, not process time, which is usually what I want.
There are also other less-portable methods to achieve finer granularity using RDTSC; see for example http://en.wikipedia.org/wiki/Time_Stamp_Counter, and its links, but I haven't tried these.
Edit: ravenspoint's very nice answer seems to be not too dissimilar from mine. And his answer uses nice descriptive strings, rather than just ugly numbers, which I was often frustrated with. But this can be fixed with only about a dozen extra lines (but this almost doubles the line count!).
Note that we want to avoid any usage of malloc(), and I'm even a bit dubious about strcmp(). So the number of slices is never increased. And hash collisions are simply flagged it rather being resolved: the human profiler can fix this by manually bumping up the number of slices from 30, or by changing the description. Untested
And another point is that typically you'll want to disable this profiling for release versions; this also applies to ravenspoint's answer. This can be done by the trick of using an evil macro to define it away:
If this is done, you will of course need to add parentheses to the definition to disable the disabling macro:
我可以推荐我自己的开源分析器 raven::set::cRunWatch 吗?它正是针对这个问题而设计的,并且可以在使用 Visual Studio 2008 标准版的 Windows 上运行,因此您无需为包含探查器的版本付费。
我已经拿走了你的代码,稍微重新排列了它,这样它就可以在没有前向声明的情况下进行编译,并添加了对 cRunWatch 的必要调用,
当运行时会产生输出
这表明 badly_writing_function 是非常接近的第二次用户,因此是罪魁祸首。
您可以从此处获取cRunWatch 您将在用户指南中识别示例代码:-)
May I suggest my own open source profiler raven::set::cRunWatch? It is designed for exactly this problem and works on Windows using Visual Studio 2008 Standard Edition, so you do not need to pay for the version that has the profiler included.
I have taken your code, rearranged it slightly so it compiles without forward declarations and added the necessary calls to cRunWatch
When run this produces the output
This shows badly_written_function to be the very close second time user, and therefore the culprit.
You can obtain cRunWatch from here You will recognize the sample code in the User Guide :-)
一般来说,您希望观察函数的总时间而不是自身时间,以确保您查看的时间包括被调用函数的时间。
在 VTune 中,我建议使用自顶向下选项卡。或者,更好的是,如果您使用的是最新更新,请尝试新的实验性主叫方-被叫方视图。您可以在此处获取有关此内容的详细信息 - http://software.intel.com/en -us/forums/topic/376210。它获得函数及其总时间的平面列表,以便您可以查看程序中最耗时的子树。
Generally, this is something where you want to observe function's total time as opposed to self time, to make sure that you are looking at the time which includes the time of the called functions.
In VTune, I would recommend using Top-down tab for that. Or, even better and if you are using a latest update, try out the new experimental Caller-Callee view. You can get details on this here - http://software.intel.com/en-us/forums/topic/376210. It gets a flat list of functions with their total times so that you can view what are the top time-consuming subtrees in your program.