5 ms·

Ruby Threads and the Global Interpreter Lock in C

56 points by montanalow 12y ago

towski 12y ago
The only question I have is, how much work is it to create a C based ruby without a global interpreter lock.
- montanalow 12y ago
  Matz mentioned off hand at the last Ruby Conf that Nobu has been experimenting without the GIL. It's scary because running code without the GIL will expose a lot of existing concurrency bugs that have been safely hidden thus far. A lot of code works fine with the GIL, since it prevents the full parallelism that would exercise all possible race conditions, so it's unlikely they'd remove it in anything other than a major release, i.e. Ruby 3.0
  - philwelch 12y ago
    He also tweeted this awhile ago: https://twitter.com/yukihiro_matz/status/495219763883163648 https://twitter.com/yukihiro_matz/status/495219763883163648 "My vague plan for Ruby GIL is 1) add more abstract concurrency e.g. actors 2) add warning when using threads directly 3) then remove GIL"
  - masklinn 12y ago
    An other issue, the one CPython has hit repeatedly when trying to remove the GIL — and the big sticking point for the core team in general — is that single-threaded performances of a naive interpreter suffer a lot when splitting the GIL: instead of a single lock which is taken and released relatively rarely, the interpreter has to juggle with many small locks which it has to acquire and release much more often. When David Beazley looked back on the GIL-less patch for CPython 1.4[0] he measured performance hits of 4x~7x. Though in the case of CPython most of the cost comes from the refcounting. MRI is not refcounted so the performance hit of finer locking would probably be lower. [0] http://dabeaz.blogspot.be/2011/08/inside-look-at-gil-removal-patch-of.html http://dabeaz.blogspot.be/2011/08/inside-look-at-gil-removal...
    - jordanthoms 12y ago
      This is where JRuby / Truffle is exciting - JRuby's been exciting for a long time and never quite reached it's potential, but with these latest projects it could become the main ruby implementation - and these complex issues are already largely solved in the JVM.
      - stormbrew 12y ago
        I really doubt jruby will ever become the main ruby implementation, as awesome as it is. The fact is that too much of the ruby ecosystem is built on calling out to C, and jruby officially abandoned cext shimming a while back. And while ffi is good, it's often not nearly as flexible. There's also the fact that because of slow startup times, the modify/test cycle can be quite frustrating compared to working with MRI. The truth is that the vast majority of ruby applications never reach a point where the steady-state post-warmup performance of jruby with pure ruby outweighs the fast-startup moderate performance of mri+cexts. And ones that do reach that point often have a better case for moving to something else anyways (including other jvm technologies that can now be shimmed on via jruby and eventually replace the whole thing).
        ianlevesque 12y ago
        Is there a write up somewhere about why they abandoned cext support? That would be interesting and I couldn't find one.
        jordanthoms 12y ago
        Truffle can reach faster performance in pure-ruby than MRI+cext. Agreed though, it'll be a uphill battle to change the interpreter of choice, and JRuby will have to have much faster startup to get it to work
        chrisseaton 12y ago
        We're working on an AOT compiled build of JRuby Truffle that has no dependency on the JVM and starts about as fast as MRI, but it's not public yet.
- dfox 12y ago
  Creating MRI/CPython/Perl5-style VM without GIL is not much harder than creating the same thing with GIL. But the problem is that converting existing implementation to not use GIL is comparable amount of work.
