Awesome. Has anyone tried using Haskell for scientific computing applications like: fluid simulation, finite element simulation, etc. It would be interesting to see benchmarks with traditional tools used in scientific computing industry which are usually done in C/C++.
GPU acceleration toolkits exist to a ton of languages and these toolkits aren't the only ones. Haskell also has Obsidian (as in Minecraft), Microsoft has one for .NET.
Nor are they had difficult to do, you basically have to implement map and reduce as OpenCL/CUDA code (which is C or C++, but without the nice stuff) and then a DSL from your target language to C (which, at least in Haskell, isn't very difficult).
I wrote one for Scala as a (small) part of a Masters project, but it wasn't very good.
If you search HN you will find a wealth of comments on the Accelerate. If you are writing such a library, or you plan to use it, be wary though that thenumber that a pragmatic user is interested in is the wall clock time. Speed-up plot hides this information. It turns out that it is surprisingly difficult even to beat single threaded array manipulating C code if the code has been written with the cache architecture in mind, the loops judicioulsly un-rolled etc etc.
If you are constrained to remain within the Haskell runtime, or the .net runtime, then speedup curves are fine and informative, but as a metric of comparison with other solutions, it is a bit deficient.
BTW this is by no means an effort to diminish the achievments of the accelerate framework. Writing efficient code using a high level code is an incredibly important and worthy goal and any progress deserve to be cheered, but lets not forget that there are miles to go.
Indeed, its easy these days to do something, but it's hard to do it well.
This is a particularly interesting effort as it is by far the most mature (7 years of work has gone into it - originally targetted Brook; then CUDA; and now OpenCL); is well funded (so will see continued improvement); is a deep, strongly typed embedding (meaning it looks and behaves like normal Haskell, making it easy to use); and is the most widely used Haskell GPU language, going by downstream dependencies.
