Buy-in for technical proposal 47 which affect GHC devs

[Carter Schonwald]

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

On Fri, Mar 24, 2023 at 3:48 AM Phyx <lonetiger at gmail.com> wrote:

>
> 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?
>
> Kind regards,
> Tamar
>
> On Fri, Mar 24, 2023, 04:47 Ben Gamari <ben at smart-cactus.org> wrote:
>
>> "Adam Sandberg Eriksson" <adam at sandbergericsson.se> writes:
>>
>> > I switched all the HADDOCK hide to not-home in base a couple of years
>> > ago, but I see a couple of new ones have snuck in in the meantime. I
>> > would suggest adding a lint against hiding in GHC CI.
>> >
>> Sounds reasonable to me.
>> Perhaps someone could open a ticket to track this?
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20230324/7193fc3c/attachment.html>