Phyx <loneti...@gmail.com> writes: > Hi, > > Though I'm no longer a very active GHC developer I do have some questions. > > Overall I'm in support of this but I think I'd rather see an outright split > from the start rather than first having a forwarder library. > > The reason for this is that I'm afraid of the performance impact of having > this intermediate layer. > > For statically linked programs this means at least an additional load and > branch on every call to a standard library. This would for instance affect > Windows quite heavily. I'm not sure the impact is mitigated by branch > prediction and prefetching. At the least it'll polute your L2 cache much > more than before. > > For dynamically linked we could potentially use symbol preemption to remove > the forwarding or on Windows redirect using import libraries. > > Now maybe I'm overestimating the impact this would have, but I'd very much > like to see some numbers on a small-ish experiment to see what impact (if > any) there are and what mitigation we can do. > > Typically it's quite hard to optimize after the fact. Maybe I've missed it > in there. Proposal, but can the compiler remove the forwarding? i.e. Can > the calls be specialized directly to the definition one? If so it'll break > having alternative standard libs at runtime? > I highly doubt that this split will have any measurable overhead. Reexporting a definition defined in one module from another module via an export list does not produce any code at all; importing such a declaration is equivalent to importing the definition from the defining module.
If for some reason we can't in some cases directly reexport then we would likely rather have a some very trivial bindings that GHC would be quite eager to inline. Cheers, - Ben
signature.asc
Description: PGP signature
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
