Unpack primitive types by default in data

[Johan Tibell]

On Wed, Feb 29, 2012 at 2:08 AM, Simon Marlow <marlowsd at gmail.com> wrote:

> (I think you meant "record", not "field" in the last sentence, right?)
>

I did mean record, but I wasn't being very clear. Let me try again.


> It's not obvious to me why having a mixture of strict and nonstrict (maybe
> you meant UNPACKed and not UNPACKed?) fields would make things worse.
>  Could you give a concrete example?
>

Sure. Lets say we have a value x of type Int, that we copy from constructor
to constructor:

    f (C_i x) = C_j x  -- for lots of different i:s and j:s

(In practice C_i and C_j most likely have different types.)

In a program with constructors, C_1 .. C_n, we can do one of three things:

 1. Unpack no fields.
 2. Unpack some fields.
 3. Unpack all fields.

Now, if we have a program that's currently in state (1) and we move to
state (2) by manually adding some unpack pragmas, performance might get
worse, as we introduce re-boxing where there was none before. However, if
we kept unpacking fields until we got into state (3), performance might be
even better than in state (1), because we are again back into a state where

 * there's no reboxing (lazy functions aside), but
 * we have better cache locality.

I suspect many large Haskell programs (GHC included) are in state (1) or
(2).

If we introduce -funbox-primtive-fields and turn it on by default, the hope
would be that many programs go from (1) to (3), but that only works if the
programs have consistently made primitive fields strict (or kept them all
lazy, in which case -funbox-primitive-fields does nothing.) If the
programmer have been inconsistent in his/her use of strictness annotations,
we might end up in (2) instead.

Did this make any more sense?

Cheers,
  Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20120229/7ce334ab/attachment.htm>