Hello Andrew,
Friday, April 20, 2007, 10:01:32 PM, you wrote:
I have *no idea* if this is an appropriate place to put this, but here
goes...
http://haskell.org/haskellwiki/Library/AltBinary
http://haskell.org/haskellwiki/Modern_array_libraries
last article contains information about slowness
Donald Bruce Stewart wrote:
ahey:
Actually it isn't I'm afraid. That module has had a complete re-write
since the package was last cabalised. Anybody who's interested should
darcs get it from
http://darcs.haskell.org/packages/collections-ghc6.6/
Oh, what's remaining before the next release?
I have *no idea* if this is an appropriate place to put this, but here
goes...
I have a (presumably) common problem. I have a nice Haskell program.
It's compute-bounded, and I'd like to make it go faster. To that end,
I've been trying to optimise it.
Without going into great detail, the
On Fri, Apr 20, 2007 at 07:01:32PM +0100, Andrew Coppin wrote:
I have *no idea* if this is an appropriate place to put this, but here
goes...
Sure.
Next, I read the GHC manual. Apparently there's a command-line switch
-O2 which makes GHC try harder to optimise the program. (I had
stupidly
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
David Roundy wrote:
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).
Then what you
droundy:
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
Yes! Haskell is a combined strict and lazy language, after all.
In particular, the ability to precisely combine strictness and laziness
in a
ahey:
David Roundy wrote:
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).
Then
Donald Bruce Stewart wrote:
ahey:
David Roundy wrote:
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
ahey:
Donald Bruce Stewart wrote:
ahey:
David Roundy wrote:
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
10 matches
Mail list logo
