13 ms·

I didn't say anything about penalizing. Microsoft clearly differentiates versions of SQL Server. That's all I'm asking for. If JRuby performance continues to

by ssmoot 15y ago

I didn't say anything about penalizing. Microsoft clearly differentiates versions of SQL Server. That's all I'm asking for. If JRuby performance continues to match or exceed Rubinius performance, but JRuby also gives me deployment flexibility and Java OSS integration options Rubinius doesn't, why would I choose Rubinius for my next green-field project? That's not an accusation. It's a serious question. I think Evan's answer on the Ruby C API is a pretty compelling reason on it's own. For businesses that don't have an easy JRuby migration path because of dependencies on multiple gems with C-extensions, maybe Rubinius is a much easier way to get into the next JRuby/Rubinius/YARV Ruby performance bracket. That can be very compelling on it's own. What are some other reasons I might consider Rubinius? Given the down-votes I guess I'm in the minority, but I think it's a fair question. I was an early supporter of Rubinius, and put my money where my mouth was on more than one occasion with cash donations to the project. I get that it's very neat from an academic standpoint. No argument here. Is it something EngineYard is going to stand behind and just as importantly, start marketing so I get a good feel for the practical uses?

mitchty 15y ago
For my needs, jruby will never suffice as java isn't going to be installed on the servers I'm on. Nor to be honest would I want it, and JNI for c extensions is also a nonstarter. We have puppet at work for server deploys, and well, jruby may suffice for web/app server deploys that just run rails. But not all ruby users actually give a rats about rails (that's me, don't use it at all at work), nor do we have a need for java interop. Basically I'm in the exact opposite of your vantage. I need c bindings for a few gems I made that need c ffi bindings, I don't need/care/use any java interop, and personally, I'd rather not have the jvm running on any of my servers. I look at rubinius as the eventual YARV for the compiled version as YARV was to MRI, not as an academic project. But I admit, I seem to be a ruby outlier ever since rails has been around.
- ssmoot 15y ago
  I don't use Rails. I see the JVM as a tool that gives me access to code I might find useful, and web-servers that are (IMO) 1000X superior to anything available to MRI. That and much better performance than REE anyways. If you need C-extensions, well, there you go. Rubinius as a better MRI I totally get/agree with. I think we agree on that as a good reason for the season for Rubinius. It'd just be nice for EY to put up a "Why Rubinius?" page. And further, a "Which VM best targets my project? JRuby or Rubinius?" page would make me very happy. I can't imagine it could hurt the adoption of either.
- andrewvc 15y ago
  Jruby is working on cext support
  - headius 15y ago
    C ext support shipped in an "experimental" form in JRuby 1.6. The main problem is that C extensions suck in so many ways: * Can't have multiple VMs in process, because C exts load all their state into C globals * Can't run them concurrently, because they can't be trusted not to segfault * Don't participate well in modern GCs, so they have significantly higher call overhead in JRuby or Rubinius than they do in MRI FFI is a better option in almost every case, although it is admittedly a much trickier path to cross-platform library binding. The best thing the Ruby community could do to move Ruby forward is to either come up with a better C API or start using FFI for everything. C exts suck.
- headius 15y ago
  Your reluctance to install Java on the servers you're on means you're missing out on one of the best Ruby implementations available. You'd be well served by putting aside your prejudice and just giving JRuby a try. That said, there's certainly domains where JRuby is not a great fit. C extension-heavy systems are one; because C extensions are so crippling to more modern VMs like the JVM or Rubinius, you're better off using the implementation the C API was designed for (MRI). Or if Rubinius suits your needs and C extensions work well enough, I'll recommend Rubinius over JRuby any day. I hate C extensions, or at least I hate them in the form they exist in MRI, since they're invasive and damaging to modern VM features like good GC and concurrent threads. In any case, it's worth seeing if FFI (the Ruby API that Rubinius pioneered and JRuby made generally available) serves your purposes, because it works extremely well in JRuby and requires no C extension support. And I'd suggest you actually give JRuby a try; it's so much more than "Ruby for Java interop" and may work better as a "plain old Ruby impl" than you expect.
  - tptacek 15y ago
    I just used JRuby FFI to implement a native x86-64 debugger on WinAPI; we had x86 working for a long time on Win32, Linux, and OSX using MRI, and JRuby was actually the only way to get around LP64 issues with MRI. JRuby has been a compat and native code win for us; it is a better platform for accessing C code than MRI Ruby is.
    - headius 15y ago
      That's great to hear! Given that FFI is intended to work across all Ruby impls, I wish there were more attention paid to using FFI instead of C extensions. I will admit there are some usability problems, especially around cross-platform struct mapping, but the resulting libraries are vastly easier to deal with than a bunch of grotty Ruby C API code.
    - enebo 15y ago
      We have had other JRuby users state that most 64 bit stuff just works with JRuby and not so much with MRI. Thanks for sharing another example.
    - 15y ago
