5 ms·

I can tell that you wanted a clear distinction between implementations for comparisons sake. And I don't doubt that you could probably achieve higher performanc

I can tell that you wanted a clear distinction between implementations for comparisons sake. And I don't doubt that you could probably achieve higher performance in each respective branch with Cuda and c++ for GPU and CPU branches. I get why you'd choose Cuda over opencl for pure gpgpu code, but when faced with the requirement of having both a CPU and a GPU version why not use openCL to keep both code paths as close as possible? Did you write it so both branches live in a single build and can select the optimal path at runtime and looking at the hardware and seeing what is available? Or do you maintain two separate builds that are deployed to different servers?

paulmd 10y ago
You can actually go the other route too. There's a library called Thrust that provides a STL-like interface to CUDA, as well as "glue" functions that go between the finely-tuned stuff. One of the things Thrust supports is an OpenMP backend, so it can emit code that runs on a CPU instead of a GPU. I've never tried it so I don't know how good it is, particularly on the collective operations. But I assume if what you want is a "#pragma omp parallel for 1-to-N" then it's probably great. Construct your operation as a functor and use a thrust::for_each from 1 to N.
- maccard 10y ago
  Works reasonably well, but it absolutely ruins your compile times.
  - paulmd 10y ago
    Yeah, I totally agree. It's not just the OpenMP backend, it's Thrust in general. I had a project that was probably 5-10k LOC and it took like 2 minutes to compile with Thrust. I'm pretty sure nvcc doesn't handle the templating very well.
- gnarbarian 10y ago
  hmm interesting I had no idea that existed. Looking forward I have high hopes for Vulkan being the foundation for cross platform and cross vendor heterogeneous computing. As it is in the raw, it's pretty rough to use but I am excited to see what interfaces will be built on top of it to make heterogeneous computing more accessible and maintainable. I'm thinking something like PyOpenCL for Vulkan.

paulmd 10y ago

You can actually go the other route too. There's a library called Thrust that provides a STL-like interface to CUDA, as well as "glue" functions that go between the finely-tuned stuff. One of the things Thrust supports is an OpenMP backend, so it can emit code that runs on a CPU instead of a GPU. I've never tried it so I don't know how good it is, particularly on the collective operations. But I assume if what you want is a "#pragma omp parallel for 1-to-N" then it's probably great. Construct your operation as a functor and use a thrust::for_each from 1 to N.

maccard 10y ago
Works reasonably well, but it absolutely ruins your compile times.
- paulmd 10y ago
  Yeah, I totally agree. It's not just the OpenMP backend, it's Thrust in general. I had a project that was probably 5-10k LOC and it took like 2 minutes to compile with Thrust. I'm pretty sure nvcc doesn't handle the templating very well.
gnarbarian 10y ago
hmm interesting I had no idea that existed. Looking forward I have high hopes for Vulkan being the foundation for cross platform and cross vendor heterogeneous computing. As it is in the raw, it's pretty rough to use but I am excited to see what interfaces will be built on top of it to make heterogeneous computing more accessible and maintainable. I'm thinking something like PyOpenCL for Vulkan.