From: Charles O Nutter <headius@...>
Date: 2006-07-27T00:23:23+09:00
Subject: Re: For performance, write it in C

------=_Part_9670_1020595.1153927399687
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 7/26/06, Sean O'Halpin <sean.ohalpin@gmail.com> wrote:
>
> On 7/26/06, Charles O Nutter <headius@headius.com> wrote:
>
> > there's nothing about a
> > language's design that should necessitate it being slower than any other
> > language.
>
> While I accept that you shouldn't confuse a language with its
> implementation,
> I find that a mildly surprising statement, especially since you said
> in an earlier post:
>
> > for memory-intensive situations Java almost always wins because lazy
> memory
> > management allows work to get done first, faster
>
> Garbage collection seems to me to be an integral part of Java's design.


Garbage collection is a characteristic of the Java VM, not the language.
Nothing in the language specifies garbage collection or how it should be
performed. It could just as easily be implemented with reference-counting,
and the language would still look exactly the same. What IS a characteristic
of the language is that you do not explicitly release objects when you are
finished using them. There are many ways to interpret that and many ways to
implement it. Garbage collection is just one among many.

Off the top of my head, I can think of some other design aspects that
> have an effect on performance: method lookup in OO languages, scoping,
> continuations, closures, static vs dynamic typing, type inference,
> double dispatch, consing + car + cdr in Lisp, direct vs indirect
> threading in Forth, etc. These are not just matters of implementation.
> Each is a language design decision with a semantic effect which incurs
> or avoids a computational cost, regardless of how it's actually
> implemented. For example, Ruby has real closures, Python doesn't. I
> don't see how you could ever reduce the cost of Ruby having closures
> to zero - the memory alone is an implied overhead. Sure you can
> optimize till the cows come home but different functionalities have
> different costs and you can't ever avoid that.


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.
Continuations are a language feature, but the means by which a continuation
and its applicable scoping are memoized is an implementation detail. Static
and dynamic typing are language features; the means by which type is
propagated and used for calls, checks, and memory allocation is an
implementation detail. On and on and on...language features always have an
associated implementation, but there's almost always multiple ways to
implement a given feature, and those different implementations will have
their plusses and minuses.

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.

-- 
Charles Oliver Nutter @ headius.blogspot.com
JRuby Developer @ www.jruby.org
Application Architect @ www.ventera.com

------=_Part_9670_1020595.1153927399687--