在分析 OpenCL 代码时，我是否还应该测量 clCreateContext()？

Question

最近我正在编写处理一些图像的 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 代码？

---

另外：我的程序将处理连续图像（如视频），因此在 GPU 和其他内存之间会有频繁的内存复制。那么我也应该有时间在 OpenCL 代码和本机 C 代码中复制内存，对吧？

Answer 1

我的意思是，这显然取决于您需要测量的内容。

一般来说，如果您关心程序的总运行时间，请测量总运行时间，包括上下文创建。

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

例如，您用来测量某事执行所需时间的计时器具有一定的粒度，通常以微秒的倍数为单位。如果您的工作负载比 500 µs 短，那么您所测量的实际上无法用作基准。这是很多东西性能比较的通病！