9 ms·

Ruby 2.1 Garbage Collection to Address Criticism on Large Scale Deployments

66 points by DanielRibeiro 13y ago

exDM69 13y ago
You should go and read the Ruby Garbage Collector implementation. It's very straightforward to read, the code is simple but reveals why it's so slow. I won't say anything bad about it but it's not a stellar piece of software engineering. The good thing is that there's plenty of room for improvement.
- ioquatix 13y ago
  What surprises me is that there are a lot of companies using Ruby. Why don't they put their money where their mouth is? Hire a team of sufficiently skilled developers and pay them to improve the GC implementation. It isn't rocket science :)
  - mikekersehy 13y ago
    There's only so many GC engineers in the world, and the majority work in academia, industrial research labs and places like the Oracle VM team. So some web-app company isn't likely to hire one. Also they aren't interested in making some toy GC for a language they don't use.
    - ioquatix 13y ago
      Really? Seriously?
      - FooBarWidget 13y ago
        I think the guy has a good point. GC is a relatively obscure area, with few people having expertise in it. This, plus the fact that the number of Rubyists who also know C (and know C well enough to work on the GC) is very small, doesn't help the current situation. The Ruby GC is also extremely tied to the VM implementation, making it generally very hard to hack on. I made the Ruby garbage collector copy-on-write friendly several years ago.
    - justincormack 13y ago
      And this is why Silicon Valley has a hiring problem. No, you hire someone who can code C and read the GC literature. The problem space is well understood. You are not breaking new ground, just applying known algorithms.
      - dasil003 13y ago
        This is an absolutely ridiculous comment. Writing a GC for a dynamic language like Ruby is not just a question of knowing C and reading some literature. It's a massive problem to solve. This is not something that you double your burn rate in the hopes that 2-3 years down the line you can double performance of your application cluster. It's simply not worth it. Startups have immediate problems to solve or they die. And BTW, the reason we have a hiring problem is not because we are too picky about specific experience, it's because when it comes to software engineering some people have it and some people don't, and the ones who don't are the ones whose resumes are consistently out there filling up inboxes, and the ones who do are rarely looking for a job, and when they are the Facebooks, Twitters and Googles of the world are throwing around $200k + benefits like pocket change.
        justincormack 13y ago
        The OP was suggesting that only someone who had worked at Oracle could solve the problem. At least you are saying that someone who "has it" might have a chance. The issue of whether startups would fund it is a different question. Quite clearly the performance of Ruby is not in fact a huge problem for most people, and we haven't had a huge organisation that could fund stuff in the way, say, Facebook has with PHP. I haven't looked at Ruby's GC, but I am guessing it was written by one person originally, and that could be done again. The poster at the top said it was simple. Its a big problem but as I said, its not a perfect solution needed just a better one.
        coldtea 13y ago
        >This is an absolutely ridiculous comment. Writing a GC for a dynamic language like Ruby is not just a question of knowing C and reading some literature. It's a massive problem to solve. No it's not. There are tons of good GC's around. You can even improve Ruby's GC with 1990 technology. (E.g did the LuaJit guy solved a "massive problem"? Mostly by himself?)
    - astrodust 13y ago
      So this leads to the question: Why there isn't an open-source garbage collector that can be used across different projects? Surely Python, V8, and Ruby have enough in common, allocation-wise, that the code can be shared? They're all C in the back-end. It's just pointers and more pointers at the lowest level. It's not about making a toy GC, it's about making a top-rate GC that works and packaging it up as a tool.
      - Derander 13y ago
        To a certain extent that's what the JVM is -- you just have to target its bytecode :-).
        astrodust 13y ago
        That's not exactly a portable back-end toolkit you can just link in.
        Tuna-Fish 13y ago
        It's not really possible to do that with GC. It requires analyzing and dealing with basically every assumption about object lifetimes that is done within the system, and that typically requires you to read and understand every single line of code. I have worked on GC projects, and imho bolting on a good GC system on an existing language runtime is considerably harder than reimplementing the entire runtime on top of a GC platform.
      - __alexs 13y ago
        The Boehm GC [1] has been integrated with various other languages in the past. I'm aware of various attempts to get both Python and Ruby code running with it. 1. http://www.hpl.hp.com/personal/Hans_Boehm/gc/ http://www.hpl.hp.com/personal/Hans_Boehm/gc/
      - silentbicycle 13y ago
        Garbage collection is a particularly cross-cutting implementation issue, and tends to interfere with all kinds of abstraction. You're essentially making a system that knows which specific ways abstraction can be broken safely, so that you can defer resource management to it in the future. Retrofitting a GC is even harder. You can bolt on a conservative collector (like boehm-gc), sure, but that can lead to many unexpected performance issues (see e.g. http://timetobleed.com/6-line-eventmachine-bugfix-2x-faster-gc-1300-requestssec/ http://timetobleed.com/6-line-eventmachine-bugfix-2x-faster-...). Writing a virtual machine for a GC'd language and then trying to give it a portable, reasonably convenient C API convinced me that it's a significantly harder issue than most people realize. (Particularly after scrapping my third prototype!) The C API also impacts many things, and tends to bring up nasty edge cases in the GC. Lua seems to have settled on a design that works unusually well, and is worth studying. Still, Lua can safely cut corners that Python and Ruby cannot - they have threads, which also break a lot of assumptions.
  - rapind 13y ago
    I wonder if rocket scientists say "It's not like we're building a garbage collector".
  - deleted 13y ago
    [deleted]
  - cheald 13y ago
    Throwing another few boxes into your web app is significantly cheaper than hiring a GC engineer to rewrite the implementation.
