7 ms·

Reduction in Garbage Collection Pause Time in Ruby 2.2

215 points by mparramon 12y ago

kevingadd 12y ago
Incremental garbage collection is great for realtime-ish use cases like games and multimedia, too, because if you tune the collector right, you can ensure your GC never causes you to drop frames or fail to mix a sound buffer on time. Need to hit vsync every 16ms? Just run a 1-3ms incremental GC every frame when you have time to spare, and as long as your game's theoretical performance is good enough, you won't ever hitch. This is one of Lua's advantages for game scripting because it's had a fairly solid incremental collector for a while, making it easy to give the GC a fixed chunk of time to operate in every frame so your game never pauses. Scripting is a huge boon for people doing game development, game prototyping, and multimedia scripting (toolsets like Processing, for example), so having another scripting language to choose from for that is awesome.
- digi_owl 12y ago
  This was also one of the major changes in the Android ART VM vs Dalvik.
- the8472 12y ago
  MRI still has the global interpreter lock, i.e. is effectively single-threaded for CPU-bound tasks. IO/waiting for forked jobs can be done in background threads since the lock is released on some select function calls. So while incremental GC certainly does bring down latency caused by the GC it does not bring down latency for tasks that could be parallelized.
  - chrisseaton 12y ago
    MRI is multi-threaded, even for CPU-bound tasks - it just doesn't run those threads in parallel.
    - nitrogen 12y ago
      Hence the "effectively" in the parent comment; Ruby's interpreter lock can be very problematic in threaded apps that use I/O functions from C-based gems that forget to release the lock.
      - chrisseaton 12y ago
        It's not a case of 'effectively' or not. MRI is 100%, totally, unequivocally, multi-threaded. The fact that those threads do not run in parallel is an entirely unrelated issue. Parallelism is not an essential quality of multi-threading.
        canadev 12y ago
        I don't understand what this means... Can you explain? Here's my basic understanding: MRI is a single process, with multiple threads... They can't run in parallel because of the global interpreter lock (which is used because the code in MRI is not thread safe? Meaning each thread can touch the same memory and may leave it in a broken state for another thread, so we lock access to it first...). So: there are multiple threads, I am guessing each with their own task (maybe one to run the code, one to do garbage collection, ... I have no idea), but because of the GIL they can't be parallelized. Still multi-threaded anyway.
        nitrogen 12y ago
        You can create multiple OS-level threads in MRI using Thread.new. Those threads can run code at the same time, just not Ruby code. There is a function that C extensions are supposed to call while running I/O that can block, or while running CPU-intensive non-Ruby code, that releases the global lock.
        teacup50 12y ago
        This is a completely pointless semantic distinction that nobody cares about. What makes threads interesting is parallelism; if the goal is merely cooperative or pre-emptive multitasking, where there's no concurrency, then you're "effectively" not multi-threaded as per any modern expectation.
  - nitrogen 12y ago
    If you write a C extension to do CPU-intensive stuff, you can release the lock.
- dmpk2k 12y ago
  At least in games Ruby has a hard time competing with LuaJIT; all that extra headroom is really nice to have, because 16ms isn't much at all. Having said that, GC improvements are a good thing. Some of the RPG Maker folks will be delighted when this eventually reaches them.
aikah 12y ago
nice!this will make ruby usefull for a new range of applications like games,sound synthesis,...
- SEMW 12y ago
  Re sound synthesis in ruby, that's already a thing -- check out http://sonic-pi.net/ http://sonic-pi.net/
  - fsiefken 12y ago
    o thats nice, is there something like that for creating visuals for vj-ing through ruby code - or are there ways to integrate the ruby generated music with ruby generated visuals?
  - simpsond 12y ago
    Well... there goes my weekend.
  - tomc1985 12y ago
    That looks more tedious than using a tracker
