From: Chad Perrin <perrin@...>
Date: 2006-07-27T03:59:49+09:00
Subject: Re: For performance, write it in C

On Thu, Jul 27, 2006 at 12:23:23AM +0900, Charles O Nutter wrote:
> 
> You're mixing language semantics and implementation details here. The
> mechanics of method lookup is not a language feature; it's an implementation
> detail. On the other hand, the logic of which method gets invoked in a
> hierarchy of types is a language detail. Scoping is a language feature, but
> the means by which scope is maintained is an implementation detail.

In some ways, you're right: implementation details are being mixed up
with language definition in the preceding list of features.  In the case
of scoping, however, you're not entirely right with regard to "the means
by which scope is maintained".  Dynamic scoping, by definition, requires
runtime scoping.  Static scoping, by definition, does not.  This means
that (to use Perl as an example, since I know it better than Ruby) my(),
which is used to declare variables in lexical scope, can be managed at
compile time, while local(), which is used for dynamic scope, can only
be managed at runtime -- else it will not work as advertised.  That's
more than simply implementation details: implementation is, in this
case, dictated by language features.


> 
> As for the closure comment...sure, there's overhead in creating closures,
> but it's *explicit* overhead. This is no different from creating the
> equivalent of closures in languages that don't support them. The concept of
> a closure has a clear specification and certainly increases the complexity
> of a language and an underlying implementation. But that complexity may not
> in itself always represent a decrease in performance, since other means of
> accomplishing the same task may be even less performant. That's how it is
> for any language feature...you take the good with the bad, and if you don't
> use all of the good you may be less-than-optimal. If using a feature has ten
> good aspects and five bad, and you only make use of five good aspects, then
> your code is sub-optimal. If you use less than five, you're even worse off
> and perhaps should consider doing things differently. Nothing about the
> feature itself explicitly implies that performance should degrade by using
> it...it's a matter of using those features wisely and making optimal use of
> their good aspects, balanced with their bad aspects.

I think closures are kind of a bad example for this, actually.  There's
nothing about closures that necessarily harms performance of the
language in implementation.  In fact, closures are in some respects
merely a happy accident that arises as the result of other, positive
characteristics of a language that all can tend to contribute to better
performance of the implementation of a language (such as lexical scope,
which leads to better performance than dynamic scope).  In fact, one of
the reasons Python doesn't have proper closures (lack of strict lexical
scoping) is also likely one of the reasons Python still tends to lag
behind Perl for performance purposes.

The only real overhead involved in closures, as far as I can see, is the
allocation of memory to a closure that doesn't go away until the program
exits or, in some implementations, until the program reaches a point
where it will absolutely, positively never need that closure again
(which is roughly the same thing for most uses of closures).  A little
extra memory usage does not translate directly to performance loss.  In
fact, in any halfway-decent system implementation, it really shouldn't
result in reduced performance unless you start having to swap because
you've overrun "physical RAM", I think.

The day may come when RAM is better managed so that performance gains
can be had for less memory usage, though, so I doubt this will always be
true.

-- 
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
"A script is what you give the actors.  A program
is what you give the audience." - Larry Wall