CUDA Performance: Maximizing Instruction-Level Parallelism • Hacker News Board

Re: CUDA Performance: Maximizing Instruction-Level Parallelism

#11

Post by iskander » Mon, Sep 09, 2013, 6:04 PM UTC

alcari wrote: post #9

iskander wrote: post #4

Vasily's approach to CUDA really revolutionized how I think about GPU programming and I'm glad the continuum folks are giving ILP on the GPU a broader audience. Can anyone testify to the quality of continuum's CUDA wrapper? Is it nicer to work with than PyCUDA?

I haven't dealt much with PyCUDA recently, but Continuum's wrapper is interesting in that it compiles python code (or at least a subset thereof) to run natively on the GPU, via LLVM if I'm not mistaken. As far as I'm aware, PyCUDA only allows Python code to call pre-compiled CUDA kernels.

PyCUDA lets you define new kernels by plopping CUDA source as a triple-quoted string in the middle of your Python code. It's not the most elegant thing in the world but you quickly get used to it. It seems on the surface that Continuum's CUDA is essentially the same thing sans-quotations. The semantic level of the "Python" code you're compiling doesn't look significantly more abstract than what you would find in a .cu file. But, it's not fair to judge from a few blog posts, which is why I'm wondering what peoples' actual experiences have been.

Re: CUDA Performance: Maximizing Instruction-Level Parallelism

#12

Post by iskander » Mon, Sep 09, 2013, 6:10 PM UTC

lmeyerov wrote: post #10

alcari wrote: post #9

Earlier quoted context omitted.

I haven't dealt much with PyCUDA recently, but Continuum's wrapper is interesting in that it compiles python code (or at least a subset thereof) to run natively on the GPU, via LLVM if I'm not mistaken. As far as I'm aware, PyCUDA only allows Python code to call pre-compiled CUDA kernels.

A labmate did some great work similar to Continuum's wrapper and has been continuing on now at NVIDIA: http://copperhead.github.io/ . He basically identified an ML-like subset of Python (sort of like asm.js vs js) and specializes it. For me, the big surprise is that Copperhead departs from NESL-like flattening transformations (e.g., those used by Data Parallel Haskell.) It's a bit less surprising when you realize the…

Is Bryan still working on Copperhead?

Also, do you know if the DPH folks ever managed to iron out a version of higher order flattening which gives a predictable performance gain?

Re: CUDA Performance: Maximizing Instruction-Level Parallelism

#13

Post by lmeyerov » Mon, Sep 16, 2013, 8:42 PM UTC

iskander wrote: post #12

lmeyerov wrote: post #10

Earlier quoted context omitted.

A labmate did some great work similar to Continuum's wrapper and has been continuing on now at NVIDIA: http://copperhead.github.io/ . He basically identified an ML-like subset of Python (sort of like asm.js vs js) and specializes it. For me, the big surprise is that Copperhead departs from NESL-like flattening transformations (e.g., those used by Data Parallel Haskell.) It's a bit less surprising when you realize the…

Is Bryan still working on Copperhead? Also, do you know if the DPH folks ever managed to iron out a version of higher order flattening which gives a predictable performance gain?

I think Bryan has been doing a followup to Copperhead, probably easy to just ask him :)

I don't know what you mean by predictable performance. Flattening is a direct transformation and seems simple to reason about on SIMD architectures, though the recent dynamic schedule (work stealing) approach for multicore/distributed has the usual caveats. (I tend to avoid it for HPC.) Given the 10+ year history of the researchers involved, it seems like a slow-but-steady project..