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â _______________________________________________ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users