(in-place) mutable unboxable Ints (was: [GHC] #8158: Replace IO manager's IntMap with a mutable hash table)
Herbert Valerio Riedel
hvr at gnu.org
Sat Aug 24 09:47:31 CEST 2013
Hello Simon,
On 2013-08-24 at 08:54:20 +0200, GHC wrote:
[...]
> Comment (by simonmar):
>
> @bos: GHC has a `FastMutInt` type for this purpose, which is a 1-element
> mutable unboxed array. I'd be interested to know whether performance
> differs between this and `ForeignPtr`.
>
> source:ghc/compiler/utils/FastMutInt.lhs
One thing I have been wondering about:
...even with FastMutInt, which is defined as
data FastMutInt = FastMutInt (MutableByteArray# RealWorld)
If I have a hypothetical data structure,
data IoStats = IoStats { sBytesRecv :: {-# UNPACK -#} !FastMutInt
, sBytesSent :: {-# UNPACK -#} !FastMutInt
, sPacketsRecv :: {-# UNPACK -#} !FastMutInt
, sPacketsSent :: {-# UNPACK -#} !FastMutInt
}
Then (if have the numbers right) each instance of IoStats takes 1 word
for the IoStats info-ptr, plus 1 word for each unpacked FastMutInt
(which is basically reduces to pointer to a MutableByteArray#), and 3
words for each MutableByteArray# as those result in separate heap
objects; that is, a total of 17 words needs to be allocated to keep
track of 4 counters. The overhead could be improved somewhat, if I used
a 4-word-long MutableByteArray (which would still be a separate heap
object and thus result in a single 3-word overhead), but the data
declaration would be less expressive IMHO.
Would it be possible (w/ reasonable effort) to have an unpackable
version of FastMutInt which only has a total storage cost of 1 word
(when unpacked), so that IoStats would have a total storage cost of 5
words (and no indirections)?
Or even just a new unboxed primitive MutInt# type in the style of Int#,
so that FastMutInt would be defined similiar to 'Int' as
data FastMutInt = FMI# MutInt#
?
PS: The FastMutInt API doesn't seem to provide atomic
decrements/increments, what would be needed to provide that?
Cheers,
hvr
More information about the ghc-devs
mailing list