[GHC] #7782: flag to run the demand analysis a second time
#7782: flag to run the demand analysis a second time -----------------------------+---------------------------------------------- Reporter: nfrisby | Owner: Type: task | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: 4941, 5302, 6087, 4962 -----------------------------+---------------------------------------------- There are some tickets documenting runtime bugs that can be cleaned up by running the demand analyzer a second time at the end of the pipeline: #4941, #5302, #6087. #6070 ? Others? Here's the effects on nofib. Run time didn't seem to change as drastically. {{{ Allocations ------------------------------------------------------------------------------- Program O2/O2 late-dmd/O2 late-dmd/late-dmd ------------------------------------------------------------------------------- cryptarithm2 25078168 +0.0% +8.0% nucleic2 98331744 +0.0% +3.2% cichelli 80310632 +0.0% -22.9% fasta 401159024 -9.1% -9.1% fulsom 321427240 +0.0% -2.6% k-nucleotide 4125102928 -0.0% -4.8% knights 2037984 +0.0% -3.7% mandel2 1041840 +0.0% -21.4% parstof 3103208 +0.0% -1.4% reverse-complem 155188304 -12.8% -12.8% simple 226412800 -0.0% -1.0% }}} Note that it improves a couple tests significantly just via changes in the base libraries. For cryptarithm2, see my comments on #4941. This might indicate that #4962 should be re-opened. For nucleic2, in var_most_distant_atom, an inlined let grows numerous closures by a significant amount. I'm not sure where to lay the blame for this. Note however, that just making nucleic2's data types use strict !Float fields changes its allocation -72.4%, so maybe this "bad practice" corner case is a small issue. The main remaining task beyond the attached patch is to repair the treatment of wrapper's strictness signatures in .hi files. Because the second demand analysis might change a these signatures, the current compaction mechanism that .hi uses results in ill-formed Core. For the attached patch, I've just disabled that .hi compaction mechanism, but this just needlessly bloats .hi files. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7782 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#7782: flag to run the demand analysis a second time -----------------------------+---------------------------------------------- Reporter: nfrisby | Owner: Type: task | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: #4941, #5302, #6087, #4962 -----------------------------+---------------------------------------------- Changes (by nfrisby): * cc: nfrisby (added) * related: 4941, 5302, 6087, 4962 => #4941, #5302, #6087, #4962 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7782#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#7782: flag to run the demand analysis a second time -------------------------------------------+-------------------------------- Reporter: nfrisby | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: #4941, #5302, #6087, #4962 | -------------------------------------------+-------------------------------- Changes (by simonpj): * difficulty: => Unknown Old description:
There are some tickets documenting runtime bugs that can be cleaned up by running the demand analyzer a second time at the end of the pipeline: #4941, #5302, #6087. #6070 ? Others?
Here's the effects on nofib. Run time didn't seem to change as drastically.
{{{ Allocations
------------------------------------------------------------------------------- Program O2/O2 late-dmd/O2 late-dmd/late-dmd ------------------------------------------------------------------------------- cryptarithm2 25078168 +0.0% +8.0% nucleic2 98331744 +0.0% +3.2%
cichelli 80310632 +0.0% -22.9% fasta 401159024 -9.1% -9.1% fulsom 321427240 +0.0% -2.6% k-nucleotide 4125102928 -0.0% -4.8% knights 2037984 +0.0% -3.7% mandel2 1041840 +0.0% -21.4% parstof 3103208 +0.0% -1.4% reverse-complem 155188304 -12.8% -12.8% simple 226412800 -0.0% -1.0% }}}
Note that it improves a couple tests significantly just via changes in the base libraries.
For cryptarithm2, see my comments on #4941. This might indicate that #4962 should be re-opened.
For nucleic2, in var_most_distant_atom, an inlined let grows numerous closures by a significant amount. I'm not sure where to lay the blame for this. Note however, that just making nucleic2's data types use strict !Float fields changes its allocation -72.4%, so maybe this "bad practice" corner case is a small issue.
The main remaining task beyond the attached patch is to repair the treatment of wrapper's strictness signatures in .hi files. Because the second demand analysis might change a these signatures, the current compaction mechanism that .hi uses results in ill-formed Core. For the attached patch, I've just disabled that .hi compaction mechanism, but this just needlessly bloats .hi files.
New description: There are some tickets documenting runtime bugs that can be cleaned up by running the demand analyzer a second time at the end of the pipeline: #4941, #5302, #6087. #6070 ? Others? Here's the effects on nofib. Run time didn't seem to change as drastically. The "X/Y" column headers mean "library-flags/test-flags" given to GHC when compiling the respective bit. {{{ Allocations ------------------------------------------------------------------------------- Program O2/O2 late-dmd/O2 late-dmd/late-dmd ------------------------------------------------------------------------------- cryptarithm2 25078168 +0.0% +8.0% nucleic2 98331744 +0.0% +3.2% cichelli 80310632 +0.0% -22.9% fasta 401159024 -9.1% -9.1% fulsom 321427240 +0.0% -2.6% k-nucleotide 4125102928 -0.0% -4.8% knights 2037984 +0.0% -3.7% mandel2 1041840 +0.0% -21.4% parstof 3103208 +0.0% -1.4% reverse-complem 155188304 -12.8% -12.8% simple 226412800 -0.0% -1.0% }}} Note that it improves a couple tests significantly just via changes in the base libraries. For cryptarithm2, see my comments on #4941. This might indicate that #4962 should be re-opened. For nucleic2, in var_most_distant_atom, an inlined let grows numerous closures by a significant amount. I'm not sure where to lay the blame for this. Note however, that just making nucleic2's data types use strict !Float fields changes its allocation -72.4%, so maybe this "bad practice" corner case is a small issue. The main remaining task beyond the attached patch is to repair the treatment of wrapper's strictness signatures in .hi files. Because the second demand analysis might change a these signatures, the current compaction mechanism that .hi uses results in ill-formed Core. For the attached patch, I've just disabled that .hi compaction mechanism, but this just needlessly bloats .hi files. -- -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7782#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#7782: flag to run the demand analysis a second time -------------------------------------------+-------------------------------- Reporter: nfrisby | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: #4941, #5302, #6087, #4962 | -------------------------------------------+-------------------------------- Description changed by simonpj: Old description:
There are some tickets documenting runtime bugs that can be cleaned up by running the demand analyzer a second time at the end of the pipeline: #4941, #5302, #6087. #6070 ? Others?
Here's the effects on nofib. Run time didn't seem to change as drastically. The "X/Y" column headers mean "library-flags/test-flags" given to GHC when compiling the respective bit.
{{{ Allocations
------------------------------------------------------------------------------- Program O2/O2 late-dmd/O2 late-dmd/late-dmd ------------------------------------------------------------------------------- cryptarithm2 25078168 +0.0% +8.0% nucleic2 98331744 +0.0% +3.2%
cichelli 80310632 +0.0% -22.9% fasta 401159024 -9.1% -9.1% fulsom 321427240 +0.0% -2.6% k-nucleotide 4125102928 -0.0% -4.8% knights 2037984 +0.0% -3.7% mandel2 1041840 +0.0% -21.4% parstof 3103208 +0.0% -1.4% reverse-complem 155188304 -12.8% -12.8% simple 226412800 -0.0% -1.0% }}}
Note that it improves a couple tests significantly just via changes in the base libraries.
For cryptarithm2, see my comments on #4941. This might indicate that #4962 should be re-opened.
For nucleic2, in var_most_distant_atom, an inlined let grows numerous closures by a significant amount. I'm not sure where to lay the blame for this. Note however, that just making nucleic2's data types use strict !Float fields changes its allocation -72.4%, so maybe this "bad practice" corner case is a small issue.
The main remaining task beyond the attached patch is to repair the treatment of wrapper's strictness signatures in .hi files. Because the second demand analysis might change a these signatures, the current compaction mechanism that .hi uses results in ill-formed Core. For the attached patch, I've just disabled that .hi compaction mechanism, but this just needlessly bloats .hi files.
New description: There are some tickets documenting runtime bugs that can be cleaned up by running the demand analyzer a second time at the end of the pipeline: #4941, #5302, #6087. #6070 ? Others? Here's the effects on nofib. Run time didn't seem to change as drastically. The "X/Y" column headers mean "library-flags/test-flags" given to GHC when compiling the respective bit. {{{ Allocations ------------------------------------------------------------------------------- Program O2/O2 late-dmd+O2/O2 late-dmd+O2 /late-dmd+O2 ------------------------------------------------------------------------------- cryptarithm2 25078168 +0.0% +8.0% nucleic2 98331744 +0.0% +3.2% cichelli 80310632 +0.0% -22.9% fasta 401159024 -9.1% -9.1% fulsom 321427240 +0.0% -2.6% k-nucleotide 4125102928 -0.0% -4.8% knights 2037984 +0.0% -3.7% mandel2 1041840 +0.0% -21.4% parstof 3103208 +0.0% -1.4% reverse-complem 155188304 -12.8% -12.8% simple 226412800 -0.0% -1.0% }}} Note that it improves a couple tests significantly just via changes in the base libraries. For cryptarithm2, see my comments on #4941. This might indicate that #4962 should be re-opened. For nucleic2, in var_most_distant_atom, an inlined let grows numerous closures by a significant amount. I'm not sure where to lay the blame for this. Note however, that just making nucleic2's data types use strict !Float fields changes its allocation -72.4%, so maybe this "bad practice" corner case is a small issue. The main remaining task beyond the attached patch is to repair the treatment of wrapper's strictness signatures in .hi files. Because the second demand analysis might change a these signatures, the current compaction mechanism that .hi uses results in ill-formed Core. For the attached patch, I've just disabled that .hi compaction mechanism, but this just needlessly bloats .hi files. -- -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7782#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#7782: flag to run the demand analysis a second time -------------------------------------------+-------------------------------- Reporter: nfrisby | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: #4941, #5302, #6087, #4962 | -------------------------------------------+-------------------------------- Description changed by simonpj: Old description:
There are some tickets documenting runtime bugs that can be cleaned up by running the demand analyzer a second time at the end of the pipeline: #4941, #5302, #6087. #6070 ? Others?
Here's the effects on nofib. Run time didn't seem to change as drastically. The "X/Y" column headers mean "library-flags/test-flags" given to GHC when compiling the respective bit.
{{{ Allocations
------------------------------------------------------------------------------- Program O2/O2 late-dmd+O2/O2 late-dmd+O2 /late-dmd+O2 ------------------------------------------------------------------------------- cryptarithm2 25078168 +0.0% +8.0% nucleic2 98331744 +0.0% +3.2%
cichelli 80310632 +0.0% -22.9% fasta 401159024 -9.1% -9.1% fulsom 321427240 +0.0% -2.6% k-nucleotide 4125102928 -0.0% -4.8% knights 2037984 +0.0% -3.7% mandel2 1041840 +0.0% -21.4% parstof 3103208 +0.0% -1.4% reverse-complem 155188304 -12.8% -12.8% simple 226412800 -0.0% -1.0% }}}
Note that it improves a couple tests significantly just via changes in the base libraries.
For cryptarithm2, see my comments on #4941. This might indicate that #4962 should be re-opened.
For nucleic2, in var_most_distant_atom, an inlined let grows numerous closures by a significant amount. I'm not sure where to lay the blame for this. Note however, that just making nucleic2's data types use strict !Float fields changes its allocation -72.4%, so maybe this "bad practice" corner case is a small issue.
The main remaining task beyond the attached patch is to repair the treatment of wrapper's strictness signatures in .hi files. Because the second demand analysis might change a these signatures, the current compaction mechanism that .hi uses results in ill-formed Core. For the attached patch, I've just disabled that .hi compaction mechanism, but this just needlessly bloats .hi files.
New description: There are some tickets documenting runtime bugs that can be cleaned up by running the demand analyzer (followed by a simplifier run) a second time at the end of the pipeline: #4941, #5302, #6087. #6070 ? Others? Here's the effects on nofib. Run time didn't seem to change as drastically. The "X/Y" column headers mean "library-flags/test-flags" given to GHC when compiling the respective bit. {{{ Allocations ------------------------------------------------------------------------------- Program O2/O2 late-dmd+O2/O2 late-dmd+O2 /late-dmd+O2 ------------------------------------------------------------------------------- cryptarithm2 25078168 +0.0% +8.0% nucleic2 98331744 +0.0% +3.2% cichelli 80310632 +0.0% -22.9% fasta 401159024 -9.1% -9.1% fulsom 321427240 +0.0% -2.6% k-nucleotide 4125102928 -0.0% -4.8% knights 2037984 +0.0% -3.7% mandel2 1041840 +0.0% -21.4% parstof 3103208 +0.0% -1.4% reverse-complem 155188304 -12.8% -12.8% simple 226412800 -0.0% -1.0% }}} Note that it improves a couple tests significantly just via changes in the base libraries. For cryptarithm2, see my comments on #4941. This might indicate that #4962 should be re-opened. For nucleic2, in var_most_distant_atom, an inlined let grows numerous closures by a significant amount. I'm not sure where to lay the blame for this. Note however, that just making nucleic2's data types use strict !Float fields changes its allocation -72.4%, so maybe this "bad practice" corner case is a small issue. The main remaining task beyond the attached patch is to repair the treatment of wrapper's strictness signatures in .hi files. Because the second demand analysis might change a these signatures, the current compaction mechanism that .hi uses results in ill-formed Core. For the attached patch, I've just disabled that .hi compaction mechanism, but this just needlessly bloats .hi files. -- -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7782#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#7782: flag to run the demand analysis a second time -------------------------------------------+-------------------------------- Reporter: nfrisby | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: #4941, #5302, #6087, #4962 | -------------------------------------------+-------------------------------- Description changed by simonpj: Old description:
There are some tickets documenting runtime bugs that can be cleaned up by running the demand analyzer (followed by a simplifier run) a second time at the end of the pipeline: #4941, #5302, #6087. #6070 ? Others?
Here's the effects on nofib. Run time didn't seem to change as drastically. The "X/Y" column headers mean "library-flags/test-flags" given to GHC when compiling the respective bit.
{{{ Allocations
------------------------------------------------------------------------------- Program O2/O2 late-dmd+O2/O2 late-dmd+O2 /late-dmd+O2 ------------------------------------------------------------------------------- cryptarithm2 25078168 +0.0% +8.0% nucleic2 98331744 +0.0% +3.2%
cichelli 80310632 +0.0% -22.9% fasta 401159024 -9.1% -9.1% fulsom 321427240 +0.0% -2.6% k-nucleotide 4125102928 -0.0% -4.8% knights 2037984 +0.0% -3.7% mandel2 1041840 +0.0% -21.4% parstof 3103208 +0.0% -1.4% reverse-complem 155188304 -12.8% -12.8% simple 226412800 -0.0% -1.0% }}}
Note that it improves a couple tests significantly just via changes in the base libraries.
For cryptarithm2, see my comments on #4941. This might indicate that #4962 should be re-opened.
For nucleic2, in var_most_distant_atom, an inlined let grows numerous closures by a significant amount. I'm not sure where to lay the blame for this. Note however, that just making nucleic2's data types use strict !Float fields changes its allocation -72.4%, so maybe this "bad practice" corner case is a small issue.
The main remaining task beyond the attached patch is to repair the treatment of wrapper's strictness signatures in .hi files. Because the second demand analysis might change a these signatures, the current compaction mechanism that .hi uses results in ill-formed Core. For the attached patch, I've just disabled that .hi compaction mechanism, but this just needlessly bloats .hi files.
New description: There are some tickets documenting runtime bugs that can be cleaned up by running the demand analyzer (followed by a simplifier run) a second time at the end of the pipeline: #4941, #5302, #6087. #6070 ? Others? Here's the effects on nofib. Run time didn't seem to change as drastically. The "X/Y" column headers mean "library-flags/test-flags" given to GHC when compiling the respective bit. {{{ Allocations ------------------------------------------------------------------------------- Program O2/O2 late-dmd+O2/O2 late-dmd+O2 /late-dmd+O2 ------------------------------------------------------------------------------- cryptarithm2 25078168 +0.0% +8.0% nucleic2 98331744 +0.0% +3.2% cichelli 80310632 +0.0% -22.9% fasta 401159024 -9.1% -9.1% fulsom 321427240 +0.0% -2.6% k-nucleotide 4125102928 -0.0% -4.8% knights 2037984 +0.0% -3.7% mandel2 1041840 +0.0% -21.4% parstof 3103208 +0.0% -1.4% reverse-complem 155188304 -12.8% -12.8% simple 226412800 -0.0% -1.0% }}} Note that it improves a couple tests significantly just via changes in the base libraries. For cryptarithm2, (cf remarks in #4941) * 4% increase allocation is due to reboxing * 4% is due to dead closures, because the fix in #4962 isn't working for some reason. For nucleic2, in var_most_distant_atom, an inlined let grows numerous closures by a significant amount. I'm not sure where to lay the blame for this. Note however, that just making nucleic2's data types use strict !Float fields changes its allocation -72.4%, so maybe this "bad practice" corner case is a small issue. The main remaining task beyond the attached patch is to repair the treatment of wrapper's strictness signatures in .hi files. Because the second demand analysis might change a these signatures, the current compaction mechanism that .hi uses results in ill-formed Core. For the attached patch, I've just disabled that .hi compaction mechanism, but this just needlessly bloats .hi files. -- -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7782#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#7782: flag to run the demand analysis a second time -------------------------------------------+-------------------------------- Reporter: nfrisby | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: #4941, #5302, #6087, #4962 | -------------------------------------------+-------------------------------- Description changed by simonpj: Old description:
There are some tickets documenting runtime bugs that can be cleaned up by running the demand analyzer (followed by a simplifier run) a second time at the end of the pipeline: #4941, #5302, #6087. #6070 ? Others?
Here's the effects on nofib. Run time didn't seem to change as drastically. The "X/Y" column headers mean "library-flags/test-flags" given to GHC when compiling the respective bit.
{{{ Allocations
------------------------------------------------------------------------------- Program O2/O2 late-dmd+O2/O2 late-dmd+O2 /late-dmd+O2 ------------------------------------------------------------------------------- cryptarithm2 25078168 +0.0% +8.0% nucleic2 98331744 +0.0% +3.2%
cichelli 80310632 +0.0% -22.9% fasta 401159024 -9.1% -9.1% fulsom 321427240 +0.0% -2.6% k-nucleotide 4125102928 -0.0% -4.8% knights 2037984 +0.0% -3.7% mandel2 1041840 +0.0% -21.4% parstof 3103208 +0.0% -1.4% reverse-complem 155188304 -12.8% -12.8% simple 226412800 -0.0% -1.0% }}}
Note that it improves a couple tests significantly just via changes in the base libraries.
For cryptarithm2, (cf remarks in #4941) * 4% increase allocation is due to reboxing * 4% is due to dead closures, because the fix in #4962 isn't working for some reason.
For nucleic2, in var_most_distant_atom, an inlined let grows numerous closures by a significant amount. I'm not sure where to lay the blame for this. Note however, that just making nucleic2's data types use strict !Float fields changes its allocation -72.4%, so maybe this "bad practice" corner case is a small issue.
The main remaining task beyond the attached patch is to repair the treatment of wrapper's strictness signatures in .hi files. Because the second demand analysis might change a these signatures, the current compaction mechanism that .hi uses results in ill-formed Core. For the attached patch, I've just disabled that .hi compaction mechanism, but this just needlessly bloats .hi files.
New description: There are some tickets documenting runtime bugs that can be cleaned up by running the demand analyzer (followed by a simplifier run) a second time at the end of the pipeline: #4941, #5302, #6087. #6070 ? Others? Here's the effects on nofib. Run time didn't seem to change as drastically. The "X/Y" column headers mean "library-flags/test-flags" given to GHC when compiling the respective bit. {{{ Allocations ------------------------------------------------------------------------------- Program O2/O2 late-dmd+O2/O2 late-dmd+O2 /late-dmd+O2 ------------------------------------------------------------------------------- cryptarithm2 25078168 +0.0% +8.0% nucleic2 98331744 +0.0% +3.2% cichelli 80310632 +0.0% -22.9% fasta 401159024 -9.1% -9.1% fulsom 321427240 +0.0% -2.6% k-nucleotide 4125102928 -0.0% -4.8% knights 2037984 +0.0% -3.7% mandel2 1041840 +0.0% -21.4% parstof 3103208 +0.0% -1.4% reverse-complem 155188304 -12.8% -12.8% simple 226412800 -0.0% -1.0% }}} Note that it improves a couple tests significantly just via changes in the base libraries. For cryptarithm2, (cf remarks in #4941) * 4% increase allocation is due to reboxing * 4% is due to dead closures, because the fix in #4962 isn't working for some reason. For nucleic2, in var_most_distant_atom, an let-bound function is inlined after w/w, and hence grows numerous closures by a significant amount. I'm not sure where to lay the blame for this. Note however, that just making nucleic2's data types use strict !Float fields changes its allocation -72.4%, so maybe this "bad practice" corner case is a small issue. The main remaining task beyond the attached patch is to repair the treatment of wrapper's strictness signatures in .hi files. Because the second demand analysis might change a these signatures, the current compaction mechanism that .hi uses results in ill-formed Core. For the attached patch, I've just disabled that .hi compaction mechanism, but this just needlessly bloats .hi files. -- -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7782#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#7782: flag to run the demand analysis a second time -------------------------------------------+-------------------------------- Reporter: nfrisby | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: #4941, #5302, #6087, #4962 | -------------------------------------------+-------------------------------- Description changed by simonpj: Old description:
There are some tickets documenting runtime bugs that can be cleaned up by running the demand analyzer (followed by a simplifier run) a second time at the end of the pipeline: #4941, #5302, #6087. #6070 ? Others?
Here's the effects on nofib. Run time didn't seem to change as drastically. The "X/Y" column headers mean "library-flags/test-flags" given to GHC when compiling the respective bit.
{{{ Allocations
------------------------------------------------------------------------------- Program O2/O2 late-dmd+O2/O2 late-dmd+O2 /late-dmd+O2 ------------------------------------------------------------------------------- cryptarithm2 25078168 +0.0% +8.0% nucleic2 98331744 +0.0% +3.2%
cichelli 80310632 +0.0% -22.9% fasta 401159024 -9.1% -9.1% fulsom 321427240 +0.0% -2.6% k-nucleotide 4125102928 -0.0% -4.8% knights 2037984 +0.0% -3.7% mandel2 1041840 +0.0% -21.4% parstof 3103208 +0.0% -1.4% reverse-complem 155188304 -12.8% -12.8% simple 226412800 -0.0% -1.0% }}}
Note that it improves a couple tests significantly just via changes in the base libraries.
For cryptarithm2, (cf remarks in #4941) * 4% increase allocation is due to reboxing * 4% is due to dead closures, because the fix in #4962 isn't working for some reason.
For nucleic2, in var_most_distant_atom, an let-bound function is inlined after w/w, and hence grows numerous closures by a significant amount. I'm not sure where to lay the blame for this. Note however, that just making nucleic2's data types use strict !Float fields changes its allocation -72.4%, so maybe this "bad practice" corner case is a small issue.
The main remaining task beyond the attached patch is to repair the treatment of wrapper's strictness signatures in .hi files. Because the second demand analysis might change a these signatures, the current compaction mechanism that .hi uses results in ill-formed Core. For the attached patch, I've just disabled that .hi compaction mechanism, but this just needlessly bloats .hi files.
New description: There are some tickets documenting runtime bugs that can be cleaned up by running the demand analyzer (followed by a simplifier run) a second time at the end of the pipeline: #4941, #5302, #6087. #6070 ? Others? Here's the effects on nofib. Run time didn't seem to change as drastically. The "X/Y" column headers mean "library-flags/test-flags" given to GHC when compiling the respective bit. {{{ Allocations ------------------------------------------------------------------------------- Program O2/O2 late-dmd+O2/O2 late-dmd+O2 /late-dmd+O2 ------------------------------------------------------------------------------- cryptarithm2 25078168 +0.0% +8.0% nucleic2 98331744 +0.0% +3.2% cichelli 80310632 +0.0% -22.9% fasta 401159024 -9.1% -9.1% fulsom 321427240 +0.0% -2.6% k-nucleotide 4125102928 -0.0% -4.8% knights 2037984 +0.0% -3.7% mandel2 1041840 +0.0% -21.4% parstof 3103208 +0.0% -1.4% reverse-complem 155188304 -12.8% -12.8% simple 226412800 -0.0% -1.0% }}} All other changes less than 1% allocation. Note that it improves a couple tests significantly just via changes in the base libraries. For cryptarithm2, (cf remarks in #4941) * 4% increase allocation is due to reboxing * 4% is due to dead closures, because the fix in #4962 isn't working for some reason. For nucleic2, in var_most_distant_atom, an let-bound function is inlined after w/w, and hence grows numerous closures by a significant amount. I'm not sure where to lay the blame for this. Note however, that just making nucleic2's data types use strict !Float fields changes its allocation -72.4%, so maybe this "bad practice" corner case is a small issue. The main remaining task beyond the attached patch is to repair the treatment of wrapper's strictness signatures in .hi files. Because the second demand analysis might change a these signatures, the current compaction mechanism that .hi uses results in ill-formed Core. For the attached patch, I've just disabled that .hi compaction mechanism, but this just needlessly bloats .hi files. -- -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7782#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#7782: flag to run the demand analysis a second time -------------------------------------------+-------------------------------- Reporter: nfrisby | Owner: nfrisby Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: #4941, #5302, #6087, #4962 | -------------------------------------------+-------------------------------- Changes (by nfrisby): * owner: => nfrisby -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7782#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#7782: flag to run the demand analysis a second time -------------------------------------------+-------------------------------- Reporter: nfrisby | Owner: nfrisby Type: task | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: #4941, #5302, #6087, #4962 | -------------------------------------------+-------------------------------- Changes (by igloo): * milestone: => 7.8.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7782#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC