> 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.

Ah right, I can see how that's true at the Haskell level but..

> 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. 

Sure, I can see how you'd inline based on the haskell contract, I can't see how you avoid the compile time overhead when compiling the library. If you have a haskell library

module Test (Control.Monad.when, Control.Applicative.many) where

import Control.Monad(when)
import Control.Applicative(many)

compiling it:

 ghc test.hs
[1 of 1] Compiling Test             ( test.hs, test.o )

which still contains the closure for the library.  On Windows where GHC forces the use of --export-all-symbols with dynamic-too this will not result in no code.
in fact, it will result in exactly the *same* copy of code as in base inside the shared library:

--export-all-symbols

Treat all global and weak defined symbols found in the input object files as symbols to be exported. There is a small list of symbols which are not exported by default; see the --no-default-excludes option. You may add to the list of symbols to not export by using the --exclude-symbols option.

At runtime you're right that you can avoid the extra calls (forgot about re-exportation through module definition) because the library becomes unused,
but you don't avoid it at compile and link time in all cases.

Yes, --export-all-symbols is horrible but that's how it works today because GHC does not support symbol visibility correctly.

So unless there's a very good reason, I still think that it's better for *all* platforms to just move the code as opposed to re-export them, less we make it even
harder still to support dynamic-too on Windows (though maybe that's ok and GHC should be fixed).

Thanks,
Tamar

On Fri, Mar 24, 2023, 21:18 Ben Gamari <ben@smart-cactus.org> wrote:
Phyx <lonetiger@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