Reduction in Garbage Collection Pause Time in Ruby 2.2

[kevingadd]

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.

[dmpk2k]

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.

[the8472]

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.

[digi_owl]

This was also one of the major changes in the Android ART VM vs Dalvik.

[jamon51]

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

[rmchugh]

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]

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

[throwaway9821]

What has Google done for Python? The only story I know of is Unladen Swallow, which was a side project that ultimately failed.

[TazeTSchnitzel]

I wouldn't say Facebook funds the development of PHP per se, but they do fund the development of HHVM and they made the initial draft of the language spec.

[loganfrederick]

Enova Financial in Chicago employs Brian Shirai to work on Rubinius, a new implementation of Ruby.

http://rubini.us/

[esaym]

I could say the same for perl, or anything really.

[dons]

There's only so much money you can throw at broken language designs and still expect a reasonable return.

[fsiefken]

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 Koichi Sasada (Ko1) is also the author of the allocation tracer gem Patterson demoed: https://github.com/ko1/allocation_tracer

[Dirlewanger]

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).

[jcoder]

> 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.

[gkop]

Koichi says the performance should now be comparable to normal positional arguments.

[matthewmacleod]

biggest one is increasing connascence

Is that a valid argument? IMO, keyword arguments are just making it explicit.

[sdsykes]

>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.

[igravious]

   100 / 5 = 20 -> 100 - 20 = 80 (/ = reduction)

   100 * 5 = 500 (* = improvement)

   half full = half empty

   same difference

[jacques_chester]

See, kids? Denominators are important!

[igravious]

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?

[aikah]

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

[SEMW]

Re sound synthesis in ruby, that's already a thing -- check out http://sonic-pi.net/

[jblow]

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]

Ok, we changed the title.