newbie conceptual question [from haskell list]

[matt hellige]

[Fergus Henderson <fjh@cs.mu.oz.au>]
> 
> Could you be more specific about exactly which kinds of optimizations
> you are referring to here?
> 
> If/when multiple-CPU machines become common, so that automatic
> parallelization is a serious issue, then it will be much more important.
> But currently the optimizations you're talking about don't make a huge
> difference, IMHO.  Let's see, there's
> 
> 	(a) better opportunities for optimizing away code
> 	    whose results are not used
> 	    (lazy evaluation, and related optimizations);
> 	(b) better opportunities for reordering code;
> 	(c) advantages from knowing that data is immutable; and
> 	(d) better opportunities for avoiding heap allocation
> 	    because there are no problems with object identity
> 	    or mutability.
> 	    (E.g. this allows optimization such as static allocation of
> 	    constant terms, common sub-expression elimination,
> 	    and deforestation.)
> 
> I think (b) and (c) rarely make substantial differences.
> (a) and (d) can be very important, but in those cases if
> you're programming in an imperative language you can
> always do the optimization manually.
> 

i think we're in agreement, but you said it better... :)

i was only really talking about optimizations which are related to cases
which are very common in a functional language... for example, in a functional
style one is encouraged to create and apply numerous small functions, as
well as to make heavy use of recursion. so compiler writers have focused
a great deal of effort on the efficient implementation of these features.

in an imperative language, on the other hand, those features are generally
considered to be less important, and often are recognized performance hits.
so if you write in a functional style in c, for example, and make very
heavy use of recursion, you can get in deep trouble! of course, as you say,
these optimizations can always be done by hand, but usually it involves
"optimizing" from a functional style to an imperative style (e.g., converting
recursion to iteration), so then what's the point?

my point about the semantics of the language making these optimizations
possible was, i think, oblique to my main point, and perhaps only muddied
the waters...

m

-- 
matt hellige                  matt@immute.net
http://matt.immute.net