Re: [Haskell-cafe] Re: Go Haskell!

On Thu, Nov 27, 2008 at 1:20 PM, Claus Reinke wrote:

What do those folks working on parallel Haskell arrays think about the

...

...

sequential Haskell array baseline performance?

Try using a fast array library like uvector? (With no serious overhead for tuples too, fwiw)...

I downloaded uvector a while ago, but haven't got round to trying it (yet another array API?). Mostly, I'd like to know a little more than just "fast array lib":

- in which ways is it supposed to be faster? why? - for which usage patterns is it optimised? how? - if it is faster in general, why hasn't it replaced the default arrays?

In general, I think Haskell has too many array libraries, with too many APIs. And that doesn't even take account the overuse of unsafe APIs, or the non-integrated type-level safety tricks - if array accesses were properly optimized, there should be a lot less need for the extreme all-or-nothing checks or home-grown alternative special-purpose APIs:

- type-level code for watermarking indices belonging to certain index sets is one step to eliminate index checks, but hasn't been integrated into any of the standard libs - one could also associate index subsets with operations that do not leave the index superset belonging to an array (eg, if min

This library would satisfy most of your requirements I suspect: http://ofb.net/~frederik/vectro/draft-r2.pdf My understanding is that the author's code could be turned into a real library fairly easily if it hasn't been already. I only read the paper; I didn't go looking for the library on hackage, but the author does provide the code for the library. The author also says their Haskell code is faster than the same algorithm in Matlab. But, I have to say. Whenever you're faking dependent types in Haskell things get harder to understand for the programmer. Checkout the section in the above paper about type checking. Dependent types, even simulated ones, come with lots of cool static guarantees but understanding how to program with them comes with a high barrier to entry. I think this cognitive load is even higher in Haskell where dependent types have to simulated by doing seemingly bizarre things. I think it is this usability aspect that prevents the techniques from becoming more common in Haskell.

At least, uvector seems to take multi-element ops more seriously. But with so many people working on sequential and parallel Haskell array libraries, I was hoping for someone to take a big ax and clear out all that sick and half-dead wood, to give a small number of healthy arrays libs room to grow. Would be a lot easier for us poor naive Haskell array users who otherwise tend to get lost in that forrest!-)

Sometimes a good library design is an evolutionary process. Maybe it's time to apply a fitness function. Jason