【问题标题】:OpenMP debug newbie questionsOpenMP 调试新手问题
【发布时间】:2011-05-25 19:16:23
【问题描述】:

我开始学习 OpenMP,在集群中运行来自 https://computing.llnl.gov/tutorials/openMP/exercise.html 的示例(使用 gcc 4.3)。所有示例都可以正常工作,但我有一些问题:

  1. 我如何知道在哪些节点(或每个节点的核心)中“运行”了不同的线程?
  2. 以节点为例,发送和取回信息的平均传输时间是多少微秒或纳秒?
  3. 调试 OpenMP 程序的最佳工具是什么?
  4. 加速实际程序的最佳建议?

【问题讨论】:

    标签: c openmp


    【解决方案1】:
    1. 通常情况下,您的 OpenMP 程序不知道也不关心它在哪些内核上运行。如果您有一个可以在其日志文件中提供所需信息的作业管理系统。如果做不到这一点,您可能会在线程内插入对环境的调用并检查某个环境变量的值。什么叫什么以及如何做到这一点取决于平台,我将由您来解决。

    2. 我(或任何其他 SOer)到底应该怎么知道?对于有根据的猜测,您必须告诉我们更多有关您的硬件、操作系统、运行时系统等的信息。这个问题的最佳答案是您根据自己的测量结果确定的答案。我担心您也可能错误地认为信息是在计算机周围发送的——在共享内存编程中,变量通常留在一个地方(或者至少你应该考虑它们留在一个地方,现实可能要混乱得多但也无法辨别)并且没有发送或接收。

    3. 诸如TotalViewDDT 之类的并行调试器可能是最好的工具。我还没有使用过英特尔的调试器的并行功能,但它们看起来很有希望。我会把它留给资金比我少的程序员来推荐 FOSS 选项,但它们就在那里。

    4. i) 为您的问题选择最快的并行算法。这不一定是最快的并行串行算法。

      ii) 测试和测量。没有数据就无法优化,因此您必须分析程序并了解性能瓶颈在哪里。不要相信任何“X 比 Y 快”的建议。此类陈述通常基于非常狭窄且通常已过时的案例,并且在其倡导者的心目中已成为“真理”。几乎总是可以找到反例。这是您想要更快地编写的代码,没有什么可以替代您的调查。

      iii) 彻底了解您的编译器。您花在调整编译选项上的时间回报率(以代码速度改进衡量)远高于“手动”修改代码的回报率。

      iv) 我坚持的“真理”之一是编译器在优化当前处理器架构上的内存层次结构方面并不是非常擅长。这是一个很值得修改代码的领域,但在分析代码之前您不会知道这一点。

    【讨论】:

    • +1;对于调试器,我将补充说 gdb(和 idb)具有非常可靠的线程支持,并且对于您通常谈论的 OpenMP 程序(比如〜8)的各种核心数量,它通常是您所需要的,也许与ddt 或 eclipse 驱动它以获得不错的 GUI 功能。
    【解决方案2】:
    1. 你不知道,不同内核上的线程分区完全由操作系统处理。您谈论的是节点,但 OpenMP 是一种多线程(而不是多进程)并行化,它允许对包含多个内核的一台机器进行并行化。如果您需要跨不同机器进行并行化,则必须使用像 OpenMPI 这样的多进程系统。

    2. 通信时间的数量级为:

      • 在同一个 CPU 内的内核之间进行通信的情况下,可以认为是瞬时的
      • ~10 GB/s 用于跨主板的两个 CPU 之间的通信
      • ~100-1000 MB/s 用于节点之间的网络通信,具体取决于硬件

      所有理论速度都应在您的硬件规格中指定。您还应该做一些小基准测试,以了解您将真正拥有什么。

    3. 对于 OpenMP,gdb 可以很好地完成工作,即使有很多线程。

    4. 我在超级计算机上从事极限物理模拟工作,以下是我们的日常目标:
      • 在线程/进程之间使用尽可能少的通信,99% 的时间是通信会破坏并行作业的性能
      • 优化分配任务,机器负载应尽可能接近 100%
      • 测试,调整,重新测试,重新调整......并行化根本不是一个通用的“奇迹解决方案”,它通常需要一些实际工作才能高效。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2010-09-23
      • 1970-01-01
      • 2010-10-27
      • 2012-07-16
      • 2010-12-08
      • 2011-08-13
      • 2010-12-20
      • 2010-11-05
      相关资源
      最近更新 更多