So if you do a benchmark, it really depends on which kernels you use for it. To be more precise: any benchmark can be written in favour of a specific architecture. Fine-tuning the software to work a maximum speed in current and future! The page is offline now, but you it was clear that the data-transfer from and to the GPU is a huge bottleneck and Hugh Merz was rather sceptical about GPU-computing in He extended his benchmark with the PS3 and a Tesla-s and now you see bigger differences.
Since CPUs go multi-multi-core, you cannot tell how big this gap will be in the future; but you can tell the gap will be bigger and CPUs will more and more be programmed like GPUs massively parallel. What we learn from this is 1 that different devices will improve if the demands are more clear, and 2 that it will be all about specialisation, since different manufacturers will hear different demands. NVidia wants to enter high in the HPC-world, and they might even win it. While I was searching for more information about this difference, I came across a blog-item by RogueWave , which claims something different.
In the near future could bring us an xchip from NVidia. This will change a lot in the field, so more about this later. Like Java and. NET are very comparable, developers from both side know very well that their favourite feature is missing at the other camp. Most time such a feature is an external library, just built in. Or is it taste? Or even a stack of soapboxes? All differences are based on this difference in focus-area.
As it is done with more shared standards, there is no win and no gain to promote it. It has the right ingredients as a standard--mainly run-time code generation and reasonable support of heterogeneous computing. On top of that, being in a multi-vendor marketplace is a good thing--also for Nvidia, although they might not immediately see it that way.
OpenCL comes bundled with your OS and supports more cards so starting is a snap. I agree with Andreas that learning about GPU programming is similar for both frameworks.
Adding my own opinion here. I have been using OpenCL for the last 2 months or so, and feel that I have a basic understanding of it, if not a moderate view.
The errors sometimes do not even report the actual problem i. To be fair, the same is true for CUDA--the corresponding error is "invalid context", and you'll have to learn that means you caused something like a segfault. CUDA can also use variables straight out of code, due to it being code. OpenCL is parsed as a string.
The CUDA environment is much more user friendly. OpenCL has more "customizable" options for it, but this just leads to code refactoring between machines. You don't have to stick CL code into a string, you can read it from a separate file, which any sensible IDE will treat as valid C.
0コメント