Francis Cianfrocca wrote:
> On 7/2/06, M. Edward (Ed) Borasky <znmeb / cesmail.net> wrote:
>>
>> I personally don't think it a "necessary consequence of Ruby's extremely
>> dynamic nature." There are a couple of things it could be:
>>
>> 1. Page faulting with large working sets. There are things you can do to
>> the interpreter to enhance locality and minimize page faulting, but if
>> you have two 256 MB working sets in a 256 MB real memory, something's
>> gotta give.
>>
>> 2. Some process in the run-time environment that grows faster than N log
>> N, where N is the number of bytes in the working set. Again, putting on
>> my statistician's hat, you want the interpreter to exhibit N log N or
>> better behavior on the average.
>
>
> Ok, but these are problems that affect any program regardless of what
> it's
> written in. 
1 affects any program regardless of what it's written in. 2 could be
either some fundamental constraint of the langauge semantics (which I
doubt) or an optimization opportunity in the run-time to deal more
efficiently with the semantics of the language.
> I could figure this out if I were frisky enough (but someone probably
> already knows), but it seems like Ruby takes a Smalltalk-like approach to
> method-dispatch. Meaning, it searches for the method to send a message
> to,
> on behalf of each object.
Ah ... now searching is something we *can* optimize!
> Whereas a language like Java views method-dispatch
> as calling a function pointer in a dispatch table that is associated with
> each class, and can easily be optimized. That's what I meant by Ruby's
> "extremely dynamic nature." And the fact that classes and even objects
> are
> totally open throughout runtime makes it all the more challenging. As a
> former language designer, I have a hard time imagining how you would
> automatically optimize such fluid data structures at runtime.
I suspect the dynamic nature means you have to keep *more* data
structures, and that they need to be *larger*, but it's still pretty
much known techniques in computer science.
> You mentioned
> page faulting, but it's even more important (especially on
> multiprocessors)
> not to miss L1 or L2 caches or mispredict branches either. If you're
> writing
> C++, you have control over this, but not in Ruby.
Yes, you've given this task to the run time environment. At least one
poster claims, and I have no reason to doubt him, that the Sun JVM is
smart enough to do this kind of thing, though I don't recall this
specific task being given as one that it does in fact do. If the Sun JVM
can do it, a Ruby interpreter should be able to do it as well.
> The more I work with Ruby, the more I find myself metaprogramming almost
> everything I do. This seems to put such a burden on Ruby's runtime
> that I'm
> looking for simpler and more automatic ways to run Ruby objects in
> automatically-distributed containers, to minimize the working sets. The
> problem is worth solving because the productivity-upside is just so
> attractive.
I'm not sure what you mean here, both in terms of "objects in
automatically-distributed containers" and "productivity-upside". Are you
looking for something like "lightweight processes/threads" or what is
known as "tasks" in classic FORTH? Little chunks of code, sort of like
an interrupt service routine, that do a little bit of work, stick some
results somewhere and then give up the processor to some "master scheduler"?

I don't know Ruby well enough to figure out how to do that sort of
thing. Then again, if I wanted to write something that was an ideal
FORTH application, I'd probably write it in FORTH. :)

In any event, I'm working on a Ruby project in my spare time, and I can
certainly dig into the workings of the Ruby run-time if I find that it's
too slow. The application area is matrix calculation for the most part,
so I expect "mathn", "rational", "complex" and "matrix" are going to be
the bottlenecks. I suspect the places where Ruby needs be tuned
underneath will stick out like the proverbial sore thumbs for the kind
of application I have in mind.

-- 
M. Edward (Ed) Borasky

http://linuxcapacityplanning.com