Re: Linking in Dead Code

2011-05-16 Thread Guy
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 s

Re: Linking in Dead Code

2011-05-16 Thread Simon Marlow
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 initi

Re: Linking in Dead Code

2011-05-15 Thread B. Scott Michel
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 Sender: glasgow-haskell-users-boun...@haskell.org Date: Sat, 14 May 2011 22:08:16 To: Subject: Re: Linking in

Re: Linking in Dead Code

2011-05-14 Thread Guy
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 unu

Re: Linking in Dead Code

2011-05-14 Thread Daniel Fischer
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 b

Re: Linking in Dead Code

2011-05-14 Thread Guy
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.

Re: Linking in Dead Code

2011-05-14 Thread Guy
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

Re: Linking in Dead Code

2011-05-14 Thread Daniel Fischer
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://ha

Re: Linking in Dead Code

2011-05-14 Thread Don Stewart
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 wrote: > If only 1% of an imported module is used, GHC will link in the entire > module. Are there any plans, or at least some

Linking in Dead Code

2011-05-14 Thread 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 fi