BruceM 13y ago
It is too bad they aren't looking at the very nice MPS: http://www.ravenbrook.com/project/mps http://www.ravenbrook.com/project/mps
mje__ 13y ago
Is Github still running Ruby 1.8? vmg mentioned at last year's Rubyfuza they had "one of the largest 1.8 deployments in the world".
- imbriaco 13y ago
  Nope, we're on 1.9. We were briefly on 2.0 (last week) but had some minor performance regressions that we need to understand before we go back.
rustc 13y ago
Are the videos of the talks available? or more details about the implementation of the new architecture?
- lucaspiller 13y ago
  They will be eventually on http://www.baruco.org/ http://www.baruco.org/. The conference has only just finished.
- steveklabnik 13y ago
  https://news.ycombinator.com/item?id=6393413 https://news.ycombinator.com/item?id=6393413
gary4gar 13y ago
Sad fact is MRI even with no matter how much effort we put in would never would be able to match GCs of battle tested VM like JVM. so I am wondering, it makes sense to stop designing a VM & just focus on language. Perhaps, something like Truffle can be used to do the optimizations for you. Ruby on truffle is already 4-5x faster than MRI. And the ruby implementation was done by an intern in just 6months. All because power of JVM. https://twitter.com/headius/status/362616159897534465 http://www.oracle.com/technetwork/java/jvmls2013wimmer-2014084.pdf Something to keep in mind.
- riffraff 13y ago
  I wanted to find the reference but I failed. Anyway, I just wanted to counter that IIRC mike pall of luajit fame has stated that in his opinion a VM/JIT laser focused on a single language's semantics is much easier and in the end more effective than using a general purpose one. Alas, I can't find the reference, but the luajit example stands on his own. Whether designing your own VM is a better use of money&time is largely a trade off of what your targets are. E.g. HotSpot could have been a great target unless you are interested in fast startups, or whatever.
