6 ms·

MacRuby Drops GIL, Gains Concurrent Threads

31 points by jcsalterego 17y ago

mcav 17y ago
Here's hoping that unladen-swallow succeeds as well.
jmtulloss 17y ago
Many people have played with removing the GIL over the years in python. The issue is not that it's impossible, but rather that it's impractical and slows down the single threaded case significantly. This article did not go into details about how C extensions manage the changes, or whether they're compatible at all. It also doesn't talk about performance penalties that may be incurred by synchronizing data structures. Until we have hard data on that, this can't be called a success. That being said, the article didn't go into any detail at all. Perhaps these questions have been answered already. Either way, this is promising step for MacRuby.
- scott_s 17y ago
  That's what I've heard about CPython's GIL, but no one has said why it slows down single threaded performance significantly. Do you happen to know? I understand that finer-grain locking incurs more overhead, but if done well, it shouldn't be a huge performance hit. The Linux kernel at one point was protected by one, big kernel lock, too, and that was successfully relaxed.
larrytheliquid 17y ago
A little more info in the mailing list status update: http://www.mail-archive.com/macruby-devel@lists.macosforge.org/msg01312.html http://www.mail-archive.com/macruby-devel@lists.macosforge.o...
davidw 17y ago
I like the Tcl approach a lot: one interpreter per thread, with message passing. That gets around the problem entirely, for a lot of things.
- moe 17y ago
  That's been possible in python for a long time using pyprocessing (part of the stdlib since 2.5 i think). No idea about ruby but don't they have something similar?
look_lookatme 17y ago
Neat. It's too bad that MacRuby is wed to, uh Macs, as it is maturing pretty quickly. I assume that's because there is not much dissonance between the broader goals of Apple's approach to Obj-C and Ruby the language. I'd like to see a day where it isn't the bastard step-child of Ruby VM's, but I somehow doubt that will happen.
- knowtheory 17y ago
  I'd like to see a day where it isn't the bastard step-child of Ruby VM's, but I somehow doubt that will happen. The JRuby guys have been saying the same thing about JRuby for a while :P MacRuby will also be installable/runnable on non-mac systems too i hear (although i guess we'll see how far that gets as well)
  - mr_eel 17y ago
    It only relies on Obj-C runtime, so it could conceivably run on any system. Given the name though, I would surmise that is low priority for the developers.
    - look_lookatme 17y ago
      I'm wondering if some of the OS X specific Frameworks have made it into the code...

31 points by jcsalterego 17y ago

mcav 17y ago

Here's hoping that unladen-swallow succeeds as well.

Many people have played with removing the GIL over the years in python. The issue is not that it's impossible, but rather that it's impractical and slows down the single threaded case significantly. This article did not go into details about how C extensions manage the changes, or whether they're compatible at all. It also doesn't talk about performance penalties that may be incurred by synchronizing data structures. Until we have hard data on that, this can't be called a success. That being said, the article didn't go into any detail at all. Perhaps these questions have been answered already. Either way, this is promising step for MacRuby.

scott_s 17y ago
That's what I've heard about CPython's GIL, but no one has said why it slows down single threaded performance significantly. Do you happen to know? I understand that finer-grain locking incurs more overhead, but if done well, it shouldn't be a huge performance hit. The Linux kernel at one point was protected by one, big kernel lock, too, and that was successfully relaxed.

larrytheliquid 17y ago

A little more info in the mailing list status update: http://www.mail-archive.com/macruby-devel@lists.macosforge.org/msg01312.html http://www.mail-archive.com/macruby-devel@lists.macosforge.o...

davidw 17y ago

I like the Tcl approach a lot: one interpreter per thread, with message passing. That gets around the problem entirely, for a lot of things.

moe 17y ago
That's been possible in python for a long time using pyprocessing (part of the stdlib since 2.5 i think). No idea about ruby but don't they have something similar?

look_lookatme 17y ago

Neat. It's too bad that MacRuby is wed to, uh Macs, as it is maturing pretty quickly. I assume that's because there is not much dissonance between the broader goals of Apple's approach to Obj-C and Ruby the language. I'd like to see a day where it isn't the bastard step-child of Ruby VM's, but I somehow doubt that will happen.

knowtheory 17y ago
I'd like to see a day where it isn't the bastard step-child of Ruby VM's, but I somehow doubt that will happen. The JRuby guys have been saying the same thing about JRuby for a while :P MacRuby will also be installable/runnable on non-mac systems too i hear (although i guess we'll see how far that gets as well)
- mr_eel 17y ago
  It only relies on Obj-C runtime, so it could conceivably run on any system. Given the name though, I would surmise that is low priority for the developers.
  - look_lookatme 17y ago
    I'm wondering if some of the OS X specific Frameworks have made it into the code...