Final version of the Accelerate paper (GPGPU in Haskell)

Edit
Delete
Tags
Autopost

Final version of the Accelerate paper (GPGPU in Haskell)

We will present our paper Accelerating Haskell Array Codes with Multicore GPUs at ACM SIGLAN Declarative Aspects of Multicore Programming (DAMP 2011), which is co-located with POPL'11 in Austin, TX, in January. The final version of our paper is now available, and we plan to soon release a significantly improved version of the Accelerate library (matching the API used in the paper), which enables high-level GPGPU programming in Haskell based on NVIDIA's CUDA environment.

Posted

6 responses
Like
Comment

over 1 year ago Felipe Lessa responded:

Great! =)

I just missed some CPU benchmarks comparing the LLVM backend with C code. There wasn't a lot of space left on the paper, so is there any chance to see such benchmarks somewhere else?

Congrats!

over 1 year ago Ketil Malde responded:

Although the PDF displays nicely in Evince, it fails to print - it all comes out as a jumble of characters all over the pages. I tried two different printers. I don't know how this happened, most other material prints nicely. It prints from xpdf, though.

over 1 year ago Manuel Chakravarty responded:

Felipe, I'm not sure why you are referring to LLVM. Would you like to see comparisons between CUDA-based GPU code and a standard CPU implementation? We haven't included that as we compare to hand-coded CUDA and many people have already compared that to CPU code.

However, in Section 6.1, we note that a dot product for 18 million floats using Haskell's highly optimising vector package takes about 71ms on our benchmark machine. The Accelerate GPU version takes 3.5ms for the same computations. Transferring one of the involved arrays between the CPU and GPU takes about 20ms. So, even if you need to transfer all data to the GPU, compute the dot product, and transfer the result back, you are at 63.5ms for the GPU version versus 71ms for the sequential CPU version.

However, keep in mind that in any realistic application, you would execute much more complex computations on the GPU for a single data transfer. Hence, the performance advantage of using a GPU will be much bigger.

over 1 year ago Manuel Chakravarty responded:

Ketil, that is odd. The PDF was generated by pdflatex using the standard ACM SIGPLAN conference style file. I can only imagine that Evince might be confused by some of the include PDF figures.

AFAIK, Evince has a ghostscript backend, whereas xpdf has its own PDF backend. So, it might tickle a bug in ghostscript's PDF to PS conversion.

over 1 year ago Felipe Lessa responded:

I imagine that one of the advantages of using Accelerate is to have CPU and GPU code from one codebase. Although using GPU is a big win for many problems, sometimes you want to run the same code on a machine without any GPUs available. Or maybe you want your CPU working while the GPU is working as well.

The benchmarks on the paper show that Accelerate's CUDA backend generates code that isn't better than especially crafted CUDA code. However, it is close enough, especially considering that Accelerate code is much higher level.

So what I would like to know is if Accelerate's LLVM backend is competitive with especially crafted C code on the CPU as well. Is it capable of using SIMD instructions? Is it at least better than naive C code?

Cheers!

over 1 year ago Manuel Chakravarty responded:

Felipe, Accelerate's LLVM backend is not finished yet. I'm optimistic that it will generate competitive code, though, given the results Lennart Augustsson's achieved with the Haskell LLVM package.

Just Testing

About Me

Final version of the Accelerate paper (GPGPU in Haskell)