#8457: -ffull-laziness does more harm than good -------------------------------------+------------------------------------ Reporter: errge | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by errge): Hi Simon, Thanks for pointing me towards this 'Nestedly Organized Future Improving Benchmarks', they seem to be great. :) I followed http://ghc.haskell.org/trac/ghc/wiki/Building/RunningNoFib and the results are here: https://github.com/errge/notlazy/blob/master/nofib.txt There are some outliers in both directions, but the overall picture seems to me as kind of "nothing changing". Even more if you deduce the noise introduced by the outliers. It may be meaningful to have a look on fulsom, hidden, parser and parstof; these are the examples where the optimization did very good and it would be interesting to see whether it's easy to reintroduce the necessary sharing by hand. OTOH, I'm not really in the mood to debug thousand of lines of old school haskell written in '93 by academics. :-) If we get really bored, maybe will take a look... And there are some outliers on the negative side: constraints, bspt and integer. It'd be interesting to see here if the optimization introduced sharing or other performance bugs can is easy to workaround or not in these cases. My opinion about turning this off didn't change, but I can always just turn off myself, so feel free to either fix this or mark the bug as invalid. If there are more benchmarks to run, I'm happy to run them. Gergely -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8457#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler