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

[Edward Z. Yang]

SGTM.  Actually, I think actually it should be quite simple to argue that
there is no way for this change to degrade performance.

Cheers,
Edward

Excerpts from Johan Tibell's message of Thu Apr 25 09:56:03 -0700 2013:
> Hi,
> 
> I like to discuss enabling -funbox-small-strict-fields by default in GHC
> 7.8. First, a short description of the flag and why I added it.
> 
> *What does the flag do?*
> The flag causes all strict, pointer-sized or smaller* fields to be
> unpacked, as if you preceded them by an UNPACK pragma.
> 
> *Why does the flag exist?*
> The flag doesn't allow you to express anything you couldn't already express
> using UNPACK/-funbox-strict-fields. The purpose of the flag is twofold:
> 
>    - Allow for less clutter in source code. If you look at code tuned for
>    performance, every single small field has an UNPACK pragma (e.g. see
>    bytestring, text, containers, attoparsec, binary, etc). The extra UNPACK
>    pragmas makes the data type declaration harder to read.
>    - To give better performance by default for beginner and intermediate
>    Haskellers. Almost any performance problem I diagnoes (e.g. on
>    StackOverflow) involve telling the person to use UNPACK (and make the field
>    strict). I'd like to only tell them to make the field strict and let
>    compiler deal with the UNPACK.
> 
> *How do we turn the flag on by default?*
> 
> Before we turn the flag on by default, we should convince ourselves that it
> won't hurt performance (e.g. by causing re-boxing when an unpacked field is
> passed to a non-strict function). Here's my plan:
> 
>    - Look at all data declarations in some set of core libraries (e.g. the
>    ones mentioned above) and see if there are any strict but not unpacked
>    small fields in there. The presence of such fields suggests that the author
>    decided that unpacking was not beneficial there. *Done:* there are no
>    such fields in bytestring, text, binary, containers, or attoparsec.
>    - Run the nofib suite, which now includes some code with strict fields
>    from the language shootout suite, as a sanity check.
>    - Benchmark some large program that isn't carefully tuned by using
>    strictness in just the right places (like our core libraries tend to be),
>    to make sure this change doesn't hurt performance there. I nomiate GHC as
>    the candidate program for this test.
> 
> Aside: If I recall correctly John Meacham said that JHC has always used
> this optimization.
> 
> Does this sound like a reasonable plan? Does anyone have any input on
> whether this change makes sense? Simon?
> 
> P.S. I know how to run nofib with and without the flag. How can I benchmark
> the impact of the flag on building GHC? Does anyone have a step-by-step
> recipe for using GHC as a benchmark?
> 
> * This also includes Double, Int64, and Word64 on 32-bit platforms so the
> program space usage and performance doesn't change dramatically when
> switching platforms.