Francis Cianfrocca wrote:
> On 7/2/06, M. Edward (Ed) Borasky <znmeb / cesmail.net> wrote:
>>
>> ....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.
>
> If the opportunity is there, why hasn't someone seen it yet? I'll take
> even
> incremental improvements, but it seems unlikely that something really
> major
> has been missed.
As far as I know, at least since I've been reading this list, you're the
first person to come up with a "clue", in the form of noticing that big
working sets were slower than small ones. That's something a performance
engineer can take his or her measuring and analysis tools and do
something with, unlike "it's slower than Python". :)
> Ah ... now searching is something we *can* optimize!
>
> Searching can be improved but even so, it's a lot of work to do at
> runtime.
> Languages that treat method dispatch as lookups into indexed tables
> have a
> big edge. Even Python does this.
Is that language-specific or interpreter-specific? I don't know much
about Ruby and I know even less about Python. Does Python build the
tables once at "compile time", or is it dynamic enough to require table
rebuilds at run time?
> No knock against Sun's engineers, some of the sharpest folks in the
> business. But that poster was referring to the Solaris/Sparc JVM,
> which in
> my experience is perhaps the least well-executed JVM around. Ugh.
> There's a
> limit to the amount of server RAM I'm willing to buy, power, and cool
> just
> to run bloatware.
Ah, but there's also a limit to how many developer-hours you're willing
to buy as well, so you've chosen to use Ruby rather than C. :) Of
course, C is pretty much as fast as it's going to get, but the Ruby
run-time is probably "laden with low-hanging fruit".
> Nothing like that. I'm trying to make my life easier, not harder ;-). The
> main reason I'm attracted to Ruby is the promise of developing a lot
> more of
> the unbelievably large amount of code that has to get written while
> reducing
> the critical dependency on high-quality personnel, which is a
> highly-constrained resource in uncertain supply. (I'm eliding some of my
> thinking here of course, so you may well challenge that statement.)
Developing "a large amount of code?" Why is there so much code required?
Are there a lot of detailed special cases that can't be made into data?

> I'd like to run plain-old Ruby objects in container processes that
> know how
> to distribute loads adapatively and keep individual process sizes
> small, and
> interoperate with objects written in other languages. In general I
> work with
> applications that require extremely high throughputs but can tolerate
> relatively large latencies (milliseconds as opposed to microseconds)
> as long
> as all the system resources are fully utilized. I want to take
> advantage of
> the coming multiprocessor hardware, but I don't want to do it with
> multithreading (life's too short for that).
Boy, you sure don't ask for much! :) But ... hang on for a moment ...
let me type a few magic words in a terminal window:

$ cd ~/PDFs/Pragmatic
$ acroread Pickaxe.pdf

Searching for "Rinda", we find, on page 706:

"Library Rinda ... Tuplespace Implementation

"Tuplespaces are a distributed blackboard system. Processes may add
tuples to the blackboard, and other processes may remove tuples from the
blackboard that match a certain pattern. Originally presented by David
Gelernter, tuplespaces offer an interesting scheme for distributed
cooperation among heterogeneous processes.

"Rinda, the Ruby implementation of tuplespaces, offers some interesting
additions to the concept. In particular, the Rinda implementation uses
the === operator to match tuples. This means that tuples may be matched
using regular expressions, the classes of their elements, as well as the
element values."
> The application area is matrix calculation for the most part,

> That sounds like the kind of thing I would use Ruby only to prototype.
> But
> you've been around the block a few times, so who am I to say? ;-)
Yes ... the "natural" implementation of it is using Axiom for the
prototyping and R as the execution engine. But I want to use Ruby for
both, as a learning exercise and as a benchmark of Ruby's math
capabilities. I know it's going to be slow -- matrices are stored as
arrays and the built-in LU decomposition is done using "BigDecimal"
operations, for example.

It will be interesting -- to me, anyhow -- to see just how much slower
the built-in Ruby LU decomposition is than the same process using the
ATLAS library, which contains assembly language kernels. Think of ATLAS
as a "virtual machine" for numerical linear algebra. :) In the end, I'll
wish I had used ATLAS right from the beginning. But maybe Ruby will get
better in the process.

There are other things this application needs to do besides number
crunching and symbolic math. It has to have a GUI, draw various graphs,
both node-edge type and 2d/3d plot type, and handle objects large enough
that they probably will end up in a PostgreSQL database. Curiously
enough, all of these exist as add-on packages in the R library already.
:) But I think Ruby is more "natural" for those pieces of the
application, and I can always "shell out to R" if I need to.

-- 
M. Edward (Ed) Borasky

http://linuxcapacityplanning.com