If only 1% of an imported module is used, GHC will link in the entire module. Are there any plans, or at least some ideas, to rectify this? One severe example of this is qtHaskell, where importing the top-level module causes glacial compile (actually link) times and huge executables. Strip can fix the executable size (why does GHC not do this automatically?), but linking remains a problem.
On Friday 13 May 2011 13:04:14, Guy wrote:
If only 1% of an imported module is used, GHC will link in the entire module.
With split-objs, as far as I know, GHC only links in what you use (plus the module initialiser). split-objs was disabled for some GHC/OS X combinations recently, http://hackage.haskell.org/trac/ghc/ticket/4013 and 5008, maybe that applies to you, otherwise building GHC with object-splitting enabled and all libraries with split-objs should reduce code size significantly. Linking still tends to use a lot of memory with ld, on the appropriate platforms you could try using gold as the linker, that's reported to use less memory (and be faster).
Are there any plans, or at least some ideas, to rectify this? One severe example of this is qtHaskell, where importing the top-level module causes glacial compile (actually link) times and huge executables. Strip can fix the executable size (why does GHC not do this automatically?), but linking remains a problem.
On 14/05/2011 21:10, Daniel Fischer wrote:
Linking still tends to use a lot of memory with ld, on the appropriate platforms you could try using gold as the linker, that's reported to use less memory (and be faster).
No gold for windows :-( Another problem with ld is that it's only single core.
Cores don't necessarily help linking because it's I/O bound and very concrete sequential algo.
Sent from my Verizon Wireless BlackBerry
-----Original Message-----
From: Guy
Linking still tends to use a lot of memory with ld, on the appropriate platforms you could try using gold as the linker, that's reported to use less memory (and be faster).
No gold for windows :-( Another problem with ld is that it's only single core. _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
On 15/05/2011 22:28, B. Scott Michel wrote:
Cores don't necessarily help linking because it's I/O bound and very concrete sequential algo.
It's CPU-bound on my machine. ld uses 100% of one core with occasional disk activity. Pity that the other cores can't help, linking often seems like the slowest stage of compiling for me.
On 14/05/2011 19:10, Daniel Fischer wrote:
On Friday 13 May 2011 13:04:14, Guy wrote:
If only 1% of an imported module is used, GHC will link in the entire module.
With split-objs, as far as I know, GHC only links in what you use (plus the module initialiser).
FYI, in 7.2.1, the module initialiser is gone. http://hackage.haskell.org/trac/ghc/changeset/a52ff7619e8b7d74a9d933d922eeea... Cheers, Simon
When compiled with "split objs" GHC makes it possible for the linker
to do dead code stripping. Make sure your GHC has split-objs on.
On Fri, May 13, 2011 at 4:04 AM, Guy
If only 1% of an imported module is used, GHC will link in the entire module. Are there any plans, or at least some ideas, to rectify this? One severe example of this is qtHaskell, where importing the top-level module causes glacial compile (actually link) times and huge executables. Strip can fix the executable size (why does GHC not do this automatically?), but linking remains a problem.
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
On 14/05/2011 21:12, Don Stewart wrote:
When compiled with "split objs" GHC makes it possible for the linker to do dead code stripping. Make sure your GHC has split-objs on.
Thank you, I hadn't realised that the imported library could be built like this. How is this configured with cabal? (And do any packages actually do so?)
On Saturday 14 May 2011 21:06:50, Guy wrote:
On 14/05/2011 21:12, Don Stewart wrote:
When compiled with "split objs" GHC makes it possible for the linker to do dead code stripping. Make sure your GHC has split-objs on.
Thank you, I hadn't realised that the imported library could be built like this. How is this configured with cabal?
In your ~/.cabal/config file (translate the path to Windows, I've no idea where the config goes there), there's a field for that, set split-objs: True And from then on cabal (install) passes the -split-objs flag (or was that --split-objs?) to GHC when installing packages. You'd have to rebuild the packages you already have.
(And do any packages actually do so?)
It's something the user decides, not the package author.
On 14/05/2011 21:12, Don Stewart wrote:
When compiled with "split objs" GHC makes it possible for the linker to do dead code stripping. Make sure your GHC has split-objs on.
In the case that split-objs wasn't used, is this a GHC limitation, or an ld limitation? The Delphi linker eliminates unused code from monolithic object files (if I remember correctly), so presumably this isn't an inherent limitation of linking.
participants (5)
-
B. Scott Michel -
Daniel Fischer -
Don Stewart -
Guy -
Simon Marlow