0

我观察到一种奇怪的行为，想知道它是否与 Intel Xeon Phi 有关。

我有一个小示例代码，基本上是大家都知道的矩阵乘法（三个嵌套的 for 循环）。我将计算卸载到带有 OpenMP 4.0 targetpragma 的 Intel MIC 并使用map(to:A,B) map(tofrom:C).

现在，我观察到的是对于小矩阵，例如 1024x1024，内存传输花费了非常长的时间。与原生版本（相同的代码，相同的并行化策略，只是没有卸载）相比，卸载版本消耗了大约 320 毫秒的时间。我对代码进行了热身运行以消除初始化开销。

与 Nvidia Tesla K20 相比，复制相同数量的内存却没有注意到这 320 毫秒非常糟糕。

是否有一些环境设置可以提高内存传输速度？

另外一个问题：我通过 OFFLOAD_REPORT 环境变量启用了卸载报告。报告中显示的两种计时结果有什么区别：

[Offload] [HOST]  [Tag 5] [CPU Time]        26.995279(seconds)
[Offload] [MIC 0] [Tag 5] [CPU->MIC Data]   3221225480 (bytes)
[Offload] [MIC 0] [Tag 5] [MIC Time]        16.859548(seconds)
[Offload] [MIC 0] [Tag 5] [MIC->CPU Data]   1073741824 (bytes)

在 MIC 时间（内存传输？）中缺少的那 10 秒是什么？

那么第三个问题。是否可以将固定内存与英特尔 MIC 一起使用？如果是，如何？

4

2 回答 2

1

既然您说“我对代码进行了热身运行以消除初始化开销”，我假设您通过卸载一个虚拟部分来启动卸载运行时。我记得有一个调整来启动它“on_offload”（默认）或在程序初始化时（OFFLOAD_INIT=on_start）。无论如何，DMA引擎中也有一条快速路径。当缓冲区（要传输的）与页面大小对齐时，将采用快速路径。对于卸载应用程序，您可以简单地设置环境变量以及阈值整数 B|K|M|G|T，其中 M 是兆字节（例如，MIC_USE_2MB_BUFFERS=2M）。此阈值定义使用大页面之前所需的缓冲区大小。所以你得到两件事：大页面和更快的传输！

在简单地尝试 OFFLOAD_INIT=on_start 和 MIC_USE_2MB_BUFFERS=0 之后，您可能需要相应地对齐主机端的缓冲区（最大矢量宽度和页面大小；-）。请记住，如果没有额外的卸载子句（LEO；但不确定 OpenMP 4.0），主机缓冲区的对齐方式只是由卸载部分继承。对齐到 2MB 应该涵盖所有内容（但您可以使分配更智能，以避免为小缓冲区浪费资源）。如果需要，您应该有足够的关键字来查找更多背景。

于 2013-11-18T06:48:00.910 回答
1

可能是 MIC 上的内存分配需要时间。尝试将开销的三个来源分开，以更好地了解时间的去向：

// Device initialization
#pragma offload_transfer target(mic)
...
// Memory allocation and first data transfer
// This is expected to have overhead proportional to the amount of memory allocated
// Doing at least one transfer will speed up subsequent transfers
#pragma offload_transfer target(mic) in(p[0:SIZE] : alloc_if(1) free_if(0))

...
// This transfer should be faster
// For large sizes, approaching 6 GiB/s
#pragma offload_transfer target(mic) in(p[0:SIZE] : alloc_if(0) free_if(0))
于 2013-11-18T17:31:10.910 回答