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.
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.