Linking in Dead Code

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Guy
Reply | Threaded
Open this post in threaded view
|

Linking in Dead Code

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
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Linking in Dead Code

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://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.
>

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Linking in Dead Code

Don Stewart
In reply to this post by Guy
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 <[hidden email]> 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 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
> [hidden email]
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Guy
Reply | Threaded
Open this post in threaded view
|

Re: Linking in Dead Code

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
do any packages actually do so?)


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Guy
Reply | Threaded
Open this post in threaded view
|

Re: Linking in Dead Code

Guy
In reply to this post by Daniel Fischer
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.


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Linking in Dead Code

Daniel Fischer
In reply to this post by Guy
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.

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Guy
Reply | Threaded
Open this post in threaded view
|

Re: Linking in Dead Code

Guy
In reply to this post by Don Stewart
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.


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Linking in Dead Code

scooter.phd@gmail.com
In reply to this post by Guy
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 <[hidden email]>
Sender: [hidden email]
Date: Sat, 14 May 2011 22:08:16
To: <[hidden email]>
Subject: Re: Linking in Dead Code

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.


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Linking in Dead Code

Simon Marlow-7
In reply to this post by Daniel Fischer
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/a52ff7619e8b7d74a9d933d922eeea49f580bca8

Cheers,
        Simon

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Guy
Reply | Threaded
Open this post in threaded view
|

Re: Linking in Dead Code

Guy
In reply to this post by scooter.phd@gmail.com
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.


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users