- Argorak 13y ago
  Most Ruby implementations started with awesome numbers in a ridiculous short time. Remember the time when MacRuby was 6 times as fast as MRI? Those times are over after they implemented Ruby proper and ran real world programs.
  - gary4gar 13y ago
    Curious to know what are thing in "ruby proper" that make it slow?
    - Argorak 13y ago
      For example method cache invalidation is a hot topic in dynamic languages that is often ignored in synthetic benchmarks. A Ruby example for this is: output.extend(ContentTyped) (thats from Sinatra: https://github.com/sinatra/sinatra/blob/154859f1553b8bacea97af21776cc3559bebf1c0/lib/sinatra/base.rb#L816 https://github.com/sinatra/sinatra/blob/154859f1553b8bacea97...) I am not saying that these things cannot be implemented fast, but are usually the things that get ignored in a first implementation and take a lot of work to get right and quick.
sluukkonen 13y ago
For anyone interested in how it will be implemented, see ko1's presentation slides from Euruko 2013. http://euruko2013.org/speakers/presentations/toward_more_efficient_ruby_2_1-koichi.pdf http://euruko2013.org/speakers/presentations/toward_more_eff...

66 points by DanielRibeiro 13y ago

You should go and read the Ruby Garbage Collector implementation. It's very straightforward to read, the code is simple but reveals why it's so slow. I won't say anything bad about it but it's not a stellar piece of software engineering. The good thing is that there's plenty of room for improvement.

ioquatix 13y ago
What surprises me is that there are a lot of companies using Ruby. Why don't they put their money where their mouth is? Hire a team of sufficiently skilled developers and pay them to improve the GC implementation. It isn't rocket science :)
- mikekersehy 13y ago
  There's only so many GC engineers in the world, and the majority work in academia, industrial research labs and places like the Oracle VM team. So some web-app company isn't likely to hire one. Also they aren't interested in making some toy GC for a language they don't use.
  - ioquatix 13y ago
    Really? Seriously?
    - FooBarWidget 13y ago
      I think the guy has a good point. GC is a relatively obscure area, with few people having expertise in it. This, plus the fact that the number of Rubyists who also know C (and know C well enough to work on the GC) is very small, doesn't help the current situation. The Ruby GC is also extremely tied to the VM implementation, making it generally very hard to hack on. I made the Ruby garbage collector copy-on-write friendly several years ago.
  - justincormack 13y ago
    And this is why Silicon Valley has a hiring problem. No, you hire someone who can code C and read the GC literature. The problem space is well understood. You are not breaking new ground, just applying known algorithms.
    - dasil003 13y ago
      This is an absolutely ridiculous comment. Writing a GC for a dynamic language like Ruby is not just a question of knowing C and reading some literature. It's a massive problem to solve. This is not something that you double your burn rate in the hopes that 2-3 years down the line you can double performance of your application cluster. It's simply not worth it. Startups have immediate problems to solve or they die. And BTW, the reason we have a hiring problem is not because we are too picky about specific experience, it's because when it comes to software engineering some people have it and some people don't, and the ones who don't are the ones whose resumes are consistently out there filling up inboxes, and the ones who do are rarely looking for a job, and when they are the Facebooks, Twitters and Googles of the world are throwing around $200k + benefits like pocket change.
      - justincormack 13y ago
        The OP was suggesting that only someone who had worked at Oracle could solve the problem. At least you are saying that someone who "has it" might have a chance. The issue of whether startups would fund it is a different question. Quite clearly the performance of Ruby is not in fact a huge problem for most people, and we haven't had a huge organisation that could fund stuff in the way, say, Facebook has with PHP. I haven't looked at Ruby's GC, but I am guessing it was written by one person originally, and that could be done again. The poster at the top said it was simple. Its a big problem but as I said, its not a perfect solution needed just a better one.
      - coldtea 13y ago
        >This is an absolutely ridiculous comment. Writing a GC for a dynamic language like Ruby is not just a question of knowing C and reading some literature. It's a massive problem to solve. No it's not. There are tons of good GC's around. You can even improve Ruby's GC with 1990 technology. (E.g did the LuaJit guy solved a "massive problem"? Mostly by himself?)
  - astrodust 13y ago
    So this leads to the question: Why there isn't an open-source garbage collector that can be used across different projects? Surely Python, V8, and Ruby have enough in common, allocation-wise, that the code can be shared? They're all C in the back-end. It's just pointers and more pointers at the lowest level. It's not about making a toy GC, it's about making a top-rate GC that works and packaging it up as a tool.
    - Derander 13y ago
      To a certain extent that's what the JVM is -- you just have to target its bytecode :-).
      - astrodust 13y ago
        That's not exactly a portable back-end toolkit you can just link in.
        Tuna-Fish 13y ago
        It's not really possible to do that with GC. It requires analyzing and dealing with basically every assumption about object lifetimes that is done within the system, and that typically requires you to read and understand every single line of code. I have worked on GC projects, and imho bolting on a good GC system on an existing language runtime is considerably harder than reimplementing the entire runtime on top of a GC platform.
    - __alexs 13y ago
      The Boehm GC [1] has been integrated with various other languages in the past. I'm aware of various attempts to get both Python and Ruby code running with it. 1. http://www.hpl.hp.com/personal/Hans_Boehm/gc/ http://www.hpl.hp.com/personal/Hans_Boehm/gc/
    - silentbicycle 13y ago
      Garbage collection is a particularly cross-cutting implementation issue, and tends to interfere with all kinds of abstraction. You're essentially making a system that knows which specific ways abstraction can be broken safely, so that you can defer resource management to it in the future. Retrofitting a GC is even harder. You can bolt on a conservative collector (like boehm-gc), sure, but that can lead to many unexpected performance issues (see e.g. http://timetobleed.com/6-line-eventmachine-bugfix-2x-faster-gc-1300-requestssec/ http://timetobleed.com/6-line-eventmachine-bugfix-2x-faster-...). Writing a virtual machine for a GC'd language and then trying to give it a portable, reasonably convenient C API convinced me that it's a significantly harder issue than most people realize. (Particularly after scrapping my third prototype!) The C API also impacts many things, and tends to bring up nasty edge cases in the GC. Lua seems to have settled on a design that works unusually well, and is worth studying. Still, Lua can safely cut corners that Python and Ruby cannot - they have threads, which also break a lot of assumptions.
