Vaildate fails

[Johan Tibell]

Here's why I think the allocation increase is OK in this case:

Polymorphic data structures (in this case a list) will always have this
problem until we figure out how to unpack polymorphic fields (something
we've discussed in the past). This test (which is for a different issue)
just happens to tickle this problem. If the benchmark performed any
computation at all on the value before they were copied into the list, the
performance wouldn't have changed (as there would have to be Int
allocations anyway).

I've fixed the tests you mentioned and had a second look at the rest. The
rest seems to be a smattering of unrelated failures, which is what I always
see on OS X.


On Fri, May 3, 2013 at 9:21 AM, Johan Tibell <johan.tibell at gmail.com> wrote:

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