6 ms·

Rubinius Announces Plans for GIL Elimination, JIT Improvements, Targetable VM

90 points by cscotta 16y ago

clyfe 16y ago
Does any python implementation have non-GIL threading?
- kingkilr 16y ago
  Both Jython and IronPython. PyPy probably will in the future, however its not a goal at the moment.
  - tmorgan 16y ago
    pypy also supports stackless style microthreads: http://codespeak.net/pypy/dist/pypy/doc/stackless.html http://codespeak.net/pypy/dist/pypy/doc/stackless.html but, yes, system level threads are GIL based.
- beagle3 16y ago
  Also, long ago there was Prothon, which wasn't exacyly python but was very close, and didn't have a GIL. Unfortunately, it seems all source code drops of this disappeared from the earth, though you can still find some mentions e.g. http://blog.ianbicking.org/initial-thoughts-on-prothon.html http://blog.ianbicking.org/initial-thoughts-on-prothon.html I don't remember how Vyper worked, but it might have abolished the GIL too: http://got.net/~landauer/sw/vyper_readme.html http://got.net/~landauer/sw/vyper_readme.html
jshen 16y ago
You can also use jruby now. I'm not trying to diminish rubinius, I hope it works out well and I worked with one of the contributors, but I've been using jruby for a while now and it's great.
poet 16y ago
Beautiful example how a combination of open source enthusiasm and commercial interest can generate some first class software. There's no way this could have happened without Evan's initial enthusiasm or Engine Yard's support. TBH I can list off dozens of open source projects that are one sponsor away from another level greatness. :P
- updog 16y ago
  You mean, can generate some plans for some first class software. ;)
  - gregwebs 16y ago
    my understanding is that rubinius is production ready (and "first class") software today. If they could offer a real performance improvement over MRI 1.9 they would be more compelling. Rubinius is also a much more compelling environment to develop the Ruby language in, but they just don't support Windows and all the 1.9 changes yet.
    - joe_the_user 16y ago
      I would say that Rubinius needs to be significantly faster than MRI and production ready to be successful. Otherwise, it's an "option" and having "lots of interesting options" at the level of your language is actually detriment to your development process. As someone said, you want your setup to be "as boring as possible" so you can concentrate on your application code instead. Having "lots of exciting choices" in your web server, your database, your object server, your language implementation, or monitor size just says your time will be sucked from real work. <almost a flame> I have been tempted, in the past, to wildly claim that if you compare Rubinius' relative failure compared to PyPy, Rubinius is kind of a poster-child of Test Driven Development's failure. IE, languages need semi-formal specs, not tests that claims they are a standard (no amount of testing can prove two implementation equivalent). </almost a flame> <CAVEAT>But listening to the PyPy folks describe their process, I realize this stuff is uber-hard and I'd just like to hear what a real compiler developer would say about this. </CAVEAT>
      - poet 16y ago
        This rant seems misplaced. Rubinius adopted a test driven approach for testing Ruby compatibility because Ruby doesn't have a spec, merely a reference implementation. The spec is being worked on, but the fact that it doesn't exist has more to do with Matz and Ruby's culture than Rubinius. Further, your other objections also appear to be rooted in a misunderstanding of Ruby's culture. The fact that there are lots of choices in the Ruby's ecosystem is what Ruby is about. Hell, choice is built right into Ruby with its inheritance model. Python is the opposite, and I'm guessing that's what your background is in.
glenjamin 16y ago
I've never been massively keen on the carious implementations of ruby, they're all a bit different and those differences appear to be documented poorly. This is most visible if compared to the python landscape.
- tedunangst 16y ago
  I'm afraid that the only explanation I can formulate for your comment is that you are simply unaware of alternative python implementations, because the differences between rubies and pythons are documented approximately evenly.
- tierack 16y ago
  I don't have a handle on the Python implementation landscape, but the various Rubies all regularly contribute to rubyspec[0] and report on how they're doing. And with rvm[1] it's incredibly easy to test code across rubies. From where I'm sitting, it seems dead simple to find the differences and how they could affect me. 0: https://github.com/rubyspec/rubyspec https://github.com/rubyspec/rubyspec 1: http://rvm.beginrescueend.com/ http://rvm.beginrescueend.com/
  - glenjamin 16y ago
    I admit I perhaps haven't looked into this as much as I perhaps should have before making that claim. My understanding is that the rubyspec project (http://rubyspec.org/ http://rubyspec.org/), is an effort to retrospectively document all the stuff the language does. Compare ruby: http://eigenclass.org/hiki.rb?Changes+in+Ruby+1.9 http://eigenclass.org/hiki.rb?Changes+in+Ruby+1.9, to python: http://docs.python.org/dev/whatsnew/2.7.html http://docs.python.org/dev/whatsnew/2.7.html I appreciate this isn't a great example, as python 2.7 isn't a different implementation (ruby 1.8 -> 1.9 is though), but this has been my experience of the way things are documented language-wise.
- koenigdavidmj 16y ago
  The Ruby approach is that you should have good enough unit tests to make sure that you can pass everywhere you want. That is also a generally good idea with other dynamic languages, as you get checks that the compiler provides on static languages (like making sure that if you renamed a method, you renamed calls to that method everywhere).
ekidd 16y ago
This is really great news: I spent some time digging around in the Rubinius JIT in December, and realized that it wasn't going to generate significantly better code until the byte codes were replaced with an intermediate representation that made type checks visible to the optimizer. In the long run, Ruby implementations will be at least 1 order of magnitude faster than either MRI 1.9 or JRuby. And I'm glad to see that the Rubinius folks are taking the necessary steps to get there.

