4 ms·

Kind of depressing how far behind Ruby is from V8, Hotspot, CLR etc in terms of the sophistication of the GC, non-existent JIT etc. Still hoping someday someone

Kind of depressing how far behind Ruby is from V8, Hotspot, CLR etc in terms of the sophistication of the GC, non-existent JIT etc. Still hoping someday someone will make the investment needed to catch up.

IPGlider 13y ago
Like Rubinius? Or why not JRuby?
- kaffeinecoma 13y ago
  Because there's always something different that needs to be done for them once your project starts becoming non-trivial. You might need a different version of a gem (e.g. pure-java Nokogiri), or they're behind recent MRI features. And if you care about concurrency, it's different everywhere. In my personal experience I've found MRI to be the best experience simply because that's what most other people are using, and there's a lot to be gained from being in the mainstream. Don't get me wrong- I would actually love for JRuby to become the de-facto Ruby implementation. So many headaches are caused by native code in gems. And we'd have a solid foundation for GC, concurrency, etc. But that's not the current reality.
  - YorickPeterse 13y ago
    Rubinius does not need Gem replacements like you need in JRuby, it still has a compatible CAPI. > [...] or they're behind recent MRI features. Part of this is due to MRI having literally no specification process at all. Python has the PEP system, no such thing exists in Ruby land. People tried to change this in the past (http://rubyspec.org/design/ http://rubyspec.org/design/) but with little to no success so far. As a direct result of this there are only two ways to keep up to date with what changes in Ruby: 1. Follow every issue reported on bugs.ruby-lang.org, forever. 2. Wait until users report issues about something not being present, behaving differently, etc. > And if you care about concurrency, it's different everywhere. This is FUD. An implementation may offer different primitives for concurrency (e.g. Rubinius has Rubinius::Channel) but they also offer shared APIs. For example, the Thread class works across all implementations as you'd expect. Whether you use this on JRuby or Rubinius the end result is the same: proper concurrency.
- Freaky 13y ago
  For me it's always the triple-whammy of being a bit (or a lot) slower, needing vastly more memory, and having astronomical startup times. Not exactly an appealing combination.
  - nirvdrum 13y ago
    If you're seeing a situation where you need vastly more memory with JRuby, please file it. While there is a higher base memory footprint due to the JVM being booted, I've found in practice it's much better on RAM than MRI. We saved a lot of money on EC2 by switching to JRuby because servicing a new request with a thread was a lot cheaper than forking a process running Rails.
protomyth 13y ago
Kind of depressing how far it is behind all the Smalltalk VMs given the object model.
- igouy 13y ago
  Don't begrudge the Smalltalkers their crumb of comfort :-) http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all&lang=vw&lang2=yarv http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te...
stiff 13y ago
I would like to read an actual in-depth comparison. While undeniably the quality of the Ruby implementation has a long way to go, Ruby has very "loose" semantics and I think some of the optimizations that are possible for Java, JavaScript or even for Smalltalk are simply not possible for Ruby because you have less assumptions to rely upon, everything has to be looked up at runtime basically. Besides just nitty-gritty optimizations there are some high level design issues which are interesting. JVM performance is great for languages like Java, but for some reason probably related to the JVM all Java web servers seem to be multi-threaded monsters, which turns debugging into a mess and seems to make DoS attacks way easier. We use a self-hosted Jira on top of Tomcat at work, there are maybe 30 simultaneous users and every time one of them does something computationally expensive or uses some buggy functionality the whole process goes nuts, memory leaks until exhaustion, load goes to maximum etc., the whole web sever has to be restarted. With a web server with multiple worker processes you just restart the single worker and call it a day. Does anyone happen to know why the worker-based hosting model with separate worker processes seems to be completely absent from the Java world in favour of multi-threaded servers?
- pjmlp 13y ago
  I fail to see how Ruby is more dynamic than Smalltalk as I am not aware of any Ruby dynamic feature not present in Smalltalk as well. Are you aware that Hotspot was born as a Smalltalk (StrongTalk actually) JIT compiler?
  - stiff 13y ago
    I don't know Smalltalk well enough to say for sure, it's just my rather vague impression that Smalltalk is more compiler-friendly, likely based mostly on what I've read over the years about this, for example looking at: http://lambda-the-ultimate.org/node/2606 http://lambda-the-ultimate.org/node/2606 Ruby permits adding methods to individual objects; in Smalltalk, all methods reside in classes. In Ruby, it is practical and somewhat useful to add methods dynamically; in Smalltalk, the practice is generally to treat the methods and classes as static. Have also a look at: http://www.hokstad.com/the-problem-with-compiling-ruby http://www.hokstad.com/the-problem-with-compiling-ruby I don't think all those 5 problems apply equally well to Smalltalk, do they?