Dirlewanger 12y ago
So the keyword argument speed-up is pretty insane, but how does it compare to normal positional arguments? Is there an advantage over them too? In the bigger picture, there's obviously arguments for and against keyword arguments (biggest one is increasing connascence).
- matthewmacleod 12y ago
  biggest one is increasing connascence Is that a valid argument? IMO, keyword arguments are just making it explicit.
- gkop 12y ago
  Koichi says the performance should now be comparable to normal positional arguments.
- jcoder 12y ago
  > increasing connascence Well, you're trading connascence of position for connascence of name, which in this case is much better because you are providing context for the argument data.
fsiefken 12y ago
nice timing together with the memory profiling and optimizations of rails 4.2 with the allocation tracer gem. Also see Aaron Patterson on optimizing memory usage in Rails apps: https://www.youtube.com/watch?v=-D15q-_hdzs#t=1033 https://www.youtube.com/watch?v=-D15q-_hdzs#t=1033 Koichi Sasada (Ko1) is also the author of the allocation tracer gem Patterson demoed: https://github.com/ko1/allocation_tracer https://github.com/ko1/allocation_tracer
- deleted 12y ago
  [deleted]
rmchugh 12y ago
Ruby is a wonderful language. It would be great if there was some deep-pocketed multinational willing to fund its development in the same way as Facebook has done for PHP or Google has done for Python.
- jxf 12y ago
  Heroku pays Ko1 and Matz [0], and Heroku is owned by Salesforce, which is a public company. Granted, Salesforce doesn't have Google or FB's war chest -- but it's not like Ruby isn't being supported by companies. [0]: https://blog.heroku.com/archives/2011/7/12/matz_joins_heroku https://blog.heroku.com/archives/2011/7/12/matz_joins_heroku
  - arnvald 12y ago
    Apart from Koichi, there's one more person - Nobu - who is working on CRuby full-time. Nobu's the guy with most commits to CRuby. Matz now does not work on CRuby, only on MRuby and the language specification. It's also worth noticing that another implementation, JRuby is supported by Redhat. IIRC 2 people work on it full-time: Charles Nutter (Headius) and Thomas Enebo
    - nirvdrum 12y ago
      There's a few of us at Oracle working on an alternative backend via JRuby, as well. Chris Seaton gave a talk on it at RubyConf last week. He has a series of posts about it that are pretty good: http://www.chrisseaton.com/rubytruffle/ http://www.chrisseaton.com/rubytruffle/ Obviously, this isn't people being directly paid to work on MRI, but there are side benefits like a richer set of rubyspecs and sometimes fixes landing in MRI.
      - timr 12y ago
        That was a great talk -- really sort of mind-warping to think that there are people working on "de-optimizing" the JVM so that Ruby can run faster in the average case.
  - 12y ago
jamon51 12y ago
It's too bad that keyword arguments are semantically opposite between CRuby and RubyMotion in Ruby 2.0+. It'll cause a divergence and makes it a little more difficult for Rails+RubyMotion engineers like me to switch. I understand the reasoning behind both decisions (RubyMotion is following Objective-C's semantics, CRuby is following Python et al). For those who aren't familiar with RubyMotion's syntax: def my_method(arg1, keyword: arg2) puts arg1 puts arg2 end my_method("test", keyword: "test2") # output test test2
jblow 12y ago
Very misleading title. This is not about a GC speed up, it is about a reduction in pause time. The GC a itself is eating as many cycles as before (possibly more due to the cost of making things incremental) and they are clear about this in the article.
- dang 12y ago
  Ok, we changed the title.
  - deleted 12y ago
    [deleted]
sdsykes 12y ago
>GC pause time dropped from 16ms to about 3ms — slightly better than a 500% improvment I wouldn't call an 81% reduction a 500% improvement.
- jacques_chester 12y ago
  See, kids? Denominators are important!
- igravious 12y ago
  100 / 5 = 20 -> 100 - 20 = 80 (/ = reduction) 100 * 5 = 500 (* = improvement) half full = half empty same difference
igravious 12y ago
Even with a reasonable amount of Google-fu I can't find out how to track the development version of Ruby where these changes land with rbenv (I don't use RVM). Would some kind soul enlighten me?

