major missing piece to arrays?

[John Meacham]

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
ways, 
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

run 1...
ByteArray#: 191
Ptr Int: 196
ForeignPtr Int: 410
IORef Int: 340

run 2...
ByteArray#: 173
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
overhead. 


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

-- 
John Meacham - ⑆repetae.net⑆john⑈