technomancy 15y ago
> What are some other reasons I might consider Rubinius? JRuby uses UTF-16 as its internal string encoding, so Rubinius is going to use a lot less memory. It can also boot its VM more quickly since the client hotspot JVM has been largely neglected in favour of optimizing JIT for long-running processes. I would use JRuby for sure by default, but there may be places where these two things would disqualify it. Rubinius development also feeds into JRuby--I believe JRuby uses some of Rubinius's standard library (or at least it used to), and rubyspec came from Rubinius as well.
- headius 15y ago
  JRuby uses exactly the same in-memory format as Ruby, byte[]. We also support the Encoding logic from Ruby 1.9, again atop byte[]. JRuby actually has better String performance and encoding support than Java itself in many cases. Rubinius boots negligibly faster than JRuby; for simple scripts, JRuby takes around 0.5s on my system versus 0.35s for Rubinius. All implementations that JIT to get to full speed will have startup issues. JRuby does not use any of Rubinius's standard library. We do both share most of MRI's standard library, however. As for RubySpec; Rubinius started it, and JRuby is a very heavy contributor to the project. However JRuby also runs many other Ruby test suites, so we have not been as dependent on filling out RubySpec. We do both share implementation ideas and advocate for each other in debates with ruby-core. Hopefully in the future we can work together on adding new standard APIs as well (rather than unilaterally adding them to one implementation or the other).
  - technomancy 15y ago
    I shouldn't be surprised, but my knowledge of the ruby world seems to be about two years out of date. I suppose any remaining additional memory usage is probably due to inheriting space/speed tradeoffs straight from upstream hotspot. It's great to hear that the startup time has improved so much.
    - headius 15y ago
      Actually a lot of the process size in JRuby is the fact that we need to set JVM's max size high for rare cases, but then the JVM happily grows to fill much of that size. If you choke it down to a smaller size, we're competitive with at least generational-GC impls like Rubinius (but still much larger than conservative-GC impls like MRI).

by ssmoot 15y ago

mitchty 15y ago

For my needs, jruby will never suffice as java isn't going to be installed on the servers I'm on. Nor to be honest would I want it, and JNI for c extensions is also a nonstarter. We have puppet at work for server deploys, and well, jruby may suffice for web/app server deploys that just run rails. But not all ruby users actually give a rats about rails (that's me, don't use it at all at work), nor do we have a need for java interop. Basically I'm in the exact opposite of your vantage. I need c bindings for a few gems I made that need c ffi bindings, I don't need/care/use any java interop, and personally, I'd rather not have the jvm running on any of my servers. I look at rubinius as the eventual YARV for the compiled version as YARV was to MRI, not as an academic project. But I admit, I seem to be a ruby outlier ever since rails has been around.

ssmoot 15y ago
I don't use Rails. I see the JVM as a tool that gives me access to code I might find useful, and web-servers that are (IMO) 1000X superior to anything available to MRI. That and much better performance than REE anyways. If you need C-extensions, well, there you go. Rubinius as a better MRI I totally get/agree with. I think we agree on that as a good reason for the season for Rubinius. It'd just be nice for EY to put up a "Why Rubinius?" page. And further, a "Which VM best targets my project? JRuby or Rubinius?" page would make me very happy. I can't imagine it could hurt the adoption of either.
andrewvc 15y ago
Jruby is working on cext support
- headius 15y ago
  C ext support shipped in an "experimental" form in JRuby 1.6. The main problem is that C extensions suck in so many ways: * Can't have multiple VMs in process, because C exts load all their state into C globals * Can't run them concurrently, because they can't be trusted not to segfault * Don't participate well in modern GCs, so they have significantly higher call overhead in JRuby or Rubinius than they do in MRI FFI is a better option in almost every case, although it is admittedly a much trickier path to cross-platform library binding. The best thing the Ruby community could do to move Ruby forward is to either come up with a better C API or start using FFI for everything. C exts suck.
