Opened 15 months ago

Last modified 15 months ago

#9232 new bug

Stats file has wrong numbers

Reported by: augustss Owned by: simonmar
Priority: low Milestone:
Component: Runtime System Version: 7.8.2
Keywords: Cc: simonmar
Operating System: Windows Architecture: Unknown/Multiple
Type of failure: Other Test Case:
Blocked By: Blocking:
Related Tickets: Differential Revisions:

Description

The summary numbers in the file generated with the -S flag cannot be right. Here's an example:

   1,943,795,468 bytes allocated in the heap
  17,587,189,232 bytes copied during GC

The corresponding numbers with ghc 7.2 are

 193,859,474,520 bytes allocated in the heap
  17,766,908,288 bytes copied during GC

While it's theoretically possible that allocation has improved that much, I don't believe it.

Attachments (2)

stats76.risk.2 (111.9 KB) - added by augustss 15 months ago.
ghc 7.6 stats file
stats78.risk.2 (115.7 KB) - added by augustss 15 months ago.
ghc 7.8 stats file

Download all attachments as: .zip

Change History (7)

comment:1 Changed 15 months ago by simonpj

Does time improve? Does allocation rate change?

It's unusual, but entirely possible. Eg better let-floating or whatnot.

Simon

comment:2 Changed 15 months ago by augustss

No, the overall time is worse. And the number of garbage collections has increased.

ghc 7.6:

  Gen  0      1389 colls,     0 par   60.28s   60.75s     0.0437s    0.6840s
  Gen  1        21 colls,     0 par   27.11s   27.68s     1.3182s    4.0802s

ghc 7.8:

  Gen  0      1438 colls,     0 par   58.84s   58.68s     0.0408s    0.6828s
  Gen  1        21 colls,     0 par   29.31s   30.59s     1.4566s    4.5564s

comment:3 Changed 15 months ago by simonpj

OK, so the displayed allocation rate (displayed by -S) must be much, much, much lower? After all, you are saying that GHC 7.8 allocates 100x less data, but takes longer, so the allocation rate must be much lower too.

Would you like to show the actual output?

A useful thing to do is to compile everything (libraries and all, ideally, but not essential) with -ticky. That has no effect on optimisation but does gather per-function allocation counts. Then run with +RTS -rfoo.ticky. Results in file foo.ticky.

Simon

comment:4 Changed 15 months ago by simonmar

We know that this isn't happening consistently, because our allocation measurements for e.g. nofib runs aren't showing any weirdness. Which means it's something more specific. I take it you can't share the program, and don't have a smaller example that demonstrates the problem?

Changed 15 months ago by augustss

ghc 7.6 stats file

Changed 15 months ago by augustss

ghc 7.8 stats file

comment:5 Changed 15 months ago by augustss

Sorry, we can't share the program. If I have time I'll try the -ticky. I'm not very concerned about this bug, but I do keep an eye on allocation numbers when making changes.

Note: See TracTickets for help on using tickets.