On Wed, Feb 29, 2012 at 2:08 AM, Simon Marlow <span dir="ltr"><<a href="mailto:marlowsd@gmail.com">marlowsd@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">(I think you meant "record", not "field" in the last sentence, right?)</div></div></blockquote><div><br></div><div>I did mean record, but I wasn't being very clear. Let me try again.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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?<br>
</blockquote><div><br></div><div>Sure. Lets say we have a value x of type Int, that we copy from constructor to constructor:</div><div><br></div><div> f (C_i x) = C_j x -- for lots of different i:s and j:s</div><div>
<br>
</div><div>(In practice C_i and C_j most likely have different types.)</div><div><br></div><div>In a program with constructors, C_1 .. C_n, we can do one of three things:</div><div><br></div><div> 1. Unpack no fields.</div>
<div> 2. Unpack some fields.</div><div> 3. Unpack all fields.</div><div><br></div><div>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</div>
<div><br></div><div> * there's no reboxing (lazy functions aside), but</div><div> * we have better cache locality.</div><div><br></div><div>I suspect many large Haskell programs (GHC included) are in state (1) or (2).</div>
<div><br></div><div>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.</div>
<div><br></div><div>Did this make any more sense?</div><div><br></div><div>Cheers,</div><div> Johan</div><div><br></div></div>