Buy-in for technical proposal 47 which affect GHC devs

[Ben Gamari]

Phyx <lonetiger at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 905 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20230324/4e52449d/attachment.sig>