215 points by mparramon 12y ago

Incremental garbage collection is great for realtime-ish use cases like games and multimedia, too, because if you tune the collector right, you can ensure your GC never causes you to drop frames or fail to mix a sound buffer on time. Need to hit vsync every 16ms? Just run a 1-3ms incremental GC every frame when you have time to spare, and as long as your game's theoretical performance is good enough, you won't ever hitch. This is one of Lua's advantages for game scripting because it's had a fairly solid incremental collector for a while, making it easy to give the GC a fixed chunk of time to operate in every frame so your game never pauses. Scripting is a huge boon for people doing game development, game prototyping, and multimedia scripting (toolsets like Processing, for example), so having another scripting language to choose from for that is awesome.

digi_owl 12y ago
This was also one of the major changes in the Android ART VM vs Dalvik.
the8472 12y ago
MRI still has the global interpreter lock, i.e. is effectively single-threaded for CPU-bound tasks. IO/waiting for forked jobs can be done in background threads since the lock is released on some select function calls. So while incremental GC certainly does bring down latency caused by the GC it does not bring down latency for tasks that could be parallelized.
- chrisseaton 12y ago
  MRI is multi-threaded, even for CPU-bound tasks - it just doesn't run those threads in parallel.
  - nitrogen 12y ago
    Hence the "effectively" in the parent comment; Ruby's interpreter lock can be very problematic in threaded apps that use I/O functions from C-based gems that forget to release the lock.
    - chrisseaton 12y ago
      It's not a case of 'effectively' or not. MRI is 100%, totally, unequivocally, multi-threaded. The fact that those threads do not run in parallel is an entirely unrelated issue. Parallelism is not an essential quality of multi-threading.
      - canadev 12y ago
        I don't understand what this means... Can you explain? Here's my basic understanding: MRI is a single process, with multiple threads... They can't run in parallel because of the global interpreter lock (which is used because the code in MRI is not thread safe? Meaning each thread can touch the same memory and may leave it in a broken state for another thread, so we lock access to it first...). So: there are multiple threads, I am guessing each with their own task (maybe one to run the code, one to do garbage collection, ... I have no idea), but because of the GIL they can't be parallelized. Still multi-threaded anyway.
        nitrogen 12y ago
        You can create multiple OS-level threads in MRI using Thread.new. Those threads can run code at the same time, just not Ruby code. There is a function that C extensions are supposed to call while running I/O that can block, or while running CPU-intensive non-Ruby code, that releases the global lock.
      - teacup50 12y ago
        This is a completely pointless semantic distinction that nobody cares about. What makes threads interesting is parallelism; if the goal is merely cooperative or pre-emptive multitasking, where there's no concurrency, then you're "effectively" not multi-threaded as per any modern expectation.
- nitrogen 12y ago
  If you write a C extension to do CPU-intensive stuff, you can release the lock.
dmpk2k 12y ago
At least in games Ruby has a hard time competing with LuaJIT; all that extra headroom is really nice to have, because 16ms isn't much at all. Having said that, GC improvements are a good thing. Some of the RPG Maker folks will be delighted when this eventually reaches them.

aikah 12y ago

nice!this will make ruby usefull for a new range of applications like games,sound synthesis,...

SEMW 12y ago
Re sound synthesis in ruby, that's already a thing -- check out http://sonic-pi.net/ http://sonic-pi.net/
- fsiefken 12y ago
  o thats nice, is there something like that for creating visuals for vj-ing through ruby code - or are there ways to integrate the ruby generated music with ruby generated visuals?
- simpsond 12y ago
  Well... there goes my weekend.
- tomc1985 12y ago
  That looks more tedious than using a tracker

Dirlewanger 12y ago

So the keyword argument speed-up is pretty insane, but how does it compare to normal positional arguments? Is there an advantage over them too? In the bigger picture, there's obviously arguments for and against keyword arguments (biggest one is increasing connascence).

