On Fri, Oct 3, 2008 at 4:36 AM, minh thu <[EMAIL PROTECTED]> wrote: > 2008/10/3 Mitchell, Neil <[EMAIL PROTECTED]>: > > > > Hi > > > > > >> > > You mean shared libraries without the opportunity to > >> inline library code? > >> > > This would result in a huge performance loss, I think. > >> > > >> > Usually _mild_ performance loss, in exchange for major code-size > >> > savings, I would think. C obviously has worked quite fine under > >> > exactly this restraint (though C implementations obviously aren't > >> > built to take as great advantage of inlining library code > >> as Haskell may be). > >> > >> I think that the performance loss is much higher in the case > >> of Haskell because of Lazy Evaluation, massive use of higher > >> order functions and possibly more. > > > > Example 1: > > > > foo x | "test" `isPrefixOf` xs = ... > > | otherwise = ... > > > > If you have cross-module inlining, you get the rather obvious if like > > construct. If you don't, you have to evaluate otherwise and test its > > value. > > > > Example 2: > > > > (a :: Int) + b > > > > If you have cross-module specialisation you get a primitive integer > > arithmetic instruction (possibly with a bit of unboxing, although often > > not). If you don't, you get a dictionary lookup, followed by a higher > > order application. > > > > One reason cross-module inlining is essential is that many Haskell > > functions don't do very much, think of (+), (||), (>>), not, otherwise > > etc. In C these would be built-in's, so are always available to the > > optimiser (and usually just one instruction), in Haskell you need to get > > them from the Prelude. > > What happens in the C++ world where good chunk of functionnalities are > in header files (templates or inline methods); > is there the same LGPL problem that the one discussed here w.r.t. > static/shared linking ? >
I don't know what happens on platforms that don't have shared libraries with LGPL. If you build stuff statically, I'm pretty sure you can't claim stuff is loosely coupled. Dave > > Thanks, > Thu > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe