在分析OpenCL代码时,我还应该测量clCreateContext()吗?

时间:2017-06-20 10:24:31

标签: c parallel-processing opencl gpgpu

最近我正在编写处理一些图像的OpenCL代码。 完成代码后,我需要对OpenCL代码和本机C(或C ++)代码进行基准测试,这些代码执行相同的工作。

我的问题从上面引起。具体而言,我应该包含哪些步骤来进行时间测量?

StackOverflow上的大部分书籍和问题仅测量使用clGetEventProfilingInfo()和clWaitForEvents()执行clEnqueueNDRangeKernel()的时间。

我的大四学生说我需要包含缓冲区复制作业(C内存到cl_mem),因为本机C代码没有这样的步骤。 然后我应该包含程序创建&内核构建步骤,参数设置步骤,* .cl源代码文件读取步骤,以及(最奇怪的东西)clCreateContext()步骤?

根据 [this paper],与下面的其他步骤相比,clCreateContext()消耗的时间最长。 IMAGE

来自SONY的Android OpenCL代码示例也只获取clEnqueueNDRangeKernel()的已用时间。点击这里 - > developer.sonymobile.com/downloads/code-example-module/opencl-code-example /

如果上面是正确的,我是否应该只测量在OpenCL内核代码中执行相同工作的本机C代码?

或者有各种观点来分析和比较OpenCL&原生C代码?

PLUS:我的程序将处理连续图像(如视频),因此GPU和其他内存之间会有频繁的内存复制。那么我也应该花时间在OpenCL代码和本机C代码中复制内存,对吧?

1 个答案:

答案 0 :(得分:1)

我的意思是,这显然取决于你需要衡量的东西。

通常,如果您关心程序的总运行时间,请测量总运行时间,包括上下文创建。

实际上,您通常不使用openCL来执行工作负载,这些工作负载在程序的整个生命周期中比上下文创建花费的时间更少。如果是这种情况,我一定要检查使用openCL是否有意义。 OpenCL是一个单指令,非常多的数据架构。因此,我认为您可能正在构建测试平台,只需要做太少的工作就可以获得统计上足够的数据。

例如,用于衡量执行时间的计时器具有一些粒度,通常为几微秒。如果您的工作量比500μs短,那么您所测量的几乎无法用作基准测试。对于很多事情的性能比较,这是一个常见的问题!