#2002: problems with very large (list) literals
------------------------------------------+---------------------------------
Reporter: Isaac Dupree | Owner: simonmar
Type: compile-time performance bug | Status: new
Priority: high | Milestone: 6.10 branch
Component: Compiler | Version: 6.8.2
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Testcase: | Architecture: x86
Os: Linux |
------------------------------------------+---------------------------------
Comment (by Isaac Dupree):
-O0 -fasm succeeded within 3 minutes and 400 MB RAM or so.
{{{
./compiler/stage1/ghc-inplace -no-user-package-conf -H128m -O0 -fasm
-istage2/utils -istage2/basicTypes -istage2/types -istage2/hsSyn
-istage2/prelude -istage2/rename -istage2/typecheck -istage2/deSugar
-istage2/coreSyn -istage2/vectorise -istage2/specialise
-istage2/simplCore -istage2/stranal -istage2/stgSyn -istage2/simplStg
-istage2/codeGen -istage2/main -istage2/profiling -istage2/parser
-istage2/cprAnalysis -istage2/iface -istage2/cmm -istage2/nativeGen
-istage2/ghci -Wall -fno-warn-name-shadowing -fno-warn-orphans -Istage2
-package hpc -package bytestring -DGHCI -package template-haskell
-DGHCI_TABLES_NEXT_TO_CODE -I../libffi/build/include -cpp -fglasgow-exts
-fno-generics -Rghc-timing -I. -Iparser -Iutil -package unix -package
Cabal -ignore-package lang -recomp -Rghc-timing -O0 -fasm -DDEBUG -H16M
'-#include "cutils.h"' -package-name ghc-6.9.20080602 -fgenerics
-funbox-strict-fields -c parser/Lexer.hs -o stage2/parser/Lexer.o -ohi
stage2/parser/Lexer.hi
Binary: expanding to size: 6144
Binary: expanding to size: 6144
Binary: expanding to size: 6144
Binary: expanding to size: 6144
<<ghc: 26187464736 bytes, 49463 GCs, 24378379/237682688 avg/max bytes
residency (89 samples), 562M in use, 0.00 INIT (0.08 elapsed), 63.18 MUT
(77.00 elapsed), 67.19 GC (68.44 elapsed) :ghc>>
}}}
new summary:
-O0 -fasm completely works, though it's slower than ideal.
-O0 -fvia-C dies because GCC isn't prepared for how much we're throwing at
it. Seems hard for us to fix: lucky we're working on the NCG (though
possibly ghc -O would simplify the generated C code enough for GCC to
survive, but that'd be IMHO unlikely in this case). (though I wonder if
the GCC people know, or should know, that their compiler behaves poorly in
these artificial-but-real cases)
-O takes way too long (I only thoroughly tested -O with -fasm, so the slow
optimizations could be Core, Cmm, anything; and maybe it succeeds in an
hour's time, I don't know, would you like me to test on my computer for up
to a whole day?). I'm not entirely surprised, but it's still a somewhat
serious bug from my point of view.
-Isaac
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2002#comment:12>
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