ksec 13y ago
I think the problem with no Ruby JIT stern from the fact there are no Ruby design spec. We have implementation and no standard. Compared to Javascript and Lua, Python or Java. Ruby may not ever catch up to the superfast LuaJIT or Javascripts V8 performance due to the nature of the languages itself. But that doesn't mean Ruby should be an order of magnitude slower then them.

IPGlider 13y ago

Like Rubinius? Or why not JRuby?

kaffeinecoma 13y ago
Because there's always something different that needs to be done for them once your project starts becoming non-trivial. You might need a different version of a gem (e.g. pure-java Nokogiri), or they're behind recent MRI features. And if you care about concurrency, it's different everywhere. In my personal experience I've found MRI to be the best experience simply because that's what most other people are using, and there's a lot to be gained from being in the mainstream. Don't get me wrong- I would actually love for JRuby to become the de-facto Ruby implementation. So many headaches are caused by native code in gems. And we'd have a solid foundation for GC, concurrency, etc. But that's not the current reality.
- YorickPeterse 13y ago
  Rubinius does not need Gem replacements like you need in JRuby, it still has a compatible CAPI. > [...] or they're behind recent MRI features. Part of this is due to MRI having literally no specification process at all. Python has the PEP system, no such thing exists in Ruby land. People tried to change this in the past (http://rubyspec.org/design/ http://rubyspec.org/design/) but with little to no success so far. As a direct result of this there are only two ways to keep up to date with what changes in Ruby: 1. Follow every issue reported on bugs.ruby-lang.org, forever. 2. Wait until users report issues about something not being present, behaving differently, etc. > And if you care about concurrency, it's different everywhere. This is FUD. An implementation may offer different primitives for concurrency (e.g. Rubinius has Rubinius::Channel) but they also offer shared APIs. For example, the Thread class works across all implementations as you'd expect. Whether you use this on JRuby or Rubinius the end result is the same: proper concurrency.
Freaky 13y ago
For me it's always the triple-whammy of being a bit (or a lot) slower, needing vastly more memory, and having astronomical startup times. Not exactly an appealing combination.
- nirvdrum 13y ago
  If you're seeing a situation where you need vastly more memory with JRuby, please file it. While there is a higher base memory footprint due to the JVM being booted, I've found in practice it's much better on RAM than MRI. We saved a lot of money on EC2 by switching to JRuby because servicing a new request with a thread was a lot cheaper than forking a process running Rails.

protomyth 13y ago

Kind of depressing how far it is behind all the Smalltalk VMs given the object model.

igouy 13y ago
Don't begrudge the Smalltalkers their crumb of comfort :-) http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all&lang=vw&lang2=yarv http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te...

stiff 13y ago

I would like to read an actual in-depth comparison. While undeniably the quality of the Ruby implementation has a long way to go, Ruby has very "loose" semantics and I think some of the optimizations that are possible for Java, JavaScript or even for Smalltalk are simply not possible for Ruby because you have less assumptions to rely upon, everything has to be looked up at runtime basically. Besides just nitty-gritty optimizations there are some high level design issues which are interesting. JVM performance is great for languages like Java, but for some reason probably related to the JVM all Java web servers seem to be multi-threaded monsters, which turns debugging into a mess and seems to make DoS attacks way easier. We use a self-hosted Jira on top of Tomcat at work, there are maybe 30 simultaneous users and every time one of them does something computationally expensive or uses some buggy functionality the whole process goes nuts, memory leaks until exhaustion, load goes to maximum etc., the whole web sever has to be restarted. With a web server with multiple worker processes you just restart the single worker and call it a day. Does anyone happen to know why the worker-based hosting model with separate worker processes seems to be completely absent from the Java world in favour of multi-threaded servers?

pjmlp 13y ago
I fail to see how Ruby is more dynamic than Smalltalk as I am not aware of any Ruby dynamic feature not present in Smalltalk as well. Are you aware that Hotspot was born as a Smalltalk (StrongTalk actually) JIT compiler?
- stiff 13y ago
  I don't know Smalltalk well enough to say for sure, it's just my rather vague impression that Smalltalk is more compiler-friendly, likely based mostly on what I've read over the years about this, for example looking at: http://lambda-the-ultimate.org/node/2606 http://lambda-the-ultimate.org/node/2606 Ruby permits adding methods to individual objects; in Smalltalk, all methods reside in classes. In Ruby, it is practical and somewhat useful to add methods dynamically; in Smalltalk, the practice is generally to treat the methods and classes as static. Have also a look at: http://www.hokstad.com/the-problem-with-compiling-ruby http://www.hokstad.com/the-problem-with-compiling-ruby I don't think all those 5 problems apply equally well to Smalltalk, do they?

ksec 13y ago

I think the problem with no Ruby JIT stern from the fact there are no Ruby design spec. We have implementation and no standard. Compared to Javascript and Lua, Python or Java. Ruby may not ever catch up to the superfast LuaJIT or Javascripts V8 performance due to the nature of the languages itself. But that doesn't mean Ruby should be an order of magnitude slower then them.