[Haskell-cafe] Re: Go Haskell!

[Jason Dagit]

On Thu, Nov 27, 2008 at 1:20 PM, Claus Reinke <claus.reinke at talk21.com>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<i<max, then
> min<=i+-1<=max, still safe without checks)
> - GHC does seem to common up index checks only if they are
>   identical, but if min<i<i+1<i+2<..<i+j<max, only the outer checks   are
> really necessary (as long as we know about '+')
> - whole-array ops allow to avoid index checks without type-level
>   tricks, leaving the indexing implicit; but the corresponding ops
>   in Data.Array.MArray claim to construct new arrays, contrary
>   to the intended inplace updating for which one uses MArrays?
> - etc. etc.


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081127/a07eafa7/attachment.htm