#1945: Faulty optimizations
----------------------+-----------------------------------------------------
Reporter: jleedev | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 6.8.1
Severity: normal | Keywords:
Testcase: | Architecture: Unknown
Os: Unknown |
----------------------+-----------------------------------------------------
I've found a case where the optimizer produces code that uses more memory
and runs slower. Here's an example that contrasts the default behavior
with the optimized behavior. Cale posted a comparison of GHC's core on
this program (using 6.8.1) on http://hpaste.org/4133#a1.
Without optimizations: Both print statements take the same (fairly short)
amount of time. [[BR]]
With optimizations: The first print statement takes a lot longer, but
second happens very quickly.
Essentially, it is caching the entire 10 million item list, instead of
just its length.
{{{
$ cat test.hs
f x = length [0 .. x :: Int]
main = do
print $ f 10000000
print $ f 10000000
$ time runhaskell test.hs
10000001
10000001
real 0m0.682s
user 0m0.636s
sys 0m0.044s
$ ghc --make test
[1 of 1] Compiling Main ( test.hs, test.o )
Linking test ...
$ time ./test
10000001
10000001
real 0m0.438s
user 0m0.428s
sys 0m0.008s
$ rm test test.hi test.o
$ ghc --make test -O
[1 of 1] Compiling Main ( test.hs, test.o )
Linking test ...
$ time ./test
10000001
10000001
real 0m2.447s
user 0m2.200s
sys 0m0.224s
}}}
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1945>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
