Openmp 与英特尔话筒之间的内存传输开销

Openmp 与英特尔话筒之间的内存传输开销,openmp,intel-mic,Openmp,Intel Mic,我观察到一个奇怪的行为,想知道它是否与英特尔至强Phi有关 我有一个小示例代码,基本上是大家都知道的矩阵乘法(三个嵌套循环)。我使用OpenMP 4.0targetpragma将计算转移到一个英特尔麦克风上,并使用map(to:A,B)map(tofrom:C)映射三个矩阵 现在,我观察到的是,对于小矩阵,例如1024x1024,内存传输花费了非常长的时间。与本机版本(相同的代码,相同的并行化策略,只是没有卸载)相比,卸载版本要多花大约320ms的时间。我对代码进行了预热运行,以消除初始化开销

我观察到一个奇怪的行为,想知道它是否与英特尔至强Phi有关

我有一个小示例代码,基本上是大家都知道的矩阵乘法(三个嵌套循环)。我使用OpenMP 4.0
target
pragma将计算转移到一个英特尔麦克风上,并使用
map(to:A,B)
map(tofrom:C)
映射三个矩阵

现在,我观察到的是,对于小矩阵,例如1024x1024,内存传输花费了非常长的时间。与本机版本(相同的代码,相同的并行化策略,只是没有卸载)相比,卸载版本要多花大约320ms的时间。我对代码进行了预热运行,以消除初始化开销

与Nvidia特斯拉K20相比,在没有注意到的情况下复制相同数量的内存是非常糟糕的

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

还有一个问题: 我通过卸载报告环境变量启用了卸载报告。报告中显示的两个计时结果之间有什么区别:

[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)
话筒时间(内存传输)缺少的10秒是什么

第三个问题。是否可以将固定内存与英特尔话筒配合使用?如果是,怎么做?

既然您说“我做了一次代码的热身运行以消除初始化开销”,我假设您是通过卸载一个虚拟部分来启动卸载运行时的。我记得有一个调整是在“卸载时”(默认)或在程序初始化时(卸载时=启动时)启动它。无论如何,DMA引擎中也有一条快速路径。当缓冲区(待传输)与页面大小对齐时,采用快速路径。对于卸载应用程序,您可以简单地设置一个环境变量和一个阈值整数b | K | M | G | T,其中M是兆字节(例如,MIC_USE_2MB_BUFFERS=2M)。此阈值定义了使用大型页面之前所需的缓冲区大小。所以你得到了两件事:巨大的页面和更快的传输!即使在协处理器上引入了透明巨大页面(THP),此功能仍然有意义


在尝试卸载\u INIT=on\u start和MIC\u USE\u 2MB\u BUFFERS=0之后,您可能需要相应地对齐主机端的缓冲区(最大向量宽度和页面大小;-)。请记住,如果没有额外的卸载条款(LEO;但不确定OpenMP 4.0),主机缓冲区的对齐只会由卸载部分继承。调整到2MB应该涵盖所有内容(但您可以使您的分配更加智能,以避免将资源浪费在小型缓冲区上)。如果需要的话,你应该有足够的关键字来查找更多的背景。

可能是麦克风上的内存分配需要时间。尝试将三个开销来源分开,以便更好地了解时间的去向:

// 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))

谢谢你的回答。我使用
\u mm\u alloc
获得正确的对齐内存。
MIC_USE_2MB_BUFFERS
的提示似乎有点帮助,但是,即使我设置
MIC_USE_2MB_BUFFERS=0
并将我的分配与2MB对齐,内存传输仍然需要250毫秒。我尝试了MKL,没有遇到这样的问题。任何额外的建议都会很好。感谢您的尝试和反馈!您是否检查过卸载启动时的卸载启动?是的,这将删除第一个卸载区域的初始化开销。然而,内存传输开销仍然存在,内存分配才是真正的问题。与内存传输相比,它们需要很长的时间。有没有办法减少这种分配开销。另外,你能解释一下为什么它首先出现吗?