4 ms·

I am not sure it doesn't make sense for them to just move over to JRuby and have them all focus their efforts their.

ehsanu1 10y ago
Yeah, jruby+truffle could be pretty amazing for ruby performance. However, having multiple ruby implementations is great too, and they probably would rather keep working on an independent implementation that they have full control over, and whose goals may not align perfectly with that of other implementations.
- dakull 10y ago
  As they pointed out in the interview - it's not a free meal i.e. one could expect high memory usage and slow start-up times. For me the slow start-up and the JIT requiring ~50K/req for warm-up just ruin the whole experience in coding the app in Ruby I'd rather just use Elixir. Another interesting project is IBM's OMR [0] - compared to JRuby there are no slow start-ups and weirdly, being still a dev. preview it can run Rails and its deps. without issues, even better than Rubinius stable. [0] - https://github.com/rubyomr-preview/rubyomr-preview https://github.com/rubyomr-preview/rubyomr-preview
  - ehsanu1 10y ago
    50k requests seems excessive, are you sure about that? :) Of course it depends on the implementation particulars, and profile-guided optimization may help, but needing a couple thousand requests to warm up is not so bad for a web application server that will see 100x as many requests as that. If we're very lucky, Substrate VM will be released at some point, solving the startup time issues (and I believe many of the JIT issues, though less clear on that): http://lafo.ssw.uni-linz.ac.at/papers/2013_JVMLanguageSummit_OneVMToRuleThemAll.pdf http://lafo.ssw.uni-linz.ac.at/papers/2013_JVMLanguageSummit... The OMR project definitely looks interesting, but it doesn't seem to be actively developed (or perhaps the most recent commits are just not public yet). But if it works that well, then maybe there's no need, hah. Will have to try it out.
    - igravious 10y ago
      > but it doesn't seem to be actively developed The source code is here: https://github.com/rubyomr-preview/ruby https://github.com/rubyomr-preview/ruby Seems the code is being developed internally to IBM. First the docker images of the OMR tech preview were dropped about a year ago. The the source was dropped recently. Targets Ruby 2.2 so I'm going to open an issue asking about targeting 2.3 and folding this work into trunk. $ git clone https://github.com/rubyomr-preview/ruby.git --branch ruby_2_2_omr --recursive $ cd ruby $ autoconf $ ./configure SPEC=linux_x86-64 --with-omr-jit $ make $ make install This should build it for you to try out. I urge others to try it out and give feedback.
      - magaudet 10y ago
        Hey! thanks for the shout out. I would totally love to see more feedback as well! We haven't turned on the issue tracker on that repo, but the glue has it's issues turned on: https://github.com/rubyomr-preview/rbjitglue https://github.com/rubyomr-preview/rbjitglue Working on smoothing this out a bit, and also currently working on upgrading the JIT to target 2.4
        igravious 10y ago
        Thank you for pushing Ruby performance forward! :)
    - magaudet 10y ago
      Hey, OMR developer here. Ruby+OMR is developed in three pieces: 1) the language independent core, then 2) The language dependent portions (i.e., the VM, and what we call the 'glue') The language independent core is here: https://github.com/eclipse/omr https://github.com/eclipse/omr. It's under active development, :) I'm actually working on Ruby 2.4 support right now (supremely not prime time, but if you're curious, the branch is here: https://github.com/mgaudet/ruby/tree/ruby_2_4_omr_preliminary https://github.com/mgaudet/ruby/tree/ruby_2_4_omr_preliminar...)
      - 10y ago