sandstrom 12y ago
It mentions Rubinius briefly (it doesn't have a GIL). Slightly of topic, but can anyone with better knowledge then myself of ruby implementations and internals explain why it hasn't caught much of a following (what it seems anyway, I may be wrong here). To me it seems like a pretty good idea to implement Ruby mostly in Ruby, since it makes it easier to get contributions (especially to less performance-sensitive parts of the language, e.g. parts of the standard lib).
- montanalow 12y ago
  Rubinius is neat, but for me personally (and I think most of the community) it's performance. Writing C enables optimizations by hand that still yield very significant performance gains over the best of what any other high level language (java, c++, ruby) can muster. I don't want to write C, but I'm glad someone else does so I get the benefits when I write Ruby.
  - FranzVonSuppe 12y ago
    I don't understand how you can say Java, C++, and Ruby in the same breath. They are not at all alike. Also what optimizations are available to C which are not in C++? C++ is (almost) a strict superset of C.
    - Argorak 12y ago
      Just because C++ is a superset of C doesn't mean that all C++ features are in a way comparable to C (in compiling and at runtime).
    - lmm 12y ago
      Restrict pointers in C let you write code that's faster than the C++ equivalent for functions that copy a lot of memory.
- cremno 12y ago
  CRuby's standard library is partially written in Ruby. https://github.com/ruby/ruby/tree/trunk/lib https://github.com/ruby/ruby/tree/trunk/lib Rubinius' one (called RubySL) also includes some rewrites of standard libraries, that were originally written in C. And as you may know, Rubinius itself is just Ruby code to some extent. https://github.com/rubysl https://github.com/rubysl mruby has some Ruby code, too. Even some parts of the core language are written in it. https://github.com/mruby/mruby/tree/master/mrblib https://github.com/mruby/mruby/tree/master/mrblib
pmontra 12y ago
This 3 parts series from 2013 explains in details how the GIL works http://www.jstorimer.com/blogs/workingwithcode/8085491-nobody-understands-the-gil http://www.jstorimer.com/blogs/workingwithcode/8085491-nobod... Disclaimer: it's linked in the omniref.com page too.
hardwaresofton 12y ago
Did anyone notice a popup box asking you if you "didn't find what you were looking for"? it appeared almost automatically after I moved my mouse to close the tab... Are they doing some mouse tracking and looking for rapid movement off screen (to the top of the page)? If so, that's really cool. If not, nevermind
- girvo 12y ago
  I triggered it on purpose when I saw your post, by pretending to close the tab. Pretty neat trick!
  - hardwaresofton 12y ago
    Yeah, it looks like they even do it maybe once per IP - I tried to reproduce it but couldn't, even in incognito mode. Glad I wasn't crazy

56 points by montanalow 12y ago

towski 12y ago

The only question I have is, how much work is it to create a C based ruby without a global interpreter lock.

montanalow 12y ago
Matz mentioned off hand at the last Ruby Conf that Nobu has been experimenting without the GIL. It's scary because running code without the GIL will expose a lot of existing concurrency bugs that have been safely hidden thus far. A lot of code works fine with the GIL, since it prevents the full parallelism that would exercise all possible race conditions, so it's unlikely they'd remove it in anything other than a major release, i.e. Ruby 3.0
- philwelch 12y ago
  He also tweeted this awhile ago: https://twitter.com/yukihiro_matz/status/495219763883163648 https://twitter.com/yukihiro_matz/status/495219763883163648 "My vague plan for Ruby GIL is 1) add more abstract concurrency e.g. actors 2) add warning when using threads directly 3) then remove GIL"
- masklinn 12y ago
  An other issue, the one CPython has hit repeatedly when trying to remove the GIL — and the big sticking point for the core team in general — is that single-threaded performances of a naive interpreter suffer a lot when splitting the GIL: instead of a single lock which is taken and released relatively rarely, the interpreter has to juggle with many small locks which it has to acquire and release much more often. When David Beazley looked back on the GIL-less patch for CPython 1.4[0] he measured performance hits of 4x~7x. Though in the case of CPython most of the cost comes from the refcounting. MRI is not refcounted so the performance hit of finer locking would probably be lower. [0] http://dabeaz.blogspot.be/2011/08/inside-look-at-gil-removal-patch-of.html http://dabeaz.blogspot.be/2011/08/inside-look-at-gil-removal...
  - jordanthoms 12y ago
    This is where JRuby / Truffle is exciting - JRuby's been exciting for a long time and never quite reached it's potential, but with these latest projects it could become the main ruby implementation - and these complex issues are already largely solved in the JVM.
    - stormbrew 12y ago
      I really doubt jruby will ever become the main ruby implementation, as awesome as it is. The fact is that too much of the ruby ecosystem is built on calling out to C, and jruby officially abandoned cext shimming a while back. And while ffi is good, it's often not nearly as flexible. There's also the fact that because of slow startup times, the modify/test cycle can be quite frustrating compared to working with MRI. The truth is that the vast majority of ruby applications never reach a point where the steady-state post-warmup performance of jruby with pure ruby outweighs the fast-startup moderate performance of mri+cexts. And ones that do reach that point often have a better case for moving to something else anyways (including other jvm technologies that can now be shimmed on via jruby and eventually replace the whole thing).
      - ianlevesque 12y ago
        Is there a write up somewhere about why they abandoned cext support? That would be interesting and I couldn't find one.
      - jordanthoms 12y ago
        Truffle can reach faster performance in pure-ruby than MRI+cext. Agreed though, it'll be a uphill battle to change the interpreter of choice, and JRuby will have to have much faster startup to get it to work
        chrisseaton 12y ago
        We're working on an AOT compiled build of JRuby Truffle that has no dependency on the JVM and starts about as fast as MRI, but it's not public yet.
dfox 12y ago
Creating MRI/CPython/Perl5-style VM without GIL is not much harder than creating the same thing with GIL. But the problem is that converting existing implementation to not use GIL is comparable amount of work.

sandstrom 12y ago

It mentions Rubinius briefly (it doesn't have a GIL). Slightly of topic, but can anyone with better knowledge then myself of ruby implementations and internals explain why it hasn't caught much of a following (what it seems anyway, I may be wrong here). To me it seems like a pretty good idea to implement Ruby mostly in Ruby, since it makes it easier to get contributions (especially to less performance-sensitive parts of the language, e.g. parts of the standard lib).

montanalow 12y ago
Rubinius is neat, but for me personally (and I think most of the community) it's performance. Writing C enables optimizations by hand that still yield very significant performance gains over the best of what any other high level language (java, c++, ruby) can muster. I don't want to write C, but I'm glad someone else does so I get the benefits when I write Ruby.
- FranzVonSuppe 12y ago
  I don't understand how you can say Java, C++, and Ruby in the same breath. They are not at all alike. Also what optimizations are available to C which are not in C++? C++ is (almost) a strict superset of C.
  - Argorak 12y ago
    Just because C++ is a superset of C doesn't mean that all C++ features are in a way comparable to C (in compiling and at runtime).
  - lmm 12y ago
    Restrict pointers in C let you write code that's faster than the C++ equivalent for functions that copy a lot of memory.
cremno 12y ago
CRuby's standard library is partially written in Ruby. https://github.com/ruby/ruby/tree/trunk/lib https://github.com/ruby/ruby/tree/trunk/lib Rubinius' one (called RubySL) also includes some rewrites of standard libraries, that were originally written in C. And as you may know, Rubinius itself is just Ruby code to some extent. https://github.com/rubysl https://github.com/rubysl mruby has some Ruby code, too. Even some parts of the core language are written in it. https://github.com/mruby/mruby/tree/master/mrblib https://github.com/mruby/mruby/tree/master/mrblib

pmontra 12y ago

This 3 parts series from 2013 explains in details how the GIL works http://www.jstorimer.com/blogs/workingwithcode/8085491-nobody-understands-the-gil http://www.jstorimer.com/blogs/workingwithcode/8085491-nobod... Disclaimer: it's linked in the omniref.com page too.

hardwaresofton 12y ago

Did anyone notice a popup box asking you if you "didn't find what you were looking for"? it appeared almost automatically after I moved my mouse to close the tab... Are they doing some mouse tracking and looking for rapid movement off screen (to the top of the page)? If so, that's really cool. If not, nevermind

girvo 12y ago
I triggered it on purpose when I saw your post, by pretending to close the tab. Pretty neat trick!
- hardwaresofton 12y ago
  Yeah, it looks like they even do it maybe once per IP - I tried to reproduce it but couldn't, even in incognito mode. Glad I wasn't crazy