c++ - start_thread 克隆在并行程序中占用了大部分时间 - 并行化错误或报告错误？

Question

我目前正致力于并行化 C++ 程序，以提高其在多核系统上的性能。使用 OpenMP 并考虑到挑战(线程同步、数据访问等)，我们终于找到了一种使整个程序并行化的方法，但性能提升并不明显。

使用英特尔 VTune Amplifier，我进行了热点搜索，发现在几乎每个应该并行完成的函数调用中，libgomp.so 中的“start_thread clone”比函数的实际执行花费的时间更多:

Intel VTune Result Image

这真的出乎意料，因为我检查过，在当前的 OpenMP 实现中，从并行和串行区域切换几乎没有惩罚。根据this discussion :

The thread are started when your program starts ( or the first time are needed, depending on the implementation ). Pause your program anywhere else, and you'll notice the threads are still there

我这样做了，在调试器中停止了程序，在第一个并行区域之前只有一个线程，之后，无论我在哪里停止(并行或串行区域)，都有多个线程。所以我确信每次“重新生成”新线程应该不会产生开销。

现在，据我对测量的理解，VTune 告诉我不同​​的说法。有人可以帮我吗？

Answer 1

请为包含此库的调试符号的 libgomp 下载相应的调试包 - VTune 将能够更好地对 CPU 时间进行分类。热点中存在 libgomp 可能是由自旋锁导致的不良工作拆分造成的。

另请注意，屏幕截图上的时间并不意味着“start_thread clone”花费了 11 秒 - 它意味着从 start_thread 到 calcGrowthStep 区域调用热点(未解析的函数)花费了 11 秒。