Phyx
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