(in-place) mutable unboxable Ints

Simon Marlow marlowsd at gmail.com
Sun Aug 25 22:11:14 CEST 2013


On 24/08/13 08:47, Herbert Valerio Riedel wrote:
> 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#
>
> ?

This is not like anything else we have: it's neither a primitive value 
that can be passed around, like Int#, nor is it an object on the heap 
with identity, like MutVar#.  What does it mean to pass a MutInt# value 
around?  Presumably the intention is for it to be passed by reference 
somehow, but a reference to what?

Mutable objects have identity - you have to explicitly create them with 
a State#, so that we don't accidentally create zero or two or some other 
number of them.  So if a mutable object were to be unpacked in a 
constructor field, its parent object would need to somehow assume the 
responsibility of being the object with identity.  I just don't know a 
good way to fit something like this into GHC (but that doesn't mean it's 
impossible!).

> PS: The FastMutInt API doesn't seem to provide atomic
>      decrements/increments, what would be needed to provide that?

Just some new primops.

Cheers,
	Simon





More information about the ghc-devs mailing list