> 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 <b...@smart-cactus.org> wrote: > Phyx <loneti...@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 > >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs