Buy-in for technical proposal 47 which affect GHC devs

[Phyx]

> 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 at smart-cactus.org> wrote:

> Phyx <lonetiger at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20230325/5a05c0bd/attachment.html>