Turning on -funbox-small-strict-fields by default in GHC 7.8

Simon Marlow marlowsd at gmail.com
Fri May 10 10:16:47 CEST 2013

On 26/04/13 06:32, Johan Tibell wrote:
> On Thu, Apr 25, 2013 at 9:51 PM, Bryan O'Sullivan <bos at serpentine.com> wrote:
>> On Thu, Apr 25, 2013 at 4:01 PM, Johan Tibell <johan.tibell at gmail.com>
>> wrote:
>>> I think you could make up a case where it is a loss. It would boil down to
>>> repeated reboxing of a value pulled out of a strict field. In practice I
>>> think it's pretty hard.
>> I've seen this in real-world code, though it is indeed rare in my
>> experience.
> If you remember where it would be great to see an example. There's
> also NOUNPACK nowadays so you can opt out in these specific cases.

I'm probably a bit late to the party here, but I've seen UNPACK make 
things worse a lot inside GHC itself.  I think it would be a good idea 
to measure this change on GHC, if you haven't already.

One particular example I remember recently was that when trying to make 
the code generator faster I tried unpacking various fields in the Cmm 
data type (and its children).  Some of them resulted in improvements, 
and I've left those in, while others made things worse.  In some cases 
it made runtime worse but heap residency better, as you might expect 
because the representation is smaller.


More information about the ghc-devs mailing list