DCompute: GPGPU with Native D for OpenCL and CUDA

http://dlang.org/blog/2017/07/17/dcompute-gpgpu-with-native-d-for-opencl-and-cuda/

by ingve • 9 years ago

111 30 9 years ago

gravypod• 9 years ago

I can't wait until compilers can start auto generating GPU kernels. That will be when GPGPU really takes off for most people who's applications aren't critical enough to spend hours writing these by hand but would benefit from the significant speed up.

pcwalton• 9 years ago

I'm not sure that will ever happen, at least without changing languages.

Autovectorization alone is difficult in C and C++ because the languages provide almost no useful information about aliasing. Precise aliasing info is just the tip of the iceberg regarding what you would need for GPU-based autovectorization.

moosingin3space2• 9 years ago

Is there any discussion about doing this in Rust? (maybe surrounding the SIMD RFCs)

willvarfar2• 9 years ago

(On the Mill CPU the retire stations snoop/snarf writes and spot aliasing as it happens at runtime. This is a big part of our auto-vectorisation)

WalterBright2• 9 years ago

D has array expressions, which look like:

   a[] = c * b[];

The idea of them is they are parallelizable, and do not require an auto-vectoring loop optimizer. Auto-vectorizing is fraught with problems, like the user not being aware if the auto-vectorizing succeeded or not.

Another aspect of D that enables parallization is the use of ranges + algorithms. Although currently unexploited, it has the potential to be able to express parallel algorithms, and then take advantage of that.

jamesaross• 9 years ago

There are several efforts including VexCL [0] expression templates, OpenACC [1] preprocessor, Kokkos [2] template metaprogramming, SYCL [3], and many other similar projects. Parallel programming for non-trivial parallelism is still...non-trivial.

[0] https://github.com/ddemidov/vexcl

[1] https://www.openacc.org/

[2] https://github.com/kokkos/kokkos

[3] https://www.khronos.org/sycl

VHRanger5• 9 years ago

If OpenACC worked as well as OpenMP (or OpenMP offloads worked as simply) it'd be huge, I would think

moosingin3space2• 9 years ago

Apparently Numba can (kind of) do this. It JITs Python/Numpy/Scipy code through the LLVM-based toolchain for CUDA.

[1] http://numba.pydata.org/numba-doc/latest/cuda/kernels.html [2] http://numba.pydata.org/numba-doc/latest/cuda/reduction.html...

VHRanger5• 9 years ago

You still need to write what's basically CUDA code for it to run.

It's not at all like you write python and it translates it to CUDA or anything.

Athas3• 9 years ago

It is really difficult to extract parallelism from sequentially written programs. It is even worse when it comes to restricted fine-grained parallelism, as on a GPU. I'm not aware of any really robust auto-parallelising compiler, and even compilers for specialised parallel languages struggle to reach performance close to hand-written code for more complex problems.

e9• 9 years ago

not sure if this is what you are looking for but I had success with this Java library http://aparapi.com/, it looks at function's JVM byte code and runs it on GPU if it can, otherwise falls back to CPU. I suspect same thing can be done in other languages.

https://github.com/Syncleus/aparapi/

"Aparapi allows developers to write native Java code capable of being executed directly on a graphics card GPU by converting Java byte code to an OpenCL kernel dynamically at runtime. Because it is backed by OpenCL Aparapi is compatible with all OpenCL compatible Graphics Cards."

nicwilson5• 9 years ago

One of the main goals for DCompute is to lower the barrier of entry, so that people how have embarrassingly parallel problems can take advantage of their hardware without being an expert.

ptrott20172• 9 years ago

Nicholas Wilson has done an awesome job with DCompute - especially ability to use D's lambda's and templates when writing compute kernels. Its going to be fun seeing this evolve.

VHRanger5• 9 years ago

I'd be excited for D to find its niche there. Good heterogeneous compute support with D's introspective design features has the potential to be a very powerful way to create number crunching applications

nicwilson5• 9 years ago

Thanks. Halide has recently caught my eye and I'd like to see how far I replicate how they do things. It'll have to wait a bit though.

ptrott20172• 9 years ago

Halide has some interesting ideas for image processing -especially regarding algorithm separation and scheduling - so great to hear its on your radar and be very interested to see what you come up with. My interest/focus is more on stencil codes and that is certainly an area I hope to test with DCompute. Congrats again (and thanks again) for an awesome project.

axaxs• 9 years ago

D has always interested me a lot. Sure it's been around a while, but the community seems rather small - comparatively. That said, that small community produces some really nice stuff - they are up to what 3 'official' compilers now? I hope to see its adoption rise now that the reference compiler is open source(iirc) - the community seems second to none as far as signal to noise ratio goes.

p0nce• 9 years ago

Interesting. CUDA kernels are plagued by an explosion of entry points and OpenCL C kernels by the lack of meta-programming.

DCompute: GPGPU with Native D for OpenCL and CUDA

Related Stories