On 07/07/2011 09:36, Max Bolingbroke wrote:
On 7 July 2011 08:53, Simon Marlow<[email protected]> wrote:
Great - that should speed up linking too.
Here is another idea which should be worth a lot. The observation is
that top level statically allocated _closure exports are rarely used.
GHC exports 32,484 _closure pointers but only 5,214 distinct closures
actually get referenced, so 27,210 are unused (I'm counting references
reported by nm from object file making up ghc.exe and libHSghc). There
are 19,233 closure use sites, with the closures being used having a
"long tail" kind of distribution: the Pretty_Empty_closure has 213
uses and there are about as many closures with 1 uses as there are
closures with 2 and 3 uses combined.
A possible response to these figures is to move to a scheme with lazy
construction of top-level _closures. We could create the _closure for
a top level import on demand (I think there should be enough
information in the .hi to do this) and then perhaps use C++-template
instantiation linking semantics to common up definitions arising from
distinct object files. These _closures would never be marked as
exported.
This should cut the number of exported symbols by 32k at a stroke. The
only bit of information we will need to export about a top-level
definition is the _info.
Sound reasonable? Is this something we would want to do?
Are you talking about closures for constructors here, or functions too?
I'd expect most function closures to be referenced in an SRT somewhere.
It does sound like it might be worth a try, though. Even if we were to
create a new _closure for each reference, do you have an idea what
effect that would have on code size?
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
