From: Jordi Date: 2007-12-22T23:23:53+09:00 Subject: Re: Experimental PATCH to improve thread performance ------=_Part_3103_8783621.1198333430893 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 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 ------=_Part_3103_8783621.1198333430893 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
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 <charles.nutter@sun.com> 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
------=_Part_3103_8783621.1198333430893--