OpenMP如何实现对关键部分的访问？

Question

我想读取一个输入文件（在C / C ++中）并尽可能快地独立处理每一行。 处理本身需要几个滴答，所以我决定使用OpenMP线程。 我有这个代码：

#pragma omp parallel num_threads(num_threads)
{
  string line;
  while (true) {
#pragma omp critical(input)
    {
      getline(f, line);
    }
    if (f.eof())
      break;
    process_line(line);
  }
}

我的问题是，如何确定要使用的最佳线程数？ 理想情况下，我希望在运行时动态检测到这一点。 我不理解parallel的DYNAMIC计划选项，所以我不能说这是否有帮助。 任何见解？

另外，我不确定如何“手动”确定最佳数量。 我为我的具体应用尝试了各种数字。 我原本认为top报告的CPU使用率会有所帮助，但它不会（！）在我的情况下，CPU使用率始终保持在num_threads *（85-95）左右。 然而，使用pv来观察我正在读取输入的速度，我注意到最佳数字是2-5左右; 在此之上，输入速度变小。 所以我的问题是 - 为什么我在使用10个线程时会看到CPU使用率为850？ 这可能是由于OpenMP如何处理线程等待进入关键部分的效率低下？

编辑：这是一些时间。 我用它获得了它们：

for NCPU in $(seq 1 20) ; do echo "NCPU=$NCPU" ; { pv -f -a my_input.gz | pigz -d -p 20 | { { sleep 60 ; PID=$(ps gx -o pid,comm | grep my_prog | sed "s/^ *//" | cut -d " " -f 1) ; USAGE=$(ps h -o "%cpu" $PID) ; kill -9 $PID ; sleep 1 ; echo "usage: $USAGE" >&2 ; } & cat ; } | ./my_prog -N $NCPU >/dev/null 2>/dev/null ; sleep 2 ; } 2>&1 | grep -v Killed ; done

NCPU = 1 [8.27MB / s]用法：98.4

NCPU = 2 [12.5MB / s]用法：196

NCPU = 3 [18.4MB / s]用法：294

NCPU = 4 [23.6MB / s]用法：393

NCPU = 5 [28.9MB / s]用法：491

NCPU = 6 [33.7MB / s]用法：589

NCPU = 7 [37.4MB / s]用法：688

NCPU = 8 [40.3MB / s]用法：785

NCPU = 9 [41.9MB / s]用法：884

NCPU = 10 [41.3MB / s]用法：979

NCPU = 11 [41.5MB / s]用法：1077

NCPU = 12 [42.5MB / s]用法：1176

NCPU = 13 [41.6MB / s]用法：1272

NCPU = 14 [42.6MB / s]用法：1370

NCPU = 15 [41.8MB / s]用法：1493

NCPU = 16 [40.7MB / s]用法：1593

NCPU = 17 [40.8MB / s]用法：1662

NCPU = 18 [39.3MB / s]用法：1763

NCPU = 19 [38.9MB / s]用法：1857

NCPU = 20 [37.7MB / s]用法：1957年

我的问题是我可以使用785 CPU使用率达到40MB / s，但也可以使用1662 CPU。 那些额外的周期在哪里？

EDIT2：感谢Lirik和John Dibling，我现在明白，我发现令人费解的时间的原因与I / O无关，而是与OpenMP实现关键部分的方式有关。 我的直觉是，如果你有一个CS内部的线程和10个等待进入的线程，那么第一个线程退出CS的那一刻，内核应该唤醒另一个线程并让它进入。时间建议不然：它可以是线程自己多次唤醒并发现CS占用了？ 这是线程库或内核的问题吗？

Answer 1

“我想读取一个输入文件（在C / C ++中），并尽可能快地独立处理每一行。”

从文件读取会使应用程序受I / O限制，因此单独读取部分所能达到的最大性能是以最大磁盘速度读取（在我的机器上读取的CPU时间小于10％）。 这意味着如果您能够完全释放任何处理中的读取线程，则需要处理的时间少于剩余的CPU时间（使用我的计算机时为90％）。 如果线路处理线程占用的时间超过剩余的CPU时间，那么您将无法跟上硬盘驱动器的步伐。

在这种情况下有几种选择：

1. 排队输入并让处理线程出列“工作”，直到它们赶上所呈现的输入（假设你有足够的RAM来执行此操作）。
2. 打开足够的线程，只需最大化处理器，直到读取所有数据，这是您最好的工作方案。
3. 节流读取/处理，以便您不占用所有系统资源（如果您担心UI响应和/或用户体验）。

“...处理本身需要几个滴答，所以我决定使用OpenMP线程”

这是一个好兆头，但它也意味着您的CPU利用率不会很高。 正如约翰·迪布林所提到的，这是你可以优化你的表现的部分，最好是手工完成。 通常，最好是排队每一行并让处理线程从队列中提取处理请求，直到您无需处理任何其他内容。 后者也被称为生产者/消费者设计模式 - 并发计算中非常常见的模式。

更新

为什么会有区别

• （i）每个进程获取锁定，拉取数据，释放锁定，处理数据; 和
• （ii）一个过程：拉取数据，获取锁定，入列块，释放锁定，
• 其他：获取锁，出队块，释放锁，处理数据？

差别很小：在某种程度上，两者都代表了消费者/生产者模式。 在第一种情况下（i）您没有实际队列，但您可以将文件流视为您的生产者（队列），而Consumer是从流中读取的线程。 在第二种情况（ii）中，您明确地实现了消费者/生产者模式，这种模式更健壮，可重用并为生产者提供更好的抽象。 如果您决定使用多个“输入通道”，那么后一种情况会更好。

最后（也可能是最重要的），您可以使用一个单一生产者和一个消费者的无锁队列 ，这将使（ii）比（i）快得多，使您受到i / o约束。 使用无锁队列，您可以在不锁定的情况下 提取数据 ， 排队块和dequque块 。

Answer 2

您可以做的最好的事情就是通过手动，通过重复的测量 - 调整 - 比较周期自己进行调整。

用于处理数据集的最佳线程数高度依赖于许多因素，其中最重要的是：

1. 数据本身
2. 你用来处理它的算法
3. 线程正在运行的CPU
4. 操作系统

您可以尝试设计某种启发式方法来测量处理器的吞吐量并在运行中进行调整，但这种方式往往比它的价值更麻烦。

通常，对于I / O绑定的任务，我通常从每个核心大约12个线程开始并从那里调整。 对于CPU绑定的任务，我从每个核心大约4个线程开始，然后从那里开始。 如果您真的想要优化处理器使用，关键是“从那里开始”部分。

另外请记住，如果您真的想要进行优化，则应该可以配置此设置，因为部署它的每个系统都具有不同的特性。