<div dir="ltr"><br><br><div class="gmail_quote">On Fri, Oct 3, 2008 at 4:36 AM, minh thu <span dir="ltr"><<a href="mailto:noteed@gmail.com">noteed@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
2008/10/3 Mitchell, Neil <<a href="mailto:neil.mitchell.2@credit-suisse.com">neil.mitchell.2@credit-suisse.com</a>>:<br>
<div><div></div><div class="Wj3C7c">><br>
> Hi<br>
><br>
><br>
>> > > You mean shared libraries without the opportunity to<br>
>> inline library code?<br>
>> > > This would result in a huge performance loss, I think.<br>
>> ><br>
>> > Usually _mild_ performance loss, in exchange for major code-size<br>
>> > savings, I would think. C obviously has worked quite fine under<br>
>> > exactly this restraint (though C implementations obviously aren't<br>
>> > built to take as great advantage of inlining library code<br>
>> as Haskell may be).<br>
>><br>
>> I think that the performance loss is much higher in the case<br>
>> of Haskell because of Lazy Evaluation, massive use of higher<br>
>> order functions and possibly more.<br>
><br>
> Example 1:<br>
><br>
> foo x | "test" `isPrefixOf` xs = ...<br>
> | otherwise = ...<br>
><br>
> If you have cross-module inlining, you get the rather obvious if like<br>
> construct. If you don't, you have to evaluate otherwise and test its<br>
> value.<br>
><br>
> Example 2:<br>
><br>
> (a :: Int) + b<br>
><br>
> If you have cross-module specialisation you get a primitive integer<br>
> arithmetic instruction (possibly with a bit of unboxing, although often<br>
> not). If you don't, you get a dictionary lookup, followed by a higher<br>
> order application.<br>
><br>
> One reason cross-module inlining is essential is that many Haskell<br>
> functions don't do very much, think of (+), (||), (>>), not, otherwise<br>
> etc. In C these would be built-in's, so are always available to the<br>
> optimiser (and usually just one instruction), in Haskell you need to get<br>
> them from the Prelude.<br>
<br>
</div></div>What happens in the C++ world where good chunk of functionnalities are<br>
in header files (templates or inline methods);<br>
is there the same LGPL problem that the one discussed here w.r.t.<br>
static/shared linking ?<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>Dave</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Thanks,<br>
<font color="#888888">Thu<br>
</font><div><div></div><div class="Wj3C7c">_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote></div><br></div>