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⑈