我正在尝试使用高度异步通信模式优化 MPI 应用程序。每个等级都有一个要计算的事物列表，如果输入或输出位于不同的等级上，则根据需要发送消息。此外，每个 rank 都是线程化的（目前有一个通信线程和 5 个工作线程）。
我已经在代码的不同性能关键部分周围使用计时器对代码进行了检测，这为我提供了每个线程的 (start,end,type) 三元组列表。以明显的方式绘制，以时间作为水平轴，等级和线程作为垂直轴，颜色表示每个线程当前正在做什么，我得到这样的图像，具有 16 个等级，每个等级有 6 个线程：
我的问题是：可视化这些数据的其他方法可能有助于确定性能问题？在分析异步应用程序时，有没有人喜欢他们使用的绘图类型？
该数据集的局限性在于它不知道数据流结构，但我想在尝试收集更复杂的东西之前尽可能多地了解它。
未压缩的图像在这里，以防有人想四处看看（它无法通过正常路线上传）。不幸的是，即使我相信它是有效的，Firefox 也不接受它，可能是因为它太大了。
有时您可以通过高级资源分析获得有关性能问题的另一种观点：是否存在相关瓶颈，例如内存带宽？每个工作线程是否做相同数量的工作？可以使用来自 LIKWID 工具套件LIKWID Google 代码项目的 likwid-perfctr 轻松收集此数据。如果配置文件存在许多不同的热点，则可能需要您一一解决。也可能存在不同的问题，具体取决于使用了多少线程/进程。
我花了很多时间编写和调试并行代码，包括共享和/或分布式内存，但在不知道您的具体问题的情况下，我只能告诉您什么对我最有效。
如果您正在考虑计算效率，那么了解哪些例程需要多少时间是一件重要的事情，但是如果您担心并行效率，那么您应该更担心您的代码在不进行任何计算时正在做什么。有点像在太安静的时候担心孩子们在做什么……
由于您使用的是混合共享/分布式内存方法，我猜您的代码在空白处是等待 MPI 调用或互斥体/条件变量。您也可以将这些调用包装在计时器中，这将使您更好地了解是什么让您慢了下来，例如，如果它总是相同的条件或总是相同MPI_REDUCE的线程卡住。
我经常使用的一款软件是Intel Vtune Amplifier XE。它有一个很好的绘图功能/选项，可以可视化线程并发。该程序将绘制与您的非常相似的图，但是当线程等待互斥锁或条件变量时，它会在等待线程开始等待时绘制一条对角线，直到实际释放互斥锁或发出信号的线程在它被释放/发出信号时它正在等待的条件。这可能很混乱，但它会立即出现瓶颈。
最后，我还收集批量统计数据，例如对于每个互斥锁/信号/MPI 调用，平均和最大等待时间是多少？收集到的等待时间的直方图是什么？虽然该情节为您提供了一个很好的概述，但当涉及到细节时，它可能会变得非常混乱。
最后，一个不容小觑的问题：你如何收集你的时间安排？您的计时器是否足够无干扰，不会影响您的代码？我尽可能使用 CPU 指令计数，即RDTSC在 x86 架构上。这通常只是在您的代码中添加一条指令。
当我在由消息或事件控制的高度异步进程网络中遇到问题时，我会使用一种不容易但有效的方法。它涉及获取流程的时间戳日志，将它们合并到一个公共时间线中，并在某些消息触发活动时跟踪它们的进度，从而触发更多消息。我正在寻找的是收到消息和对其采取行动的时间之间的延迟，并了解延迟的原因。当发现问题时，将其修复，并重复该过程。这样，您可以获得真正令人满意的性能。
重要的是要了解这与您测量、测量、测量的方法有何不同。可以想象，唯一可以告诉你的是不该看的地方。真正的性能调优需要从时间的角度仔细查看细节。您要寻找的不是时间花在哪里，而是花在不必要的地方。
祝你好运。
