11–20 of 21 posts
Why not use http://jruby.org ?
C extensions are a very big reason why not; the pain of demand-starting JVMs is another minor reason.
How is Rubinius going to tackle the GIL issue? They say they're working to get rid of it, but I'd assume that a sizable chunk of the Ruby standard library isn't thread safe, especially C extensions. I guess I'm just not sure how they plan to avoid the issues that Python faces: http://docs.python.org/faq/library#can-t-we-get-rid-of-the-g...
a) The ruby standard library is written in Ruby and is actually surprisingly well-behaved from a threading perspective. The code is not super-pretty, but it uses appropriate locking strategies and has been well-tested in threaded environments. All three major implementations (JRuby, MRI and Rubinius) share the vast majority of the Ruby standard library, so if JRuby works, Rubinius will work.
2) For the part of MRI written in C (which Rubinius calls the "kernel"), Rubinius has reimplemented the entire thing mostly in Ruby with some primitives. Since they own that code, it is their responsibility to define its semantics when run in parallel.
3) Rubinius implements its locking classes (like Mutex and ConditionVariable, see https://github.com/evanphx/rubinius/blob/master/lib/thread.r...) on top of its own low-level Channel implementation (see https://github.com/evanphx/rubinius/blob/master/kernel/boots...), which can be used to implement more sophisticated locking strategies. They have been working on this for a long time, and have been planning for it even longer.
Earlier quoted context omitted.
C extensions are a very big reason why not; the pain of demand-starting JVMs is another minor reason.
I suppose it depends on what you're using ruby for. I use it for long running processes like rails apps so the jvm startup time really doesn't matter. And jruby has support for c extensions that use ffi.
I'll put forward a more blunt answer: because Rubinius is the only tenable way forward, long-term, for Ruby. MRI is a steaming pile. (Note: You're not allowed to disagree with this unless you're a C programmer that's spent some quality time with MRI's code.) It seriously shook my faith in Ruby the first time I had to dive into MRI's code: "Could someone who waxes poetic about elegance and fun in coding really produce…
There is a massive amount of bad code on the intertubes that has been around for decades, and I kind of hope we will not be programming in ruby when it's 40 years old.
How is Rubinius going to tackle the GIL issue? They say they're working to get rid of it, but I'd assume that a sizable chunk of the Ruby standard library isn't thread safe, especially C extensions. I guess I'm just not sure how they plan to avoid the issues that Python faces: http://docs.python.org/faq/library#can-t-we-get-rid-of-the-g...
A few points: a) The ruby standard library is written in Ruby and is actually surprisingly well-behaved from a threading perspective. The code is not super-pretty, but it uses appropriate locking strategies and has been well-tested in threaded environments. All three major implementations (JRuby, MRI and Rubinius) share the vast majority of the Ruby standard library, so if JRuby works, Rubinius will work. 2) For the…
Since rubinius provides the same C-api ruby does (ignoring FFI for now) wouldn't all the accesses to external libraries need to be wrapped in a shared big lock?
Earlier quoted context omitted.
A few points: a) The ruby standard library is written in Ruby and is actually surprisingly well-behaved from a threading perspective. The code is not super-pretty, but it uses appropriate locking strategies and has been well-tested in threaded environments. All three major implementations (JRuby, MRI and Rubinius) share the vast majority of the Ruby standard library, so if JRuby works, Rubinius will work. 2) For the…
grandparent was probably thinking of how you avoid the GIL if existing extensions are written expecting to be used by a single thread. Since rubinius provides the same C-api ruby does (ignoring FFI for now) wouldn't all the accesses to external libraries need to be wrapped in a shared big lock?
We've got some other ideas to increase concurrency in extensions, but the crux is that yes, we have to perform some locking because people wrap thread unsafe libraries.
Because Rubinius does not use the C-API to implement anything in the core, this doesn't impact general concurrency.
Why not use http://jruby.org ?
C extensions are a very big reason why not; the pain of demand-starting JVMs is another minor reason.
Earlier quoted context omitted.
C extensions are a very big reason why not; the pain of demand-starting JVMs is another minor reason.
The second is actually much less painful than people generally think. Jruby -e 'some code' only takes half a second on my machine, which is fast enough to not be a problem. The main slowness people experience has to do with loading gems, usually via rubygems. That is painfully slow, but does not have anything to do with JVM startup time.
Earlier quoted context omitted.
The second is actually much less painful than people generally think. Jruby -e 'some code' only takes half a second on my machine, which is fast enough to not be a problem. The main slowness people experience has to do with loading gems, usually via rubygems. That is painfully slow, but does not have anything to do with JVM startup time.
"jruby -e 1", cold start, just took 4 seconds for me. I use jruby interactively almost every day (it's extremely handy in penetration testing), and I'm pretty sure jruby is noticeably slower to start than MRI.
time jruby -e 1
real 0m0.514s
user 0m0.510s
sys 0m0.040s
Earlier quoted context omitted.
"jruby -e 1", cold start, just took 4 seconds for me. I use jruby interactively almost every day (it's extremely handy in penetration testing), and I'm pretty sure jruby is noticeably slower to start than MRI.
It's definitely noticably slower, but 4 seconds per startup would make it unusable for me. However, since it's time jruby -e 1 real 0m0.514s user 0m0.510s sys 0m0.040s I find it acceptable (could it be the SSD in my laptop that makes such a large difference?). As http://jira.codehaus.org/browse/JRUBY-5181 shows, as soon as some gems come into the picture, actual startup times deteriorate rapidly.