c++ - 可视化每个线程正在运行的功能的工具

Question

我正在尝试调试多线程C++应用程序的性能问题。基本上，我的多线程程序(10个线程)比单线程程序慢。

我一直在尝试诸如valgrind(callgrind)，gprof和gdb之类的工具。但是到目前为止，我仍无法弄清楚线程在何处被阻塞以及原因。 gprof和callgrind给了我大量的时间在每个功能上。但是，这段时间是否包括线程阻塞某物的时间？是否有任何可用于调试此问题的开源工具。

Answer 1

即使我没有立即可用的答案，我也会在这里从注释中切换，因为还有更多的空间可以编写和格式化。

您能否澄清“lahks”一词？我仅找到something loosely related on Wiki，但纯粹是猜测，我不知道您的意思。

您说的large number of objects per thread。当您随机采样/停止时，您是否看过堆栈跟踪？我知道alloc/dealloc是堆栈跟踪中最常出现的叶子，但是* nonleaf * s呢？您是否能够看到实际上在调用那个alloc/dealloc的内容？这就是采样方法的重点-查看调用的原始信息，并从统计角度估计哪些可能的起源是造成调用频率太高的原因。

由于繁重的优化或由于体系结构不匹配，您可能无法观察到堆栈跟踪的“较高部分”(即，如果您的应用程序使用任务排队，那么在大多数情况下，您只会看到“提取任务”，”检查任务”，“执行任务”步骤而不是真正的来源)，但是几乎在每种体系结构中，您都可以进行适当调整(就任务排队而言，只需尝试采样任务注册即可!)

另一种方式-alloc/dealloc膨胀非常普遍:它通常与体系结构和算法有关，或者与bug有关。但是，这种情况不仅应该在“优化发行版”构建中很容易观察到(在查看堆栈跟踪时存在问题)，而且还应该在“完整调试信息”构建中迅速出现-较少的优化整个系统将运行速度较慢，但​​是您应该能够查看和收集所有可能的起源的中间方法。

另一件事:您已经说过“多线程”的工作要比“单线程”慢得多。这就对提出了一个问题，您如何在之间进行切换？您是否有两个单独的实现？还是只在1个workerthread和N个workerthread之间调整线程池大小？将其与“分配/解除分配”问题交叉使用-也许您的每个线程每次都需要执行太多的设置/拆卸操作？

尝试检查实际的线程(作为一个组，也要查看线程的生命周期)必须重复准备，而与单线程选项形成对比。

例如，单线程以某种方式节省了分配/取消分配并可能重用了某些结构)，而N线程可能需要N倍的相同结构。如果线程只是反复启动/停止并且不被重用，那么它们的N *数据也可能不会被重用，因此N线程可能只是在实际工作之前浪费时间进行准备。

另外，如果您设法捕获了无关的分配方案-为什么不进一步追踪:停止后，退出分配器并尝试查看正在分配的内容。我的意思是，您可以逐步检查该内存中正在写入的内容，这可以使您进一步了解实际发生的情况。但是，这可能是一项非常艰巨的任务，尤其是因为它必须重复很多次。我将其保留为最后的手段。

另一件事是-纯粹的猜测-您的平台可能在alloc/dealloc内部具有一些全局锁定，以“安全地跟踪”内存管理。这样，如果所有线程根据需要管理自己的内存，则线程将在每个内存分配/取消分配操作中互相等待。更改内存分配方案，或使用其他内存管理器，或使用堆栈或TLS，或将线程池拆分为单独的进程可能会有所帮助，因为它将避免全局锁定的需要。但是，这只是一个非常遥远的猜测，没有一种解决方案易于应用。

我为这样笼统而含糊的谈话感到抱歉。仅提供您的一些细节，很难说更多。我故意回避“使工作可视化的工具”主题。如果仅通过sample/stop方法无法看到正在发生的事情，那么所有可能的“线程可视化”工具都可能无济于事:它们可能会向您显示与现在所见完全相同的东西，因为它们都可以进行分析相同的堆栈跟踪，仅比手动停止快一点。