<div dir="auto"><br><div data-smartmail="gmail_signature">Hi,</div><div data-smartmail="gmail_signature" dir="auto"><br></div><div data-smartmail="gmail_signature" dir="auto">Though I'm no longer a very active GHC developer I do have some questions. </div><div data-smartmail="gmail_signature" dir="auto"><br></div><div data-smartmail="gmail_signature" dir="auto">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. </div><div data-smartmail="gmail_signature" dir="auto"><br></div><div data-smartmail="gmail_signature" dir="auto">The reason for this is that I'm afraid of the performance impact of having this intermediate layer.</div><div data-smartmail="gmail_signature" dir="auto"><br></div><div data-smartmail="gmail_signature" dir="auto">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.</div><div data-smartmail="gmail_signature" dir="auto"><br></div><div data-smartmail="gmail_signature" dir="auto">For dynamically linked we could potentially use symbol preemption to remove the forwarding or on Windows redirect using import libraries.</div><div data-smartmail="gmail_signature" dir="auto"><br></div><div data-smartmail="gmail_signature" dir="auto">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.</div><div data-smartmail="gmail_signature" dir="auto"><br></div><div data-smartmail="gmail_signature" dir="auto">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?</div><div data-smartmail="gmail_signature" dir="auto"><br></div><div data-smartmail="gmail_signature" dir="auto">Kind regards, </div><div data-smartmail="gmail_signature" dir="auto">Tamar </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 24, 2023, 04:47 Ben Gamari <<a href="mailto:ben@smart-cactus.org">ben@smart-cactus.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">"Adam Sandberg Eriksson" <<a href="mailto:adam@sandbergericsson.se" target="_blank" rel="noreferrer">adam@sandbergericsson.se</a>> writes:<br>
<br>
> I switched all the HADDOCK hide to not-home in base a couple of years<br>
> ago, but I see a couple of new ones have snuck in in the meantime. I<br>
> would suggest adding a lint against hiding in GHC CI.<br>
><br>
Sounds reasonable to me.<br>
Perhaps someone could open a ticket to track this?<br>
<br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank" rel="noreferrer">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div>