Vaildate fails

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Vaildate fails

Simon Peyton Jones
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/cbab580b/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

Vaildate fails

Johan Tibell-2
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>

Reply | Threaded
Open this post in threaded view
|

Vaildate fails

Johan Tibell-2
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>