sams99 10y ago
At Discourse our biggest constraint we are fighting now is memory, not performance (don't get me wrong, I wish MRI was faster). JRuby is usually more memory hungry than MRI and getting reasonable boot time is not easy on JRuby. Additionally we don't even boot on JRuby today, I wish we did but it is hard to justify effort here.
- dakull 10y ago
  Did this help in any way? https://tunemygc.com https://tunemygc.com Just by playing around with RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR you can reduce memory consumption quite a bit.
  - sams99 10y ago
    I did hand tune stuff https://github.com/discourse/discourse_docker/blob/master/templates/web.template.yml#L8-L12 https://github.com/discourse/discourse_docker/blob/master/te... RUBY_GC_HEAP_GROWTH_MAX_SLOTS is critical without it you get way too much bloat. The default is very problematic I discussed this with ko1 but not sure if we can get a better default in for 2.4.
- riffraff 10y ago
  > Additionally we don't even boot on JRuby today what is the blocking issue there?
- ksec 10y ago
  Can you elaborate a little, given how memory is very cheap these days.
  - specialp 10y ago
    Memory is indeed cheap but the problem is when you run Ruby web services you have every worker taking a minimum of ~400mb. This doesn't sound like much but then with micro-services and other APIs also using that much RAM per worker it adds up fast as all of these servers also need to take this much RAM per concurrent connection you would like to support. For people starting out that is not so much a problem, but if you have moderate to large traffic you need a lot of machines just for the RAM. This is coupled with the fact that many Ruby libraries eschew streaming of files and connections and put things straight into memory despite Ruby having excellent block constructs that easily allow chunking/streaming. So apps also spike in memory and they need a large overhead as well.
MrBra 10y ago
I don't think everyone likes depending on Java.

Yeah, jruby+truffle could be pretty amazing for ruby performance. However, having multiple ruby implementations is great too, and they probably would rather keep working on an independent implementation that they have full control over, and whose goals may not align perfectly with that of other implementations.

dakull 10y ago
As they pointed out in the interview - it's not a free meal i.e. one could expect high memory usage and slow start-up times. For me the slow start-up and the JIT requiring ~50K/req for warm-up just ruin the whole experience in coding the app in Ruby I'd rather just use Elixir. Another interesting project is IBM's OMR [0] - compared to JRuby there are no slow start-ups and weirdly, being still a dev. preview it can run Rails and its deps. without issues, even better than Rubinius stable. [0] - https://github.com/rubyomr-preview/rubyomr-preview https://github.com/rubyomr-preview/rubyomr-preview
- ehsanu1 10y ago
  50k requests seems excessive, are you sure about that? :) Of course it depends on the implementation particulars, and profile-guided optimization may help, but needing a couple thousand requests to warm up is not so bad for a web application server that will see 100x as many requests as that. If we're very lucky, Substrate VM will be released at some point, solving the startup time issues (and I believe many of the JIT issues, though less clear on that): http://lafo.ssw.uni-linz.ac.at/papers/2013_JVMLanguageSummit_OneVMToRuleThemAll.pdf http://lafo.ssw.uni-linz.ac.at/papers/2013_JVMLanguageSummit... The OMR project definitely looks interesting, but it doesn't seem to be actively developed (or perhaps the most recent commits are just not public yet). But if it works that well, then maybe there's no need, hah. Will have to try it out.
  - igravious 10y ago
    > but it doesn't seem to be actively developed The source code is here: https://github.com/rubyomr-preview/ruby https://github.com/rubyomr-preview/ruby Seems the code is being developed internally to IBM. First the docker images of the OMR tech preview were dropped about a year ago. The the source was dropped recently. Targets Ruby 2.2 so I'm going to open an issue asking about targeting 2.3 and folding this work into trunk. $ git clone https://github.com/rubyomr-preview/ruby.git --branch ruby_2_2_omr --recursive $ cd ruby $ autoconf $ ./configure SPEC=linux_x86-64 --with-omr-jit $ make $ make install This should build it for you to try out. I urge others to try it out and give feedback.
    - magaudet 10y ago
      Hey! thanks for the shout out. I would totally love to see more feedback as well! We haven't turned on the issue tracker on that repo, but the glue has it's issues turned on: https://github.com/rubyomr-preview/rbjitglue https://github.com/rubyomr-preview/rbjitglue Working on smoothing this out a bit, and also currently working on upgrading the JIT to target 2.4
      - igravious 10y ago
        Thank you for pushing Ruby performance forward! :)
  - magaudet 10y ago
    Hey, OMR developer here. Ruby+OMR is developed in three pieces: 1) the language independent core, then 2) The language dependent portions (i.e., the VM, and what we call the 'glue') The language independent core is here: https://github.com/eclipse/omr https://github.com/eclipse/omr. It's under active development, :) I'm actually working on Ruby 2.4 support right now (supremely not prime time, but if you're curious, the branch is here: https://github.com/mgaudet/ruby/tree/ruby_2_4_omr_preliminary https://github.com/mgaudet/ruby/tree/ruby_2_4_omr_preliminar...)
    - 10y ago

sams99 10y ago

At Discourse our biggest constraint we are fighting now is memory, not performance (don't get me wrong, I wish MRI was faster). JRuby is usually more memory hungry than MRI and getting reasonable boot time is not easy on JRuby. Additionally we don't even boot on JRuby today, I wish we did but it is hard to justify effort here.

dakull 10y ago
Did this help in any way? https://tunemygc.com https://tunemygc.com Just by playing around with RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR you can reduce memory consumption quite a bit.
- sams99 10y ago
  I did hand tune stuff https://github.com/discourse/discourse_docker/blob/master/templates/web.template.yml#L8-L12 https://github.com/discourse/discourse_docker/blob/master/te... RUBY_GC_HEAP_GROWTH_MAX_SLOTS is critical without it you get way too much bloat. The default is very problematic I discussed this with ko1 but not sure if we can get a better default in for 2.4.
riffraff 10y ago
> Additionally we don't even boot on JRuby today what is the blocking issue there?
ksec 10y ago
Can you elaborate a little, given how memory is very cheap these days.
- specialp 10y ago
  Memory is indeed cheap but the problem is when you run Ruby web services you have every worker taking a minimum of ~400mb. This doesn't sound like much but then with micro-services and other APIs also using that much RAM per worker it adds up fast as all of these servers also need to take this much RAM per concurrent connection you would like to support. For people starting out that is not so much a problem, but if you have moderate to large traffic you need a lot of machines just for the RAM. This is coupled with the fact that many Ruby libraries eschew streaming of files and connections and put things straight into memory despite Ruby having excellent block constructs that easily allow chunking/streaming. So apps also spike in memory and they need a large overhead as well.

MrBra 10y ago

I don't think everyone likes depending on Java.