matthewmacleod 12y ago
biggest one is increasing connascence Is that a valid argument? IMO, keyword arguments are just making it explicit.
gkop 12y ago
Koichi says the performance should now be comparable to normal positional arguments.
jcoder 12y ago
> increasing connascence Well, you're trading connascence of position for connascence of name, which in this case is much better because you are providing context for the argument data.

fsiefken 12y ago

nice timing together with the memory profiling and optimizations of rails 4.2 with the allocation tracer gem. Also see Aaron Patterson on optimizing memory usage in Rails apps: https://www.youtube.com/watch?v=-D15q-_hdzs#t=1033 https://www.youtube.com/watch?v=-D15q-_hdzs#t=1033 Koichi Sasada (Ko1) is also the author of the allocation tracer gem Patterson demoed: https://github.com/ko1/allocation_tracer https://github.com/ko1/allocation_tracer

deleted 12y ago
[deleted]

rmchugh 12y ago

Ruby is a wonderful language. It would be great if there was some deep-pocketed multinational willing to fund its development in the same way as Facebook has done for PHP or Google has done for Python.

jxf 12y ago
Heroku pays Ko1 and Matz [0], and Heroku is owned by Salesforce, which is a public company. Granted, Salesforce doesn't have Google or FB's war chest -- but it's not like Ruby isn't being supported by companies. [0]: https://blog.heroku.com/archives/2011/7/12/matz_joins_heroku https://blog.heroku.com/archives/2011/7/12/matz_joins_heroku
- arnvald 12y ago
  Apart from Koichi, there's one more person - Nobu - who is working on CRuby full-time. Nobu's the guy with most commits to CRuby. Matz now does not work on CRuby, only on MRuby and the language specification. It's also worth noticing that another implementation, JRuby is supported by Redhat. IIRC 2 people work on it full-time: Charles Nutter (Headius) and Thomas Enebo
  - nirvdrum 12y ago
    There's a few of us at Oracle working on an alternative backend via JRuby, as well. Chris Seaton gave a talk on it at RubyConf last week. He has a series of posts about it that are pretty good: http://www.chrisseaton.com/rubytruffle/ http://www.chrisseaton.com/rubytruffle/ Obviously, this isn't people being directly paid to work on MRI, but there are side benefits like a richer set of rubyspecs and sometimes fixes landing in MRI.
    - timr 12y ago
      That was a great talk -- really sort of mind-warping to think that there are people working on "de-optimizing" the JVM so that Ruby can run faster in the average case.
- 12y ago

jamon51 12y ago

It's too bad that keyword arguments are semantically opposite between CRuby and RubyMotion in Ruby 2.0+. It'll cause a divergence and makes it a little more difficult for Rails+RubyMotion engineers like me to switch. I understand the reasoning behind both decisions (RubyMotion is following Objective-C's semantics, CRuby is following Python et al). For those who aren't familiar with RubyMotion's syntax: def my_method(arg1, keyword: arg2) puts arg1 puts arg2 end my_method("test", keyword: "test2") # output test test2

jblow 12y ago

Very misleading title. This is not about a GC speed up, it is about a reduction in pause time. The GC a itself is eating as many cycles as before (possibly more due to the cost of making things incremental) and they are clear about this in the article.

dang 12y ago
Ok, we changed the title.
- deleted 12y ago
  [deleted]

sdsykes 12y ago

>GC pause time dropped from 16ms to about 3ms — slightly better than a 500% improvment I wouldn't call an 81% reduction a 500% improvement.

jacques_chester 12y ago
See, kids? Denominators are important!
igravious 12y ago
100 / 5 = 20 -> 100 - 20 = 80 (/ = reduction) 100 * 5 = 500 (* = improvement) half full = half empty same difference

igravious 12y ago

Even with a reasonable amount of Google-fu I can't find out how to track the development version of Ruby where these changes land with rbenv (I don't use RVM). Would some kind soul enlighten me?