Re: Experimental PATCH to improve thread performance

I don't think Matz has thought seriously about threads. I hope soon after
1.9.1 threading becomes the top research topic for the language.

Erlang can support zillions of threads with no dangerous operations, using
queues IIRC. It seems slow but avoids a lot of problems what in turns gives
room to optimizations.

BTW, congratulations for your JRuby 1.1b, rocks.


On Dec 22, 2007 11:07 PM, Charles Oliver Nutter <[e-mail]>
wrote:

> Brent Roman wrote:
> >
> > Charles Oliver Nutter-2 wrote:
> >>
> >> I'd love to know what broke in JRuby. I tried both benchmarks and
> >> they're very snappy on my machine. We're making a big push to get JRuby
> >> threading solid, so please let us know what you've seen.
> >>
> >>
> >
> > I'd like to work with you on this after the holidays.
> > In the meantime, I've attached a java backtrace
> > of the failure in our dreaded "killer app"
> > Let me know if you can glean anything from it that will
> > help me create a simple test case for you.
> >
> > http://www.nabble.com/file/p14467248/jruby-1.1b1.backtrace
> > jruby-1.1b1.backtrace
> >
> > By the way,
> > The benchmark numbers I see here are very consistent with your claim
> > that JRuby is faster than Ruby 1.8.6.  In this case, it's a lot faster:
> >
> >                Unpatched 1.8.6    Patched 1.8.6   JRuby 1.1b1      Ruby
> 1.9
> > Bench #1  22sec / 16 MB       4sec  / 7 MB     3.5sec / 21 MB    0.06sec
> > Bench #2  35sec / 10 MB      15sec  / 7 MB    2.8sec / 17 MB    0.36sec
> >
> > I realize that these numbers penalize JRuby for its JVM start up delay,
> > but, even so, it's clear that when Ruby 1.9 is finally ready,
> > it will be the horse to beat ;-)
> >
> > Note that I had to patch my version of 1.9 to implement Thread.critical=
> > to run benchmark #2.  This is quite straightforward as long as the
> > global interpreter lock continues to exist.  I'm surprised that
> > JRuby accepts Thread.critical=.  How did JRuby implement this
> > atop a JVM?
>
> In JRuby, all threads executing Ruby code checkpoint at the same places
> Ruby 1.8.6 checks if a context switch is indicated. In Ruby 1.8.6 that
> context switch flag is set every 10ms (10ms timeslicing), but in JRuby,
> we only look for cross-thread events at these checkpoints since threads
> are running concurrently.
>
> See my description of threading in Ruby here:
>
> http://spec.ruby-doc.org/wiki/Ruby_Threading
>
> and JRuby here:
>
> http://spec.ruby-doc.org/wiki/JRuby_Threading
>
> Both haven't been updated in a while, but should still be correct. I'd
> love to have a Ruby 1.9 article alongside them, and I hope you and
> others will make updates to either article as you see fit.
>
> Checkpointing does introduce some overhead, but we've pared it down a
> lot to avoid locking as much as possible. I'd love to see a day where we
> could turn off all the dangerous cross-thread operations, effectively
> eliminating checkpointing entirely, but I don't think it's likely to
> happen.
>
> Provably unsafe thread operations Ruby supports and should not:
>
> stop
> exit/exit!/kill/kill!/terminate/terminate!
> raise
> global abort_on_exception
>
> Operations which are largely incompatible with concurrent threading
> (which Ruby can't support if it wants to support concurrent threading
> well):
>
> critical=
>
> I'll enumerate the reasons why these are unsafe if anyone wants to know.
> I think Java's threading is a good model here; it provides the thread
> operations that can be safely supported and does not provide the others.
>
> Here's an article that explains some of the reasons:
>
>
> http://java.sun.com/j2se/1.5.0/docs/guide/misc/threadPrimitiveDeprecation.html
>
> - Charlie
>
>


-- 
Jordi Polo Carres
Natural language processing laboratory
NAIST
http://www.bahasara.org