可视化事件数据以搜索性能问题的方式


10

我正在尝试使用高度异步的通信模式来优化MPI应用程序。每个等级都有要计算的事物的列表,如果输入或输出位于不同等级上,则根据需要发送消息。此外,每个级别都有线程(当前有一个通信线程和5个工作线程)。

我在代码的不同性能关键部分使用计时器来检测代码,这为我提供了每个线程的(开始,结束,类型)三元组列表。以明显的方式绘制,将时间作为水平轴,将等级和线程作为垂直,并用颜色表示每个线程当前正在执行的操作,我得到了这样的图像,其中有16个等级的线程,每个线程有6个线程:

五角大楼的排名和历史

我的问题是:还有什么其他可视化此数据的方式可以帮助解决性能问题?在对异步应用程序进行性能分析时,是否有人喜欢使用他们喜欢的绘图类型?

该数据集的局限性在于它不知道数据流的结构,但是在尝试收集更复杂的数据之前,我想从中获得尽可能多的洞察力。

如果有人要环顾四周(未通过正常路线上传),则此处为未压缩的图像。不幸的是,即使我相信它是有效的,Firefox也不会接受它,可能是因为它太大了。


我在使用浏览器或几乎任何其他程序加载大图像时遇到了很多麻烦。最后,gimp完成了此操作,但您可能需要重新考虑大小或文件格式选项。
2012年

对于那个很抱歉。我认为该图片是有效的,因为Firefox给了我相同的错误,它们通过convert(ImageMagick)运行。可能超过了任意大小的阈值。
Geoffrey Irving 2012年

Answers:


4

我花费大量时间编写和调试具有共享和/或分布式内存的并行代码,但是在不了解您的特定问题的情况下,我只能告诉您哪种方法最适合我。

如果您正在查看计算效率,那么知道哪些例程花费多少时间是很重要的,但是如果您担心并行效率,那么您应该更担心代码在执行任何计算时在做什么。有点像担心孩子在安静的时候在做什么...

由于您使用的是混合共享/分布式内存方法,因此我想您的代码总是处于等待MPI调用或互斥/条件变量的状态。您也可以将这些调用包装在计时器中,这将使您更好地了解正在减慢的速度,例如,如果MPI_REDUCE线程始终处于相同的条件或相同的状态,

我经常使用的一款软件是Intel Vtune Amplifier XE。它具有很好的绘图功能/选项,可以可视化线程并发。该程序将绘制与您的图非常相似的图,但是当线程等待互斥量或条件变量时,它会从等待线程(开始等待时)到实际释放互斥量或发出信号的线程绘制一条对角线释放/发出信号时的等待条件。这可能会很混乱,但是会使瓶颈立即出现。

最后,我还收集了批量统计信息,例如,对于每个互斥锁/信号/ MPI呼叫,平均和最大等待时间是多少?收集的等待时间的直方图是什么?虽然该图为您提供了不错的概览,但是当涉及到精细的细节时,它可能会变得非常混乱。

最后,一个不容小under的问题:您如何收集时间?您的计时器是否具有非侵入性,足以不影响您的代码?我尽可能RDTSC在x86体系结构上使用CPU指令计数。这通常只向您的代码添加一条指令。


数据在所有等待中都已经有块。在该图中,空闲工作线程显示为白色,等待通信线程显示为黄色。不幸的是,由于异步,通信线程中的所有等待都发生在单个MPI_Waitsome中。因为纯线程性能本质上是完美的,所以Vtune不适用于这种情况,但是要感谢指针。直方图建议也是一个很好的建议。
Geoffrey Irving 2012年

至于计时开销:我正在使用gettimeofday,这至少在空闲部分附近是必需的,因为在那里我使用了pthread条件变量。在这种情况下可以使CPU指令计数起作用吗?开销已经足够低了,但是一定会更好。
Geoffrey Irving 2012年

1
@GeoffreyIrving:是的,您可以使用它们,但是它们仅在constant_tsc设置了标志(检查/proc/cpuinfo)的CPU上有意义,并且如果您将每个线程锁定到特定的内核,即每个线程始终从同一内核读取相同的寄存器,例如使用pthread_setaffinity_np。请注意,后者特定于Linux,因此不可移植。
2012年

@GeoffreyIrving:即使您正在使用来等待一些未公开的事件MPI_Waitsome,您仍然可以记录实际到达的请求以及从何处到达的请求。该信息可能有用也可能不会有用...
Pedro 2012年

5

有时,您可以通过高级资源分析来获得有关性能问题的另一种观点:是否存在相关的瓶颈,例如内存带宽?每个工作线程都执行相同的工作量吗?可以使用likwid-perfctr从LIKWID工具套件LIKWID Google代码项目中轻松收集此数据。如果概要文件中存在许多不同的热点,则可能需要您一一解决。取决于使用多少线程/进程,也可能存在不同的问题。


为了完全公开,Georg参与了LIKWID项目,因此我征求了此回应,因为我想用另一种观点(以及一个免费的出色工具)来补充Pedro的出色回答。
阿隆·艾玛迪亚

2

当我在由消息或事件控制的高度异步进程的网络中遇到问题时,我使用的方法并不容易,但很有效。它涉及获取带有时间戳的流程日志,将它们合并到一个通用的时间轴中,并在某些消息触发活动时跟踪它们的进度,从而触发更多消息。我要寻找的是从收到消息到对消息采取行动之间的延迟,并了解延迟的原因。发现问题后,将其修复并重复该过程。这样,您可以获得真正令人满意的性能。

重要的是要看到这与您测量,测量和测量的方法有何不同。可以想象,唯一可以衡量的事情就是告诉您什么地方看。实际的性能调整需要从时间角度仔细查看细节。您所寻找的不是花费时间,而是不必要地花费时间。

祝好运。


换句话说,我所拥有的数据没有有用的可视化。:) Jed Brown建议使用Jumpshot(及相关的实用程序)作为收集和可视化您建议的数据的一种方法,因此我将对此进行研究。
杰弗里·欧文

@Geof:可视化带来好运。我会发现有用的唯一工具是收集和合并事件日志的工具,这样我就可以跟踪一个或多个请求的路径,因为它通过各个线程,因为这是我发现唯一发现不必要的方法延误。这就是任何性能问题都将包括的内容-不必要的延迟。
Mike Dunlavey 2012年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.