From: Charles O Nutter Date: 2006-03-03T13:01:08+09:00 Subject: Re: JRuby progress and the future 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 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 > > >