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

[Johan Tibell]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130425/163df7ae/attachment.htm>