我正在使用 Valgrind + Callgrind 来分析我编写的求解器。正如 Valgrind 用户手册所述，我使用编译器的调试选项编译了我的代码：
“在没有调试信息的情况下，最好的 Valgrind 工具能够做的就是猜测一段特定代码属于哪个函数，这使得错误消息和分析输出几乎毫无用处。使用 -g，您将获得直接指向的消息相关的源代码行。”
使用调试选项编译时，代码运行速度要慢得多。CFD 代码变得非常慢，即使在使用调试标志编译的小情况下也是如此。Valgrind 使它慢了 40 倍（参见手册1）。
您使用什么工具进行代码分析（分析，而不是基准测试）？
你让代码运行多长时间（统计：多少时间步长）？
案例有多大（如果案例适合缓存，求解器的速度要快几个数量级，但我会错过与内存相关的进程）？
Q1：您使用什么工具进行代码分析（分析，而不是基准测试）？
Q2：你让代码运行多长时间（统计：多少时间步长）？
Q3：案例有多大（如果案例适合缓存，求解器会快几个数量级，但我会错过与内存相关的进程）？
我将基准测试（查看需要多长时间）与分析（确定如何使其更快）分开。分析器是否快速并不重要。重要的是它告诉您要修复什么。
我什至不喜欢“分析”这个词，因为它会让人联想到类似于直方图的图像，其中每个例程都有一个成本栏，或者“瓶颈”，因为它意味着代码中只有一个小地方需要固定的。这两件事都意味着某种时间和统计数据，您认为准确性很重要。为了时间的准确性而放弃洞察力是不值得的。
我使用的方法是随机暂停，这里有完整的案例研究和幻灯片放映。剖析器-瓶颈世界观的一部分是，如果你什么都没找到，就没有什么可找到的，如果你确实找到了一些东西并获得了一定的加速百分比，你就宣布胜利并退出。Profiler 的粉丝几乎从不说他们获得了多少加速，广告只显示人为设计的问题，旨在易于查找。随机暂停会发现问题，无论它们是简单的还是困难的。然后解决一个问题会暴露其他问题，因此可以重复该过程，以获得复合加速。
根据我从众多示例中获得的经验，它是这样进行的：我可以找到一个问题（通过随机暂停）并修复它，从而获得一定百分比的加速，比如 30% 或 1.3 倍。然后我可以再做一次，找到另一个问题并修复它，获得另一个加速，也许不到 30%，也许更多。然后我可以再做一次，多次，直到我真的找不到其他可以解决的问题。最终的加速因子是各个因子的运行乘积，在某些情况下它可以是惊人的大——数量级。
插入：只是为了说明最后一点。这里有一个详细的示例，带有幻灯片和所有文件，展示了如何在一系列问题消除中实现 730 倍的加速。第一个版本每个工作单位需要 2700 微秒。问题 A 被删除，将时间缩短到 1800，并将剩余问题的百分比放大 1.5 倍 (2700/1800)。然后B被删除。这个过程持续了六次迭代，导致几乎 3 个数量级的加速。但是剖析技术必须非常有效，因为如果没有发现任何这些问题，即如果您达到了错误地认为无能为力的地步，那么该过程就会停止。
插入：换句话说，这是一个总加速因子的图表，因为连续的问题被消除了：
因此，对于 Q1，基准测试一个简单的计时器就足够了。对于“分析”，我使用随机暂停。
Q2：我给它足够的工作量（或者只是在它周围放一个循环），让它运行足够长的时间来暂停。
Q3：无论如何，给它实际的大工作量，这样你就不会错过缓存问题。这些将在执行内存提取的代码中显示为示例。
穷人的探查器基本上是一个gdb对调用堆栈进行采样的脚本。您仍然需要有调试符号。它仍然很慢，但由于它没有实现在其上运行代码的虚拟机，因此通常比callgrind完成任务更快且足够。
我在粒子物理分析仪上取得了一定的成功（即我证明了代码没有任何可怕的热点，优化需要更好的算法）。
为了增加可用的出色答案，Rice 开发了一个工具，它可以自动进行堆栈采样，因此开销很小：
Allinea MAP是一种商业开发和支持的采样分析器，因此 - 就像早期答案中建议的 HPC Toolkit - 如果您愿意，可以在生产规模的作业上运行。
这种工具指向 CPU 瓶颈或较差的 MPI 通信，而且对分析整个工作的整个疏忽在发现意外问题时可能是无价的。
在 CFD 代码的核心内核之外，在意料之外的领域中，通常会有一些低垂的性能成果。随机堆栈采样 - 无论是使用 GDB 手动完成，还是使用 HPC Toolkit 和 Allinea MAP 等工具 - 都是找到它们的最佳方式。如果某些东西对性能很重要，它就会出现。