fannkuch-redux allocations increase by factor of 10000 between 7.4.2 and 7.6.3

In a recent look at historical nofib trends I noticed that fannkuck-redux appears to regress an almost unbelievable amount in its allocations, == 7.6.3 ==

<<ghc: 870987952 bytes, 1668 GCs (1666 + 2),
  0/0 avg/max bytes residency (0 samples),
  84640 bytes GC work, 1M in use,
  0.00 INIT (0.00 elapsed), 2.43 MUT (2.43 elapsed), 0.00 GC (0.00 elapsed),
  0.00 GC(0) (0.00 elapsed), 0.00 GC(1) (0.00 elapsed), 1 balance :ghc>>

7.4.2

<<ghc: 74944 bytes, 1 GCs (0 + 1),
  0/0 avg/max bytes residency (0 samples),
  3512 bytes GC work, 1M in use,
  0.00 INIT (0.00 elapsed), 2.25 MUT (2.25 elapsed), 0.00 GC (0.00 elapsed),
  0.00 GC(0) (0.00 elapsed), 0.00 GC(1) (0.00 elapsed), 1 balance :ghc>>

Given that [FoldrBuildNotes] suggests that this test is quite sensitive to fusion, I suspect something broke here.

Trac metadata

Trac field	Value
Version	7.6.3
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture

changed weight to 5

added Tbug Trac import labels

changed title from fannkuch-redux allocations increase 10000% between 7.4.2 and 7.6.3 to fannkuch-redux allocations increase by factor of 10000 between 7.4.2 and 7.6.3

Yes, please investigate!!

I'm now looking at the ticky output from the testcase run with argument 11 after having confirmed that compiling with -prof kills the effect (both compilers produce executables which allocate heavily).

The ticky output shows a pretty clear difference.

7.6

ENTERS: 1178454454  of which 1178454454 (100.0%) direct to the entry code
		  [the rest indirected via Node's info ptr]
36288010 (  3.1%) thunks
      0 (  0.0%) data values
      0 (  0.0%) normal indirections
      0 (  0.0%) permanent indirections

...

RETURNS: 354136250
36288000 ( 10.2%) from entering a new constructor
		  [the rest from entering an existing constructor]

UPDATE FRAMES: 36288007 (0 omitted from thunks)
...

    Entries     Allocs  Arity Stack    Kinds      Function                      
--------------------------------------------------------------------------------
...
   39916804  108864012      4     0    iiiA       $wa3{v s3Cl} (main:Main)      

7.4

ENTERS: 1142166456  of which 1142166456 (100.0%) direct to the entry code
		  [the rest indirected via Node's info ptr]
     10 (  0.0%) thunks
      0 (  0.0%) data values
      0 (  0.0%) normal indirections
      0 (  0.0%) permanent indirections

...

RETURNS: 317848252
      0 (  0.0%) from entering a new constructor
		  [the rest from entering an existing constructor]

UPDATE FRAMES: 7 (0 omitted from thunks)
...

    Entries     Allocs  Arity Stack    Kinds      Function                      
--------------------------------------------------------------------------------
...
   39916804         12      4     0    iiiA       $wa3{v s3ad} (main:Main)      

Here are the STG definitions of the s3Cl and s3ad.

Don't forget to check for which rules fired -fddump-rule-firings. Missing a fusion rule is a big deal

This was discussed in #7367 though without a real conclusion.

Oh yes -- so this is essential a duplicate ticket? If so let's close in favour of the longer discussion there

closed

Finally getting back to this after my ISP decided to "fix" my connection.

Hmmm, I sometimes do wish Trac's search were a bit better. Closing in favor of #7367.

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedDuplicate
Related	- → #7367

changed milestone to %8.0.1

Milestone renamed

added runtime perf label

added Pnormal label