headius 15y ago
Your reluctance to install Java on the servers you're on means you're missing out on one of the best Ruby implementations available. You'd be well served by putting aside your prejudice and just giving JRuby a try. That said, there's certainly domains where JRuby is not a great fit. C extension-heavy systems are one; because C extensions are so crippling to more modern VMs like the JVM or Rubinius, you're better off using the implementation the C API was designed for (MRI). Or if Rubinius suits your needs and C extensions work well enough, I'll recommend Rubinius over JRuby any day. I hate C extensions, or at least I hate them in the form they exist in MRI, since they're invasive and damaging to modern VM features like good GC and concurrent threads. In any case, it's worth seeing if FFI (the Ruby API that Rubinius pioneered and JRuby made generally available) serves your purposes, because it works extremely well in JRuby and requires no C extension support. And I'd suggest you actually give JRuby a try; it's so much more than "Ruby for Java interop" and may work better as a "plain old Ruby impl" than you expect.
- tptacek 15y ago
  I just used JRuby FFI to implement a native x86-64 debugger on WinAPI; we had x86 working for a long time on Win32, Linux, and OSX using MRI, and JRuby was actually the only way to get around LP64 issues with MRI. JRuby has been a compat and native code win for us; it is a better platform for accessing C code than MRI Ruby is.
  - headius 15y ago
    That's great to hear! Given that FFI is intended to work across all Ruby impls, I wish there were more attention paid to using FFI instead of C extensions. I will admit there are some usability problems, especially around cross-platform struct mapping, but the resulting libraries are vastly easier to deal with than a bunch of grotty Ruby C API code.
  - enebo 15y ago
    We have had other JRuby users state that most 64 bit stuff just works with JRuby and not so much with MRI. Thanks for sharing another example.
  - 15y ago

technomancy 15y ago

> What are some other reasons I might consider Rubinius? JRuby uses UTF-16 as its internal string encoding, so Rubinius is going to use a lot less memory. It can also boot its VM more quickly since the client hotspot JVM has been largely neglected in favour of optimizing JIT for long-running processes. I would use JRuby for sure by default, but there may be places where these two things would disqualify it. Rubinius development also feeds into JRuby--I believe JRuby uses some of Rubinius's standard library (or at least it used to), and rubyspec came from Rubinius as well.

headius 15y ago
JRuby uses exactly the same in-memory format as Ruby, byte[]. We also support the Encoding logic from Ruby 1.9, again atop byte[]. JRuby actually has better String performance and encoding support than Java itself in many cases. Rubinius boots negligibly faster than JRuby; for simple scripts, JRuby takes around 0.5s on my system versus 0.35s for Rubinius. All implementations that JIT to get to full speed will have startup issues. JRuby does not use any of Rubinius's standard library. We do both share most of MRI's standard library, however. As for RubySpec; Rubinius started it, and JRuby is a very heavy contributor to the project. However JRuby also runs many other Ruby test suites, so we have not been as dependent on filling out RubySpec. We do both share implementation ideas and advocate for each other in debates with ruby-core. Hopefully in the future we can work together on adding new standard APIs as well (rather than unilaterally adding them to one implementation or the other).
- technomancy 15y ago
  I shouldn't be surprised, but my knowledge of the ruby world seems to be about two years out of date. I suppose any remaining additional memory usage is probably due to inheriting space/speed tradeoffs straight from upstream hotspot. It's great to hear that the startup time has improved so much.
  - headius 15y ago
    Actually a lot of the process size in JRuby is the fact that we need to set JVM's max size high for rare cases, but then the JVM happily grows to fill much of that size. If you choke it down to a smaller size, we're competitive with at least generational-GC impls like Rubinius (but still much larger than conservative-GC impls like MRI).