Re: Buy-in for technical proposal 47 which affect GHC devs

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 wrote:

Phyx 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