- rapind 13y ago
  I wonder if rocket scientists say "It's not like we're building a garbage collector".
- deleted 13y ago
  [deleted]
- cheald 13y ago
  Throwing another few boxes into your web app is significantly cheaper than hiring a GC engineer to rewrite the implementation.

BruceM 13y ago

It is too bad they aren't looking at the very nice MPS: http://www.ravenbrook.com/project/mps http://www.ravenbrook.com/project/mps

mje__ 13y ago

Is Github still running Ruby 1.8? vmg mentioned at last year's Rubyfuza they had "one of the largest 1.8 deployments in the world".

imbriaco 13y ago
Nope, we're on 1.9. We were briefly on 2.0 (last week) but had some minor performance regressions that we need to understand before we go back.

rustc 13y ago

Are the videos of the talks available? or more details about the implementation of the new architecture?

lucaspiller 13y ago
They will be eventually on http://www.baruco.org/ http://www.baruco.org/. The conference has only just finished.
steveklabnik 13y ago
https://news.ycombinator.com/item?id=6393413 https://news.ycombinator.com/item?id=6393413

gary4gar 13y ago

Sad fact is MRI even with no matter how much effort we put in would never would be able to match GCs of battle tested VM like JVM. so I am wondering, it makes sense to stop designing a VM & just focus on language. Perhaps, something like Truffle can be used to do the optimizations for you. Ruby on truffle is already 4-5x faster than MRI. And the ruby implementation was done by an intern in just 6months. All because power of JVM. https://twitter.com/headius/status/362616159897534465 http://www.oracle.com/technetwork/java/jvmls2013wimmer-2014084.pdf Something to keep in mind.

riffraff 13y ago
I wanted to find the reference but I failed. Anyway, I just wanted to counter that IIRC mike pall of luajit fame has stated that in his opinion a VM/JIT laser focused on a single language's semantics is much easier and in the end more effective than using a general purpose one. Alas, I can't find the reference, but the luajit example stands on his own. Whether designing your own VM is a better use of money&time is largely a trade off of what your targets are. E.g. HotSpot could have been a great target unless you are interested in fast startups, or whatever.
Argorak 13y ago
Most Ruby implementations started with awesome numbers in a ridiculous short time. Remember the time when MacRuby was 6 times as fast as MRI? Those times are over after they implemented Ruby proper and ran real world programs.
- gary4gar 13y ago
  Curious to know what are thing in "ruby proper" that make it slow?
  - Argorak 13y ago
    For example method cache invalidation is a hot topic in dynamic languages that is often ignored in synthetic benchmarks. A Ruby example for this is: output.extend(ContentTyped) (thats from Sinatra: https://github.com/sinatra/sinatra/blob/154859f1553b8bacea97af21776cc3559bebf1c0/lib/sinatra/base.rb#L816 https://github.com/sinatra/sinatra/blob/154859f1553b8bacea97...) I am not saying that these things cannot be implemented fast, but are usually the things that get ignored in a first implementation and take a lot of work to get right and quick.

sluukkonen 13y ago

For anyone interested in how it will be implemented, see ko1's presentation slides from Euruko 2013. http://euruko2013.org/speakers/presentations/toward_more_efficient_ruby_2_1-koichi.pdf http://euruko2013.org/speakers/presentations/toward_more_eff...