#4951: Performance regression 7.0.1 -> 7.0.1.20110201
--------------------------------------+-------------------------------------
Reporter: simonmar | Owner: simonpj
Type: bug | Status: new
Priority: highest | Milestone: 7.0.2
Component: Compiler | Version: 7.0.1
Resolution: | Keywords:
Testcase: | Blockedby:
Difficulty: | Os: Unknown/Multiple
Blocking: | Architecture: Unknown/Multiple
Failure: Runtime performance bug |
--------------------------------------+-------------------------------------
Comment(by simonpj):
Just adding Ian's comments:
Hmm, profiling also doesn't see a difference in allocations:
{{{
- total time = 1.80 secs (90 ticks @ 20 ms)
- total alloc = 585,367,648 bytes (excludes profiling overheads)
+ total time = 1.96 secs (98 ticks @ 20 ms)
+ total alloc = 585,342,752 bytes (excludes profiling overheads)
}}}
The +RTS -Dg output is different. Here's the end of the 6.12.3 output:
{{{
-----------------------------------------------------------------
Gen Max Mut-list Step Blocks Large Live Slop
Blocks Bytes Objects
-----------------------------------------------------------------
0 256 0 0 0 0 0 0
1 2 4 26272 22880
1 256 0 0 1 0 1376 2720
-----------------------------------------------------------------
27648 25600
-----------------------------------------------------------------
}}}
and of the 7.x output:
{{{
----------------------------------------------------------
Gen Max Mut-list Blocks Large Live Slop
Blocks Bytes Objects
----------------------------------------------------------
0 256 0 12 4 34064 15088
1 256 3 260 1 1041232 23728
----------------------------------------------------------
1075296 38816
----------------------------------------------------------
}}}
More live data sounds bad, but it's not obvious to me the two are
necessarily linked.
I'm not convinced everything is being accounted for by ticky. For example,
sm/Storage.c line 572 does TICK_ALLOC_HEAP_NOCTR(n);, but I can't see how
the large object case immediately above is accounted for.
Likewise sm/Storage.c line 652.
There's also a load of stuff commented out in Ticky.c, headed by:
/* krc: comment out some of this stuff temporarily */
I think it would be good to have a less fragile way of doing the
accounting, both for ticky and CCS, e.g. a wrapper for allocGroup that
took the counters to attribute the allocation to.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4951#comment:10>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
