views:

567

answers:

3

I'm trying to understand the practical impact of different threading models between MRI Ruby 1.8 and JRuby.

What does this difference mean to me as a developer?

And also, are there any practical examples of code in MRI Ruby 1.8 that will have worse performance characteristics on JRuby due to different threading models?

+2  A: 

I am a regular JRuby user and the biggest difference is that JRuby threads are truly concurrent. They are actually system level threads so they can be executed concurrently on multiple cores. I do not know of any place where MRI Ruby 1.8 code runs slower on JRuby. You might consider checking out this question http://stackoverflow.com/questions/56087/does-ruby-have-real-multithreading/56094#56094.

Josh Moore
+4  A: 

JRuby's threads are native system threads, so they give you all the benefits of threaded programming (including the use of multiple processor cores, if applicable). However, Ruby has a Global Interpreter Lock (GIL), which prevents multiple threads from running simultaneously. So the only real performance difference is the fact that your MRI/YARV Ruby applications won't be able to utilize all of your processor cores, but your JRuby applications will happily do so.

However, if that isn't an issue, MRI's threads are (theoretically, I haven't tested this) a little faster because they are green threads, which use fewer system resources. YARV (Ruby 1.9) uses native system threads.

musicfreak
+2  A: 

State

  • ruby 1.8 has green threads, these are fast to create/delete (as objects) but do not truly execute in parallel and are not even scheduled by the operating system but by the virtual machine
  • ruby 1.9 has real threads, these are slow to create/delete (as objects) because of OS calls, but because of the GIL (global interpreter lock) that only allows one thread to execute at a time, neither these are truly parallel
  • JRuby also has real threads scheduled by the OS, and are truly concurrent

Conclusion

A threaded program running on a 2-core CPU will run faster on JRuby then the other implementations, regarding the threading point of view

Notice!

Many ruby existing ruby libraries are not thread-safe so the advantage of JRuby in many times useless
Also note that many techniques of ruby programming (for example class vars) will need additional programming effort to ensure thread-safeness (mutex locks, monitors etc) if one is to use threads.

clyfe