major missing piece to arrays?
john at repetae.net
Fri Jul 16 20:47:25 EDT 2004
On Fri, Jul 16, 2004 at 10:43:58AM +0100, Simon Marlow wrote:
> > Also, in my tests, arrays implemented via ByteArray# or Ptr a seem to
> > be signifigantly faster than those implemented via ForeignPtr. Is this
> > expected?
> Yes, StorableArray suffers from this problem. Specialising the array operations on StorableArray might help.
So, I decided to do a little testing and implemented FastMutInt in 4
FastMutInt provides a fast mutable unboxed integer.
MutByteArray# basically equivalant to the one used in GHC
Ptr Int uses peek and poke on a malloced piece of memory
ForeignPtr Int uses peek and poke on a foreignptr
IORef Int just an IORef using 'seq' to be strict in its value
here are the (very simple) timings
Ptr Int: 196
ForeignPtr Int: 410
IORef Int: 340
Ptr Int: 174
ForeignPtr Int: 395
IORef Int: 304
so, ByteArray# seems to be equivalant to a raw pointer in speed, with
the advantage that it is garbage collected.
however foreignptrs are twice as slow! and even slower than an IORef.
I compiled with -O2 and inlined everything to try to get rid of any
as a tangent..
I have been using the
counter :: Ptr Int
counter = unsafePerformIO (new 0)
trick to create fast global counters in performance critical stuff, it
seems to work quite well. it would be nice if there were a way to
allocate the memory staticaly though, because then counter could be a
constant and should be much faster.
perhaps something like the
"foo"# :: Addr# trick? like
foreign data counter 4 :: Ptr Int
to reserve 4 bytes in the bss... hmm..
John Meacham - ⑆repetae.net⑆john⑈
More information about the Glasgow-haskell-users