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

[Simon Peyton-Jones]

Sounds like a good plan to me -- thank you!

Simon

From: ghc-devs-bounces at haskell.org [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Johan Tibell
Sent: 25 April 2013 17:56
To: ghc-devs at haskell.org
Subject: Turning on -funbox-small-strict-fields by default in GHC 7.8

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/5fa7a6a2/attachment.htm>