Home » forums » LtU Forum

haskell for gpu

They are essentially translating haskell to CUDA code. The added semantics on the Haskell side is what is most interesting. Does anyone know of similar projects to add higher-level constructs to a language that gets compiled to CUDA. It's not clear to me from this presentation what the Lava semantics have to do with it.

Obsidian

By David Minor at 2008-09-24 12:28 | LtU Forum | previous forum topic | next forum topic | other blogs | 14879 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

How does this work compare to BSGP?

At SIGGRAPH'08, Hou et. al. presented BSGP: Bulk-Synchronous GPU Programming, which looked pretty impressive. How does this work compare to that?

By Pal-Kristian Engstad at Wed, 2008-09-24 18:52 | login or register to post comments

Comparison in a nutshell

At a glance, BSGP seems to be based on a a standard C-like imperative programming model with explicit identification of synchronization points, while Obsidian uses a more declarative model in which "components" are wired together (much like hardware would be) and in which synchronization points don't need to be explicitly identified. BSGP seems more fully realized, while Obsidian looks like it's still in the prototype phase.

By Allan McInnes at Fri, 2008-09-26 09:12 | login or register to post comments

Brahma

http://brahma.ananthonline.net/

By David Cuccia at Mon, 2008-10-13 04:51 | login or register to post comments

Nice! I'm definitely

Nice! I'm definitely checking Brahma out, I need to speed my physics engine up.

These are all basically meta-programming approaches. In Haskell, you build up a signal network that is then used to generate Cuda code (very much like FRP, which is kind of about forming and re-evaluating syntax trees). In Brahma, LINQ-style query-shipping-like meta-programming is used instead.

I'm wondering when someone will design a high-level language for GPU programming that isn't C and isn't meta? The key would be defining a nice high-level restricted memory model. Anyways, we'll probably have to write a few more shaders before we get any good ideas.

By Sean McDirmid at Mon, 2008-10-13 11:40 | login or register to post comments

Reminiscing

And where on this forum would I read, of some CPU architecture, that its vendor had been (quoting from memory) "foolish not to port an Haskell compiler to it" ? My memory seems to be not accurate enough for google to help me find the exact details, but maybe someone else here could.

Al.

By Alnicodon at Wed, 2008-10-15 22:27 | login or register to post comments

Also,

Sean Lee held a tech talk about his project, GpuGen, at Galois and has a few numbers and the background of the project; the approach involves using a GADT to describe what to run on the GPU and compiling to CUDA (the compilation pipeline is outlined as well.)

You can find slides here:

http://www.galois.com/blog/2008/08/29/gpugen-bringing-the-power-of-gpus-into-the-haskell-world/

By Austin Seipp at Sun, 2008-10-19 07:19 | login or register to post comments

I've just implemented a

I've just implemented a lightweight DSL based on lifting so WPF pixel shader effects can be expressed in C#. Not as typeful as Haskell, but useful nonetheless. URL:

http://www.codeplex.com/bling

Also, I wrote a blog post here.

Edit: fixed the URL!

By Sean McDirmid at Tue, 2008-10-21 12:12 | login or register to post comments

Seems that URL should be

Seems that URL should be http://www.codeplex.com/bling

Excellent work, however!

By natecain at Tue, 2008-10-21 14:18 | login or register to post comments