Re: [GHC] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7 +--- Reporter: daniel.is.fischer | Owner: Type: bug| Status: closed Priority: normal | Milestone: 7.0.1 Component: Compiler |Version: 7.1 Resolution: fixed | Keywords: executable size Testcase: | Blockedby: Difficulty: | Os: Linux Blocking: | Architecture: x86 Failure: Other | +--- Changes (by igloo): * status: merge = closed * resolution: = fixed Comment: Both merged. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#comment:39 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
Re: [GHC] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7 --+- Reporter: daniel.is.fischer |Owner: Type: bug| Status: new Priority: normal |Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords: executable size| Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: Other --+- Comment(by simonmar): Replying to [comment:30 rl]: I thought that `collect2` automates this. IIRC, it ploughs through all object files looking for specific constructor symbols and then generates and links in an additional module which calls those symbols and is, in turn, called at start up. Wouldn't it be enough to simply make sure that module initialiser symbols look like constructors and link with `collect2`? Right, and we're already doing that for the foreign export initailisers. We could use this method for the profiling initialisers too, but it would mean compiling a C stub file with every Haskell module. That may be the only way though. We could introduce a package ghc-annotations which would only define the annotation types and which both vector and ghc would depend on. Presumably, linking in ghc-annotations would have no impact on binary sizes. FWIW, I would be in favour of doing this anyway because I've had several complaints about vector depending on package ghc. I think this is a good plan. In the long term we should fix the initialisers, but this gives us a short term workaround while we think about the best way to handle initialisers. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#comment:34 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
Re: [GHC] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7 --+- Reporter: daniel.is.fischer |Owner: Type: bug| Status: new Priority: normal |Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords: executable size| Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: Other --+- Comment(by rl): Replying to [comment:34 simonmar]: Right, and we're already doing that for the foreign export initailisers. We could use this method for the profiling initialisers too, but it would mean compiling a C stub file with every Haskell module. That may be the only way though. I'm probably being a bit dense but why do we need a separate C file? Can't we just have GHC generate the initialisers and put them in the same object file as the rest of the module? I think this is a good plan. In the long term we should fix the initialisers, but this gives us a short term workaround while we think about the best way to handle initialisers. Great! I think we only use `SpecConstrAnnotation`, defined in !SpecConstr.lhs, at the moment. It would be great if we could add ghc- annotations before the next release candidate. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#comment:35 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
Re: [GHC] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7 --+- Reporter: daniel.is.fischer |Owner: Type: bug| Status: new Priority: normal |Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords: executable size| Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: Other --+- Comment(by simonpj): OK, here's the plan: * For GHC 7.0 we will add the `SpecConstr` type (which is very small) to `GHC.Exts`. That should eliminate the blow-up for clients of `vector`. * However the main point remains. For 7.2 we'll think about a more systematic solution using the module-initialisation mechanisms built into the system linker Concerning the latter, the main sticking point is that linker constructors must have a C API, and our native code generators don't know how to generate C-callable procedures. The right thing may be to generate a C stub file. (The LLVM back end should not have this problem.) Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#comment:36 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
Re: [GHC] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7
--+-
Reporter: daniel.is.fischer |Owner:
Type: bug| Status: merge
Priority: normal |Milestone: 7.0.1
Component: Compiler | Version: 7.1
Keywords: executable size| Testcase:
Blockedby: | Difficulty:
Os: Linux | Blocking:
Architecture: x86| Failure: Other
--+-
Changes (by simonpj):
* status: new = merge
Comment:
OK first part (putting `SpecConstrAnnotation` in `GHC.Exts` is done),
which is enough for 7.0. I'll mark this as merge for now; then back to
'new' for part 2!
{{{
Mon Oct 18 06:57:46 PDT 2010 simo...@microsoft.com
* Define SpecConstrAnnotation in GHC.Exts, and import it from there
Reason: avoid having to link the entire ghc package in modules
that use compile-time annotations:
import GHC.Exts( SpecConstrAnnotation )
{-# ANN type T ForceSpecConstr #-}
It's a kind of bug that the package exporting SpecConstrAnnotation
is linked even though it is only needed at compile time, but putting
the data type declaration in GHC.Exts is a simple way to sidestep
the problem
See See Note [SpecConstrAnnotation] in SpecConstr
M ./compiler/specialise/SpecConstr.lhs -37 +56
}}}
There's a similar patch in `base`:
{{{
Mon Oct 18 06:58:57 PDT 2010 simo...@microsoft.com
* Define SpecConstrAnnotation in GHC.Exts, and import it from there
Reason: avoid having to link the entire ghc package in modules
that use compile-time annotations:
import GHC.Exts( SpecConstrAnnotation )
{-# ANN type T ForceSpecConstr #-}
It's a kind of bug that the package exporting SpecConstrAnnotation
is linked even though it is only needed at compile time, but putting
the data type declaration in GHC.Exts is a simple way to sidestep
the problem
See See Note [SpecConstrAnnotation] in SpecConstr
M ./GHC/Exts.hs -1 +24
}}}
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#comment:37
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
Re: [GHC] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7 --+- Reporter: daniel.is.fischer |Owner: igloo Type: bug| Status: new Priority: normal |Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords: executable size| Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: Other --+- Comment(by rl): How likely is it that this will be fixed in time for 7.0? If it won't be fixed, we have a couple of alternatives. 1. I could remove !SpecConstr annotations from vector for now. I would rather avoid that if at all possible because they are necessary for performance. Also, we can't do this for DPH because we really depend on `NoSpecConstr` there. 2. We could change the annotations to strings. That is, `ForceSpecConstr` would become `ForceSpecConstr` and !SpecConstr would look out for such annotations. Then, vector (and DPH) wouldn't import anything from package ghc. 3. We could introduce a package ghc-annotations which would only define the annotation types and which both vector and ghc would depend on. Presumably, linking in ghc-annotations would have no impact on binary sizes. FWIW, I would be in favour of doing this anyway because I've had several complaints about vector depending on package ghc. What would GHC HQ prefer? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#comment:32 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
Re: [GHC] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7 --+- Reporter: daniel.is.fischer |Owner: Type: bug| Status: new Priority: normal |Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords: executable size| Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: Other --+- Changes (by igloo): * owner: igloo = -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#comment:33 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
Re: [GHC] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7 --+- Reporter: daniel.is.fischer |Owner: igloo Type: bug| Status: new Priority: highest|Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords: executable size| Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: Other --+- Comment(by rl): I doubt it's the fusion framework (which does work, just not as well as it used to before the typechecker patch). If the ghc package is getting linked in then that is probably the reason for the binary size. The package is only used for one thing by vector: annotations to drive !SpecConstr. That is, I only use a single data type and no functions from package ghc. Why would GHC link in the entire package in that case? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#comment:13 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
Re: [GHC] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7 --+- Reporter: daniel.is.fischer |Owner: igloo Type: bug| Status: new Priority: highest|Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords: executable size| Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: Other --+- Comment(by simonpj): Moreover, the annotations stuff, and hence the `ghc` package is only used at ''compile time''. So it should not be linked at run time. There should be literally no references to `ghc` in the `.o` files, so it should not be linked at all. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#comment:14 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
Re: [GHC] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7
--+-
Reporter: daniel.is.fischer |Owner: igloo
Type: bug| Status: new
Priority: highest|Milestone: 7.0.1
Component: Compiler | Version: 7.1
Keywords: executable size| Testcase:
Blockedby: | Difficulty:
Os: Linux | Blocking:
Architecture: x86| Failure: Other
--+-
Comment(by daniel.is.fischer):
FWIW:
{{{
$ ghc -O2 -package vector-0.7 -package base-4.2.0.2 -o aaa6 aaavec.hs
$ ls -l | grep aaa6
-rwxr-xr-x 1 dafis users 1115927 15. Okt 12:16 aaa6
$ nm aaa6 | wc -l
10110
$ nm aaa6 | grep ghc | wc -l
65
$ ~/Haskell/Hacking/bin/ghc -O2 --make aaavec.hs -o aaa7
$ ls -l | grep aaa7
-rwxr-xr-x 1 dafis users 29180744 15. Okt 12:17 aaa7
$ nm aaa7 | wc -l
332020
$ nm aaa7 | grep ghc | wc -l
65413
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#comment:15
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
Re: [GHC] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7 --+- Reporter: daniel.is.fischer |Owner: igloo Type: bug| Status: new Priority: highest|Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords: executable size| Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: Other --+- Comment(by rl): What happens with -O0? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#comment:16 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
Re: [GHC] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7
--+-
Reporter: daniel.is.fischer |Owner: igloo
Type: bug| Status: new
Priority: highest|Milestone: 7.0.1
Component: Compiler | Version: 7.1
Keywords: executable size| Testcase:
Blockedby: | Difficulty:
Os: Linux | Blocking:
Architecture: x86| Failure: Other
--+-
Comment(by daniel.is.fischer):
Not much of a difference:
{{{
$ touch aaavec.hs
$ ghc -O0 -package vector-0.7 -package base-4.2.0.2 -o aaa60 aaavec.hs
$ ls -l | grep aaa60
-rwxr-xr-x 1 dafis users 1207342 15. Okt 13:22 aaa60
$ nm aaa60 | wc -l
11025
$ nm aaa60 | grep ghc | wc -l
65
$ ~/Haskell/Hacking/bin/ghc -O0 --make aaavec.hs -o aaa70
[1 of 1] Compiling Main ( aaavec.hs, aaavec.o )
Linking aaa70 ...
$ ls -l | grep aaa70
-rwxr-xr-x 1 dafis users 29221447 15. Okt 13:23 aaa70
$ nm aaa70 | wc -l
332413
$ nm aaa70 | grep ghc | wc -l
65413
$
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#comment:17
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
Re: [GHC] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7 --+- Reporter: daniel.is.fischer |Owner: igloo Type: bug| Status: new Priority: highest|Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords: executable size| Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: Other --+- Comment(by rl): Since fusion/inlining doesn't happen with -O0, that pretty much means that it has to be something else. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#comment:18 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
Re: [GHC] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7 --+- Reporter: daniel.is.fischer |Owner: igloo Type: bug| Status: new Priority: highest|Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords: executable size| Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: Other --+- Comment(by daniel.is.fischer): I've narrowed it down a bit. Importing Data.Vector.Fusion.Util and Data.Vector.Fusion.Stream.Size gives small executables, importing Data.Vector.Fusion.Stream.Monadic a large one. So something in there triggers it. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#comment:19 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
Re: [GHC] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7 --+- Reporter: daniel.is.fischer |Owner: igloo Type: bug| Status: new Priority: highest|Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords: executable size| Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: Other --+- Comment(by simonmar): One way to track it down would be to issue the link command manually with the GHC package removed, and see what symbols are missing and where they are referred to from. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#comment:20 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
Re: [GHC] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7
--+-
Reporter: daniel.is.fischer |Owner: igloo
Type: bug| Status: new
Priority: highest|Milestone: 7.0.1
Component: Compiler | Version: 7.1
Keywords: executable size| Testcase:
Blockedby: | Difficulty:
Os: Linux | Blocking:
Architecture: x86| Failure: Other
--+-
Comment(by igloo):
Hmm, with
{{{
$ cat h.hs
import SpecConstr
main = return ()
}}}
I get:
{{{
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.12.3
$ ghc --make h -package ghc
[1 of 1] Compiling Main ( h.hs, h.o )
Linking h ...
$ nm h | grep ghc | wc -l
59049
$ ls -lh h
-rwxr-xr-x 1 ian ian 32M Oct 15 13:29 h
$ strip h
$ ls -lh h
-rwxr-xr-x 1 ian ian 21M Oct 15 13:29 h
}}}
and:
{{{
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.1.20101014
$ ghc --make h -package ghc
[1 of 1] Compiling Main ( h.hs, h.o )
Linking h ...
$ nm h | grep ghc | wc -l
66744
$ ls -lh h
-rwxr-xr-x 1 ian ian 45M Oct 15 13:30 h
$ strip h
$ ls -lh h
-rwxr-xr-x 1 ian ian 29M Oct 15 13:30 h
}}}
i.e. it looks like it never worked for me.
What does
{{{
ar t `ghc --print-libdir`/ghc-6.12.3/libHSghc-6.12.3.a | wc -l
}}}
say for you?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#comment:21
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
Re: [GHC] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7 --+- Reporter: daniel.is.fischer |Owner: igloo Type: bug| Status: new Priority: highest|Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords: executable size| Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: Other --+- Comment(by rl): Replying to [comment:19 daniel.is.fischer]: I've narrowed it down a bit. Importing Data.Vector.Fusion.Util and Data.Vector.Fusion.Stream.Size gives small executables, importing Data.Vector.Fusion.Stream.Monadic a large one. So something in there triggers it. Stream.Monadic contains annotations, the others don't (they are also rather small). -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#comment:22 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
Re: [GHC] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7 --+- Reporter: daniel.is.fischer |Owner: igloo Type: bug| Status: new Priority: highest|Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords: executable size| Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: Other --+- Comment(by igloo): Oh, never mind, I can reproduce it if I use your testcase above. Curious. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#comment:23 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
Re: [GHC] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7 --+- Reporter: daniel.is.fischer |Owner: igloo Type: bug| Status: new Priority: highest|Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords: executable size| Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: Other --+- Comment(by simonpj): Ah.. light dawns. Every module has a module-initialisation routine. Apart from initialising the module, it calls the module-initialisation routine for each imported module. So if M imports module `SpecConstr` from package `ghc`, then the module-initialisatin routine for M will call the initialisation routine for `SpecConstr`. Even though nothing from `SpecConstr` is ultimately used. Hmm. That is bad. I'm not sure what to do about it. The obvious alternative is to call the module-init routine for each `Id` mentioned in the final executable for M. That would solve the problem, but at a cost: every module will call zillions of module initialisers. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#comment:24 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
Re: [GHC] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7
--+-
Reporter: daniel.is.fischer |Owner: igloo
Type: bug| Status: new
Priority: highest|Milestone: 7.0.1
Component: Compiler | Version: 7.1
Keywords: executable size| Testcase:
Blockedby: | Difficulty:
Os: Linux | Blocking:
Architecture: x86| Failure: Other
--+-
Comment(by daniel.is.fischer):
Yeah, seems that's it,
{{{
#if __GLASGOW_HASKELL__ = 613
import SpecConstr ( SpecConstrAnnotation(..) )
#endif
}}}
means !SpecConstr isn't actually imported with 6.12.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#comment:25
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
Re: [GHC] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7 --+- Reporter: daniel.is.fischer |Owner: igloo Type: bug| Status: new Priority: highest|Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords: executable size| Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: Other --+- Comment(by josef): It seems to me that what is really needed is a form of compile time imports. Some way to indicate that an imported module will only be used at compile time, for instance to use annotations or to generate code using Template Haskell. Jonas Almström Duregård bumped in to the same problem when using Template Haskell. He needed to import modules for use only at compile time but they where also linked in when the binary was created. Link to email: http://www.haskell.org/pipermail/glasgow-haskell- users/2010-September/019211.html -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#comment:26 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
Re: [GHC] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7 --+- Reporter: daniel.is.fischer |Owner: igloo Type: bug| Status: new Priority: highest|Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords: executable size| Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: Other --+- Comment(by rl): Could we just use `collect2` to collect and execute all initialisers that are linked in? GCC already solves this problem for C++ so perhaps we could simply reuse their mechanism. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#comment:27 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
Re: [GHC] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7 --+- Reporter: daniel.is.fischer |Owner: igloo Type: bug| Status: new Priority: normal |Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords: executable size| Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: Other --+- Changes (by igloo): * priority: highest = normal Comment: Aha, not a regression, then, so downgrading priority. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#comment:28 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
Re: [GHC] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7 --+- Reporter: daniel.is.fischer |Owner: igloo Type: bug| Status: new Priority: normal |Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords: executable size| Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: Other --+- Comment(by rl): I thought that `collect2` automates this. IIRC, it ploughs through all object files looking for specific constructor symbols and then generates and links in an additional module which calls those symbols and is, in turn, called at start up. Wouldn't it be enough to simply make sure that module initialiser symbols look like constructors and link with `collect2`? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#comment:30 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
Re: [GHC] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7 --+- Reporter: daniel.is.fischer |Owner: igloo Type: bug| Status: new Priority: normal |Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords: executable size| Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: Other --+- Comment(by batterseapower): Having a better solution for compile time imports would also prevent GHC from linking in modules that are import only for their type information (e.g. a type-level natural numbers package). We could also extend it so we get a better solution to the outstanding annoying problem where you have to remember to call `hs_init` and `hs_add_root` when building a C program that links in some Haskell. We can just arrange that hs_init is marked as a constructor for collect2's purposes. This will cause libgcc library to call hs_init for you (via __main), along with the module initialisers. This means that if you build your Haskell-importing C program using the GNU toolchain, then you don't have to worry about starting up the Haskell RTS at all. In particular this means you could write a Haskell library that behaves as a drop-in replacement for a C library. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#comment:31 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
Re: [GHC] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7 --+- Reporter: daniel.is.fischer |Owner: Type: bug| Status: infoneeded Priority: highest|Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords: executable size| Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: Other --+- Comment(by igloo): Thanks, I'll take a look. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#comment:4 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
Re: [GHC] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7 --+- Reporter: daniel.is.fischer |Owner: Type: bug| Status: new Priority: highest|Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords: executable size| Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: Other --+- Changes (by igloo): * status: infoneeded = new -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#comment:5 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
Re: [GHC] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7 --+- Reporter: daniel.is.fischer |Owner: igloo Type: bug| Status: new Priority: highest|Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords: executable size| Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: Other --+- Changes (by igloo): * owner: = igloo -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#comment:6 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
Re: [GHC] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7
--+-
Reporter: daniel.is.fischer |Owner: igloo
Type: bug| Status: new
Priority: highest|Milestone: 7.0.1
Component: Compiler | Version: 7.1
Keywords: executable size| Testcase:
Blockedby: | Difficulty:
Os: Linux | Blocking:
Architecture: x86| Failure: Other
--+-
Comment(by daniel.is.fischer):
And I just have found a small testcase.
It's the vector package,
{{{
module Main (main) where
import System.Environment (getArgs)
import qualified Data.Vector.Unboxed as U
import System.Random
import Control.Monad
main :: IO ()
main = do
args - getArgs
let num = case args of
(a:_) - read a
_ - 20
-- create a new source of randomness
-- andan infinite list of randoms
g - getStdGen
let rs = randoms g
mapM_ print $ take num (rs :: [Int])
-- fill a vector with the first 10 random Ints
-- let a = U.fromList (take num rs) :: U.Vector Int
--
-- -- print the sum
-- print (U.sum a)
--
-- -- print each element
-- forM_ (U.toList a) print
}}}
produces a 29179534 byte executable. If you comment out the (unused!)
import of Data.Vector.Unboxed, it's a fairly normal 1081701 bytes.
With 6.12.3, I have vector-0.6.0.2, HEAD includes vector-0.7, so it could
well be the vector package and not GHC. Let me try out, won't be too long.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#comment:7
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
Re: [GHC] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7 --+- Reporter: daniel.is.fischer |Owner: igloo Type: bug| Status: new Priority: highest|Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords: executable size| Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: Other --+- Comment(by daniel.is.fischer): Seems to be HEAD after all, with vector-0.7 and primitive-0.3.1 from hackage, 6.12.3 produces a 1087767 byte executable. Or it might be a difference between the hackage versions and those in the HEAD tree. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#comment:8 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
Re: [GHC] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7 --+- Reporter: daniel.is.fischer |Owner: igloo Type: bug| Status: new Priority: highest|Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords: executable size| Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: Other --+- Comment(by daniel.is.fischer): Looking at an executable with nm it seems the entire ghc package is linked in. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#comment:9 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
Re: [GHC] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7 --+- Reporter: daniel.is.fischer |Owner: igloo Type: bug| Status: new Priority: highest|Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords: executable size| Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: Other --+- Comment(by guest): I've built GHC 7.1.20101010 on Windows (with small manual fixes). Vector package have not been built by default. Vector-0.7 from hackage built with this GHC 7.1.20101010 does *NOT* increase executables sizes considerably. Vector from GHC HEAD is a culprit? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#comment:10 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
Re: [GHC] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7 --+- Reporter: daniel.is.fischer |Owner: igloo Type: bug| Status: new Priority: highest|Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords: executable size| Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: Other --+- Changes (by chak): * cc: r...@… (added) Comment: There is a problem with vector's fusion framework not working with the HEAD and 7.0. Judging from past experience with other DPH libraries, this may well be the reason for the code blowup. [I put rl on the CC list, so he sees this.] -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#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
Re: [GHC] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7 --+- Reporter: daniel.is.fischer |Owner: Type: bug| Status: new Priority: normal |Milestone: Component: Compiler | Version: 7.1 Keywords: executable size| Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: Other --+- Comment(by simonpj): That is bad. Very bad. An example would be very helpful indeed. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#comment:1 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
Re: [GHC] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7 --+- Reporter: daniel.is.fischer |Owner: Type: bug| Status: infoneeded Priority: highest|Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords: executable size| Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: Other --+- Changes (by igloo): * priority: normal = highest * status: new = infoneeded * milestone: = 7.0.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#comment:2 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