90 points by cscotta 16y ago

clyfe 16y ago

Does any python implementation have non-GIL threading?

kingkilr 16y ago
Both Jython and IronPython. PyPy probably will in the future, however its not a goal at the moment.
- tmorgan 16y ago
  pypy also supports stackless style microthreads: http://codespeak.net/pypy/dist/pypy/doc/stackless.html http://codespeak.net/pypy/dist/pypy/doc/stackless.html but, yes, system level threads are GIL based.
beagle3 16y ago
Also, long ago there was Prothon, which wasn't exacyly python but was very close, and didn't have a GIL. Unfortunately, it seems all source code drops of this disappeared from the earth, though you can still find some mentions e.g. http://blog.ianbicking.org/initial-thoughts-on-prothon.html http://blog.ianbicking.org/initial-thoughts-on-prothon.html I don't remember how Vyper worked, but it might have abolished the GIL too: http://got.net/~landauer/sw/vyper_readme.html http://got.net/~landauer/sw/vyper_readme.html

jshen 16y ago

You can also use jruby now. I'm not trying to diminish rubinius, I hope it works out well and I worked with one of the contributors, but I've been using jruby for a while now and it's great.

poet 16y ago

Beautiful example how a combination of open source enthusiasm and commercial interest can generate some first class software. There's no way this could have happened without Evan's initial enthusiasm or Engine Yard's support. TBH I can list off dozens of open source projects that are one sponsor away from another level greatness. :P

updog 16y ago
You mean, can generate some plans for some first class software. ;)
- gregwebs 16y ago
  my understanding is that rubinius is production ready (and "first class") software today. If they could offer a real performance improvement over MRI 1.9 they would be more compelling. Rubinius is also a much more compelling environment to develop the Ruby language in, but they just don't support Windows and all the 1.9 changes yet.
  - joe_the_user 16y ago
    I would say that Rubinius needs to be significantly faster than MRI and production ready to be successful. Otherwise, it's an "option" and having "lots of interesting options" at the level of your language is actually detriment to your development process. As someone said, you want your setup to be "as boring as possible" so you can concentrate on your application code instead. Having "lots of exciting choices" in your web server, your database, your object server, your language implementation, or monitor size just says your time will be sucked from real work. <almost a flame> I have been tempted, in the past, to wildly claim that if you compare Rubinius' relative failure compared to PyPy, Rubinius is kind of a poster-child of Test Driven Development's failure. IE, languages need semi-formal specs, not tests that claims they are a standard (no amount of testing can prove two implementation equivalent). </almost a flame> <CAVEAT>But listening to the PyPy folks describe their process, I realize this stuff is uber-hard and I'd just like to hear what a real compiler developer would say about this. </CAVEAT>
    - poet 16y ago
      This rant seems misplaced. Rubinius adopted a test driven approach for testing Ruby compatibility because Ruby doesn't have a spec, merely a reference implementation. The spec is being worked on, but the fact that it doesn't exist has more to do with Matz and Ruby's culture than Rubinius. Further, your other objections also appear to be rooted in a misunderstanding of Ruby's culture. The fact that there are lots of choices in the Ruby's ecosystem is what Ruby is about. Hell, choice is built right into Ruby with its inheritance model. Python is the opposite, and I'm guessing that's what your background is in.

glenjamin 16y ago

I've never been massively keen on the carious implementations of ruby, they're all a bit different and those differences appear to be documented poorly. This is most visible if compared to the python landscape.

tedunangst 16y ago
I'm afraid that the only explanation I can formulate for your comment is that you are simply unaware of alternative python implementations, because the differences between rubies and pythons are documented approximately evenly.
tierack 16y ago
I don't have a handle on the Python implementation landscape, but the various Rubies all regularly contribute to rubyspec[0] and report on how they're doing. And with rvm[1] it's incredibly easy to test code across rubies. From where I'm sitting, it seems dead simple to find the differences and how they could affect me. 0: https://github.com/rubyspec/rubyspec https://github.com/rubyspec/rubyspec 1: http://rvm.beginrescueend.com/ http://rvm.beginrescueend.com/
- glenjamin 16y ago
  I admit I perhaps haven't looked into this as much as I perhaps should have before making that claim. My understanding is that the rubyspec project (http://rubyspec.org/ http://rubyspec.org/), is an effort to retrospectively document all the stuff the language does. Compare ruby: http://eigenclass.org/hiki.rb?Changes+in+Ruby+1.9 http://eigenclass.org/hiki.rb?Changes+in+Ruby+1.9, to python: http://docs.python.org/dev/whatsnew/2.7.html http://docs.python.org/dev/whatsnew/2.7.html I appreciate this isn't a great example, as python 2.7 isn't a different implementation (ruby 1.8 -> 1.9 is though), but this has been my experience of the way things are documented language-wise.
koenigdavidmj 16y ago
The Ruby approach is that you should have good enough unit tests to make sure that you can pass everywhere you want. That is also a generally good idea with other dynamic languages, as you get checks that the compiler provides on static languages (like making sure that if you renamed a method, you renamed calls to that method everywhere).

ekidd 16y ago

This is really great news: I spent some time digging around in the Rubinius JIT in December, and realized that it wasn't going to generate significantly better code until the byte codes were replaced with an intermediate representation that made type checks visible to the optimizer. In the long run, Ruby implementations will be at least 1 order of magnitude faster than either MRI 1.9 or JRuby. And I'm glad to see that the Rubinius folks are taking the necessary steps to get there.