That's a good question, Francis. I'm afraid no formal comparison of
JRuby's threads versus Ruby's threads has ever been done. Threading
has been both an advantage and a disadvantage of JRuby.

- Native threads allow ruby code under JRuby to utilize multiple
processors, ultimately scaling better to big iron, but...
- A hard 1:1 tie between Ruby and Java threads means that many Ruby
thread operations are difficult or impossible to support because
Java's own threads do not support those operations. Cross-threading
hacks are a poor substitute for access to and control of a true thread
scheduler

If we put aside JRuby's interpreter performance issues for a moment,
it would be safe to assume that JRuby's threading today would in
general scale and perform better than C Ruby, since it would
automatically provide a truly threaded environment for ruby code. That
said, it's difficult to quantify that performance benefit in light of
the current unoptimized JRuby interpreter. You could scale it better,
but you'd be scalling a much slower base interpreter.

In order to address the second point above, we have chosen to
implement our own "green" non-native threading subsystem in JRuby.
This will allow us to build a thread scheduler and threading semantics
that match the way Ruby wants threads to work. However, since Tim Bray
and others have expressed a strong interest in keeping JRuby
native-threaded, we are planning to back those "green" threads with a
configurable pool of natives. For applications that want or warrant
true 1:1 threading, there will be no issue...simply turn on 1:1 and it
will run as it runs today. For applications that want pure green
threads, it will be just as simple; turn it on and all Ruby threads
will run in a single Java thread. However, for those middle cases
where we want m Ruby threads to be backed by n Java threads, we will
also support m:n threading, providing three different mechanisms for
scaling up Ruby applications.

So in the end, I don't have any definitive answer to give you. JRuby's
current threading scales better; JRuby's current slow interpreter does
not. JRuby's threading does not support all Ruby threading operations
well currently. All these issues are being addressed in the next six
months (or perhaps sooner if we can get Rails running). Does any of
this answer your question?

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

On 3/2/06, Francis Hwang <sera / fhwang.net> wrote:
> Hey Charles:
>
> Tim Bray mentioned that JRuby uses Java native threads to implement
> Rubys' threads. [1] Do you guys have any sort of publically posted
> comparisons of performance of threading between Ruby & JRuby? I don't
> even know enough about concurrency to know what are good ways to
> measure performance, but I think I'd find it interesting reading
> anyway.
>
> Francis
>
> [1] http://www.tbray.org/ongoing/When/200x/2005/08/31/Ruby-Rome
>
> Charles O Nutter wrote:
> > Sorry for the unsolicited promotion of JRuby and my own blog, but I
> > have been keeping a record of updates to JRuby along with musings on
> > the future of Ruby and Java playing together at
> > http://headius.blogspot.com. For those of you like me, caught between
> > worlds, I will frequently provide updates on the progress of JRuby and
> > the future of Ruby applications running on Java. My post today updates
> > the progress of getting Rails and IRB running, with a long discussion
> > of JRuby's design goals, performance woes, and promises for the
> > future. Naturally, I'd like an audience, but I'd also like to dispel
> > the continuing rumors that JRuby is "dead".
> >
> > For those of you completely uninterested in Ruby-on-Java, you can
> > safely disregard this email.  :)
> >
> > Thank you!
> >
> > --
> > Charles Oliver Nutter @ headius.blogspot.com
> > JRuby Developer @ jruby.sourceforge.net
> > Application Architect @ www.ventera.com
>
>
>