GHC compiled program slower with -O1 than -O0
Hi, I've written a Haskell program which goes slower with -O1 (19 seconds) than -O0 (12 seconds). Is this considered to be a bug? How interested are you in tracking this down? The problem is that the code is not yet released, depends on Yhc (both the libraries and the binary), a few other modules and may well be a nightmare to reproduce. Even once its reproduced, its a reasonably large program (52 modules), so isn't going to be particularly fun. Are you interested in details of how to reproduce, or shall I wait until I release the program and you have a more stable set of programs to work against? Thanks Neil
| I've written a Haskell program which goes slower with -O1 (19 seconds) | than -O0 (12 seconds). Is this considered to be a bug? How interested | are you in tracking this down? Yes, very interested. Should not happen. One thing to check is heap usage and GC time. Does GC time, or residency (both reported by -Sstderr) go up a lot? It's possible that an optimisation is changing space behaviour for the worse. Does it still happen if you use profiling? If so, the profile should narrow down the culprit a lot. That might avoid the need to reproduce it elsewhere. Simon
Hi Simon
One thing to check is heap usage and GC time. Does GC time, or residency (both reported by -Sstderr) go up a lot? It's possible that an optimisation is changing space behaviour for the worse.
I've attached the logs for both -O0 (norm) and -O1 (opt), it appears that there are 4 times more garbage collections with -O1, so thats likely to be it.
Does it still happen if you use profiling? If so, the profile should narrow down the culprit a lot. That might avoid the need to reproduce it elsewhere.
Profiling with -O1 is faster than -O1 and -O0, so turning on profiling fixes whatever is going wrong. The darcs repo for the code is at: http://www.cs.york.ac.uk/fp/darcs/catch/ This is the catch_1 directory. Unfortunately it will be a nightmare to build... Thanks Neil
Neil Mitchell wrote:
Hi Simon
One thing to check is heap usage and GC time. Does GC time, or residency (both reported by -Sstderr) go up a lot? It's possible that an optimisation is changing space behaviour for the worse.
I've attached the logs for both -O0 (norm) and -O1 (opt), it appears that there are 4 times more garbage collections with -O1, so thats likely to be it.
Does it still happen if you use profiling? If so, the profile should narrow down the culprit a lot. That might avoid the need to reproduce it elsewhere.
Profiling with -O1 is faster than -O1 and -O0, so turning on profiling fixes whatever is going wrong.
The darcs repo for the code is at:
http://www.cs.york.ac.uk/fp/darcs/catch/
This is the catch_1 directory. Unfortunately it will be a nightmare to build...
There are two things that I know of that can cause this. The first is the bug that affects calendar from nofib: http://hackage.haskell.org/trac/ghc/ticket/1168 and the second is full-laziness, which can give your program a space leak if you compile with -O. You'll be able to tell if it's a space leak problem by looking at the "+RTS -sstderr" output and checking the GC time. Cheers, Simon
participants (3)
-
Neil Mitchell -
Simon Marlow -
Simon Peyton-Jones