[Haskell-cafe] Program optimisation

David Roundy droundy at darcs.net
Fri Apr 20 15:51:32 EDT 2007


On Fri, Apr 20, 2007 at 08:33:41PM +0100, Andrew Coppin wrote:
> >Indeed, unboxed arrays are much nicer, but the whole Array batch of the
> >standard library is pretty useless, in my experience.  You can roll your
> >own relatively easily using ForeignPtr, similar to Data.ByteString, but
> >that's a bit of a pain.
>
> There is no *way* I'm playing with C. The entire point of Haskell is to 
> allow mankind to eradicate C forever. :-)

ForeignPtr doesn't have anything to do with C, it's just the data structure
you need to use if you want to write your own unboxed array.

> I was more interested in seeing people's comments about the program 
> changes. For example, why would an in-place update be slower than lots 
> of dynamically-allocated lists? That's totally counterintuitive. Also, 
> is there any way in hell I can make the program stricter without 
> mutilating the entire thing to use unboxed arrays? I couldn't figure out 
> a way to do this. (Would be nice if there was a compiler switch to just 
> turn off all laziness - but as far as I can tell, there isn't.)

The in-place update (without boxing) still dynamically allocates thunks,
which are similar in cost to cons cells (for some definition of similar).

Unboxed arrays are exactly what you want--except that the UArray type is
limited, which is why I recommended rolling your own.  Hopefully the PArr
package will help reduce the pain of using arrays.

In any case, in my opinion Haskell desperately needs more strict data
types, as strict types can go a long way towards eliminating all sorts of
pain.  I remember once going through all sorts of pain trying to avoid
stack overflows when using Data.Map to compute a histogram, which all would
have been avoided if there were a strict version of Data.Map (or even just
strict functions on the lazy Data.Map).  I don't think eliminating all
laziness is a good idea, but (optional) strict datatypes most certainly
are, as they can go a very long ways towards eliminating memory leaks.
-- 
David Roundy
Department of Physics
Oregon State University


More information about the Haskell-Cafe mailing list