<div dir="ltr">this is actually a good point! In my head, i was thinking some of the backpack module renaming and exporting machinery that cabal has would be applicable to side stepping the problem you're alluding to<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 24, 2023 at 3:48 AM Phyx <<a href="mailto:lonetiger@gmail.com">lonetiger@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><br><div>Hi,</div><div dir="auto"><br></div><div dir="auto">Though I'm no longer a very active GHC developer I do have some questions. </div><div dir="auto"><br></div><div 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 dir="auto"><br></div><div dir="auto">The reason for this is that I'm afraid of the performance impact of having this intermediate layer.</div><div dir="auto"><br></div><div 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 dir="auto"><br></div><div dir="auto">For dynamically linked we could potentially use symbol preemption to remove the forwarding or on Windows redirect using import libraries.</div><div dir="auto"><br></div><div 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 dir="auto"><br></div><div 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 dir="auto"><br></div><div dir="auto">Kind regards, </div><div 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" target="_blank">ben@smart-cactus.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">"Adam Sandberg Eriksson" <<a href="mailto:adam@sandbergericsson.se" rel="noreferrer" target="_blank">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" rel="noreferrer" target="_blank">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>
</blockquote></div>