On Tue, Apr 17, 2012 at 04:06:25PM -0400, Michael Alan Dorman wrote: > Iustin Pop <iustin@debian.org> writes: > > As far as I understand, it's not symbol mangling, but the fact that > > dynamic linking (without recompilation) prevents the optimiser from > > doing its full work (e.g. inlining across modules, etc.). > > Err, now I could be wrong, but I didn't think GHC was doing link-time > optimization---and if it's not, ISTM that inlining across modules, > whether static or dynamic is infeasible, no? I might be wrong, but as far as I understand it, it's not link-time optimisation, but rather compile time. If the library exports an (inlinable) function, and ghc decides to inline it, then the program will get the inline copy. So in this mode, it is across modules. Of course, I could be very wrong :) > > As a maintainer of a C++ library, I was watching that thread, but in the > > end I gave up on (starting to) maintaining the symbols list. Just read > > the problems list in the email you quote :) > > Yeah, I know. I was hoping that the Haskell situation might be more > tractable, though in fact it looks like it's even less so. ;) Indeed. > > IMHO the simple and streamlined way _is_ static linking. Well, not > > simple for security issues, but for the build process. But that's just > > IMHO, and not a strong opinion :) > > The company I work for has plans to deploy several Haskell-based apps in > the next six months to a year. The supporting libraries are more or > less the same across all of them---so dynamic libraries have the > potential, at least, to reduce the aggregate memory footprint of those > apps significantly. Hmm. But the apps themselves are not identical, right? What I did was, for some apps that were 90%+ identical, just make them 100% identical, and select the desired behaviour via command line flags, env. vars or program name. Of course, this worked nicely in my case because they very all _very_ identical to start with (all command line tools, etc.). > We may just end up cheering that we've saved as much memory as we have > by moving to Haskell from an interpreted language and not worrying about > the static vs. dynamic cost. At least, on further examination that > would seem to be the most bang for the buck. Depending on how much you use of each library, split_objs could still help you. I never used it so I don't know, in practice, if it helps significantly. thanks, iustin
Attachment:
signature.asc
Description: Digital signature