Vaildate fails

[Johan Tibell]

I'll take a look!


On Fri, May 3, 2013 at 1:56 AM, Simon Peyton-Jones <simonpj at microsoft.com>wrote:

>  Johan****
>
> ** **
>
> Did you validate before committing -funbox-strict-fields being the default?
> ****
>
> ** **
>
> I’m getting this:****
>
> ** **
>
> Unexpected failures:****
>
>    perf/should_run           T4474a [stat not good enough] (normal)****
>
>    perf/should_run           T4474b [stat not good enough] (normal)****
>
>    perf/should_run           T4474c [stat not good enough] (normal)****
>
>    simplCore/should_compile  T7360 [stderr mismatch] (optasm)****
>
> ** **
>
> The last is certainly caused by -funbox-strict-fields being the default.**
> **
>
> ** **
>
> The first three almost certainly are too, since there is a data type****
>
>     data Tree = Leaf !Int | Fork !Tree !Tree deriving Show****
>
> ** **
>
> In all three cases we allocate 25% more:****
>
> bytes allocated value is too high:****
>
>     Expected    bytes allocated: 3766493912 +/-5%****
>
>     Lower bound bytes allocated: 3578169216 ****
>
>     Upper bound bytes allocated: 3954818608 ****
>
>     Actual      bytes allocated: 4831890456****
>
> ** **
>
> Ironically Trac #4874 is a performance bug that you reported yourself,
> saying that there is too much unnecessary boxing!****
>
> ** **
>
> Would you like to investigate?  Maybe there is another bug to fix?  ****
>
> ** **
>
> I think it’s because “fulllTree” shares all the (I# 1) constants at all
> the leaves, whereas the strict version makes a tree with a 1# at every
> leaf, and allocates an I# box for each of them when it flattens the tree.
> Maybe that is too much a special case to worry about. ****
>
> ** **
>
> Now this may be fine, but it’s certainly worth noting. And if you decide
> it’s acceptable (and you are the Peformance Tsar after all), you need to
> adjust the test bounds.****
>
> ** **
>
> Simon****
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130503/1eec18da/attachment.htm>