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 ? Thanks, Thu _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
