OpenCL与OpenMP的性能 [英] OpenCL vs OpenMP performance

问题描述

是否有任何研究将OpenCL与OpenMP性能进行比较?我特别感兴趣的是使用OpenCL启动线程的开销成本，例如，如果要将域分解为大量的单个工作项(每个工作项都由做一个小工作的线程来运行)，而在OpenMP中使用较重的线程则是该域被分解为子域，其数量等于核心数.

Have there been any studies comparing OpenCL to OpenMP performance? Specifically I am interested in the overhead cost of launching threads with OpenCL, e.g., if one were to decompose the domain into a very large number of individual work items (each run by a thread doing a small job) versus heavier weight threads in OpenMP were the domain was decomposed into sub domains whose number equals the number of cores.

似乎OpenCL编程模型更针对大规模并行芯片(例如GPU)，而不是具有更少但更强大的内核的CPU.

It seems that the OpenCL programming model is more targeted towards massively parallel chips (GPUs, for instance), rather than CPUs that have fewer but more powerful cores.

OpenCL可以有效替代OpenMP吗?

Can OpenCL be an effective replacement for OpenMP?

推荐答案

我所看到的基准表明，在同一硬件上运行的OpenCL和OpenMP在性能上通常是可比的，或者OpenMP的性能稍好一些.但是，我还没有看到任何我认为可以得出结论的基准，因为它们大多缺乏对其方法的详细说明.但是，有一些有用的事情要考虑:

The benchmarks I've seen indicate that OpenCL and OpenMP running on the same hardware are usually comparable in performance, or OpenMP has slightly better performance. However, I haven't seen any benchmarks that I would consider conclusive, because they've been mostly lacking in detailed explanations of their methodology. However, there are a few useful things to consider:

• 在运行时编译内核时，OpenCL总是会有一些额外的开销.任何基准测试都需要这次单独列出，使用预编译的本机内核，或者运行足够长的时间以使内核编译无关紧要.

• OpenCL will always have some extra overhead when compiling the kernel at runtime. Any benchmark either needs to list this time separately, use pre-compiled native kernels, or run long enough that the kernel compilation is insignificant.

OpenCL的实现将有所不同.像NVidia这样的GPU供应商没有动力确保他们基于CPU的OpenCL实施尽可能快.没有一个OpenCL实现会比一个好的OpenMP实现更成熟.

OpenCL implementations will vary. GPU vendors like NVidia have no incentive to make sure their CPU-based OpenCL implementation is as fast as possible. None of the OpenCL implementations are likely to be as mature as a good OpenMP implementation.

OpenCL规范基本上没有说明基于CPU的实现如何在后台使用线程，因此，有关线程相对轻量级还是重量级的任何讨论都必然是特定于实现的.

The OpenCL spec says basically nothing about how CPU-based implementations use threading under the hood, so any discussion of whether the threading is relatively lightweight or heavyweight will necessarily be implementation-specific.

当您在CPU上运行OpenCL代码时，您的工作项不必太小.您可以使用与OpenMP相同的方法来解决问题.

When you're running OpenCL code on a CPU, your work items don't have to be tiny and numerous. You can break down the problem in the same way you would for OpenMP.

即使OpenCL的开销更大，也可能有其他一些原因希望使用它.

Even if OpenCL has a bit more overhead, there may be other reasons to prefer it.

• 很显然，如果您的代码可以充分利用GPU，那么您将需要使用OpenCL实现. CPU上的OpenCL性能可能足够好，以至于不为没有强大GPU的用户维护OpenMP后备代码路径也不值得.

• Obviously, if your code can make good use of a GPU, you will want to have an OpenCL implementation. OpenCL performance on a CPU may be good enough that it isn't worth it to also maintain an OpenMP fallback code path for users who don't have powerful GPUs.

良好的基于​​CPU的OpenCL实施意味着您将自动受益于CPU和OpenCL实施支持的任何指令集扩展.使用OpenMP，您需要做更多的工作来确保您的可执行文件同时包含SSEx和AVX代码路径.

A good CPU-based OpenCL implementation means that you will automatically get the benefit of whatever instruction set extensions the CPU and OpenCL implementation support. With OpenMP, you have to do extra work to make sure that your executable includes both SSEx and AVX code paths.

OpenCL矢量原语可以帮助您表达一些明确的并行性，而不会因使用SSE内部函数而牺牲可移植性和可读性.

OpenCL vector primitives can help you express some explicit parallelism without the portability and readibility sacrifices you get from using SSE intrinsics.

这篇关于OpenCL与OpenMP的性能的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！