优化 libc 中“问题”所在的代码答案

【问题标题】：Optimizing code where "problems" are in libc优化 libc 中“问题”所在的代码
【发布时间】：2014-03-26 22:15:19
【问题描述】：

我有一个 C++ 代码，我正在使用英特尔的 VTune，我运行了 General Exploration analysis，但不知道如何解释结果。它将Retire Stalls 的数量标记为问题。

就其本身而言，这足以让我感到困惑，因为我可能已经不知所措了。但是它列出的具有异常数量的退休摊位的函数是_int_malloc 和malloc_consolidate，两者都在libc 中。因此，这甚至不是我可以查看自己的代码并试图弄清楚的事情，也不是我真正可以开始改变的事情。

有没有办法使用这些信息来改进我自己的代码？或者这真的只是意味着我应该找到减少或减少分配频率的方法吗？

（注意：手头的特定代码不是问题，我正在寻找策略来解释数据并在热点或停顿或任何“问题”可能出现在我无法控制的代码中时进行改进)

【问题讨论】：

内存很慢，一个高速缓存未命中很容易在处理器停止的情况下花费多达 200 个 cpu 周期。你对此无能为力。
说明这些函数中有很多Retire Stalls，但就整体性能而言，它可能不是真正的热点。我建议您进行高级热点分析并按 CPU_CLK_UNHALTED 计数器排序，这将显示您在每个函数中花费了多少周期。
我一般会换成“Hardware Event Sample Count”的观点来分析热点。
@Elalfer 按 CPU_CLK_UNHALTED 排序将这两个相同的函数显示为最高计数。分别为 1.632 亿次、1.404 亿次。第三高的是我自己的代码中的一个函数，计数为 9000 万
@tpg2114 你确定你在看@“样本计数”吗？您应该收集足够的样本（运行工作负载至少几秒钟）来估计您在每个函数中花费了多少时间。如果 malloc 是一个真正的热点，您可能希望重组代码以减少内存分配/对象创建。

【解决方案1】：

有没有办法使用这些信息来改进我自己的代码？或者确实这实际上只是意味着我应该找到分配更少或更少的方法经常？

是的，听起来您应该在您的代码中进行更改，以减少调用 malloc 的频率。

根据您的应用程序，内存分配可能很昂贵。我曾经通过从紧密循环中删除内存分配使程序快 20 倍。该应用程序在 Linux 上并没有那么慢，但在 Windows 上却是一场灾难。经过我的修改，在 Windows 上也可以了。

【讨论】：

【解决方案2】：

【讨论】：