[Haskell-cafe] Hmm, what license to use?
minh thu
noteed at gmail.com
Fri Oct 3 07:36:24 EDT 2008
2008/10/3 Mitchell, Neil <neil.mitchell.2 at credit-suisse.com>:
>
> 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
More information about the Haskell-Cafe
mailing list