On Sun, Sep 29, 2002 at 02:28:30AM +0900, William Djaja Tjokroaminata wrote:
> Hi,
> 
> dblack / candle.superlink.net wrote:
> > I hope Ruby will continue to be Ruby even if you write this third
> > language :-)  But as for the question, I don't know.  I guess most
> > languages represent an attempt to find that balance -- not
> > specifically between Ruby-ish syntax and speed, but between ease of
> > life for programmer and speed.
> 
> Exactly.  Right now, I have only two choices.  When I need ease of life, I
> use Ruby; when I need speed, I use C.  And then, when I need both, I am
> strangled in this complex world of Ruby-C integration.  Hopefully, the R
> language can be a good, unified, language somewhere in between (closer to
> the C side, I hope).

Ruby-C integration really isn't that complicated. In fact, from my use, Ruby
has one of the simplest C interfaces to a scripting language.  It's even easier
if you use a tool like SWIG.

> But if we think deeper, one of the first questions to be answered in
> designing R is, do we want automatic memory management in terms of garbage
> collector or not?  It is known that invalid memory access and memory leaks
> are very common when the programmer manages the memory himself.  However,
> this is just my guess, when we use a garbage collector, there immediately
> we incur significant performance drop as compared to C.  (Not that the
> application is unusable (Ruby is definitely very usable), but the measure
> is applied more relative to pure C speed.)

I think you'll always have tradeoffs between speed, memory, and
usability. Assembly programmers know that hand written assembly is
often faster than compiler generated C. However, most asm programmers
will be the first to tell you, that it's usually not worth writing
code in all assembly, just the key performance bottlenecks.

> Member data access using hashing (as in Ruby) as compared to access using
> memory offset (as in C) I think is secondary, and therefore static typing
> has secondary effects on performance.  And I am afraid that we
> *may* already have such a language which is interpreted,
> garbage-collected, and use memory offset (instead of hashing) to access
> member data; the language is called.... Java (which I think is still too
> slow for network simulations)

Trying to optimize for the general case is far more difficult that
optimizing for a specific application.  If you read the Linux Kernel
list for example, you always see the scheduler and VM programmers
going back and forth on various optimizations -- for example, how do
you maximize IO transfers without knocking out interactive response on
other processes?  The problem is that "performance" means vastly
different things in different applications.

I think you're asking interesting questions which (if we can progress
toward answering them) might be valuable for everybody.  However, I
also think you might make faster progress with your specific network
sims problem if you were to spend more time examining optimized C/C++
code with a ruby interface.

-- 
Alan Chen
Digikata LLC
http://digikata.com