6 ms·

I just wish someone would find it in their economic interest to do for Ruby what V8 did for Javascript. Doesn't seem like there is any fundamental reason for Ru

I just wish someone would find it in their economic interest to do for Ruby what V8 did for Javascript. Doesn't seem like there is any fundamental reason for Ruby to run slower - it's just a matter of putting the (substantial) resources in to make it happen. JRuby might be the solution to this though, if they can catch up with MRI's functionality and stay on par.

gfodor 13y ago
This presumes the request time here is due to time in the CPU. Odds are what probably happened here is some underlying algorithmic or I/O change in Rails that would have slowed things down proportionally regardless of how slow the interpreter is.
cgcardona 13y ago
EDIT: Formatting For a while Phusion offered Ruby Enterprise Edition[1] which made improvements on the Ruby 1.8.7 interpreter including improvements such as: > * A “copy-on-write friendly” garbage collector, capable of reducing Ruby on Rails applications’ memory usage by 33% on average. > * The tcmalloc memory allocator, which lowers overall memory usage and boosts memory allocation speed. > * The ability to performance tune the garbage collector. > * The MBARI patch set, for improved garbage collection efficiency. > * Various analysis and debugging features. They've since dropped support of it because: > * A copy-on-write patch has recently been checked into Ruby 2.0. > * Many of the patches in Ruby Enterprise Edition are simply not necessary in 1.9. So it sounds like many of the improvements offered in Ruby Enterprise Edition 1.8.7 have been rolled into Ruby 2.0. Do you have any suggestions of what might be included in a Ruby Enterprise Edition 2.0? [1] http://blog.phusion.nl/category/ruby-enterprise-edition/ http://blog.phusion.nl/category/ruby-enterprise-edition/
- gesman 13y ago
  Is there a Ruby Startup Edition? :)
- FooBarWidget 13y ago
  I'm from Phusion. There will be no Ruby Enterprise Edition 2.0. REE has been discontinued. The original goal of REE was to incorporate our copy-on-write friendliness patches into Ruby, and to distribute it in a user-friendly form. Since then, its goal has been extended to include other useful patches as well. We've discontinued Ruby Enterprise Edition for the following reasons: 1. Ruby 2.0 incorporates (or obsoletes) all these improvements. 2. Ruby 1.8 is no longer supported even by its upstream authors. 3. We have limited resources and wanted to focus on Phusion Passenger. Since the discontinuation of REE we've made tremendous improvements in Passenger. The plan was to hand over maintainership to another interested party. Unfortunately nobody volunteered. http://blog.phusion.nl/2012/02/21/ruby-enterprise-edition-1-8-7-2012-02-released-end-of-life-imminent/ http://blog.phusion.nl/2012/02/21/ruby-enterprise-edition-1-...
cygwin98 13y ago
Twitter was in a nice position to better Ruby in terms of performance, though they chickened out and escaped to Scala. Even Twitter went public recently and posed to challenge big guys such as Google, Facebook, they've lost my respect as a technology company.
- cgcardona 13y ago
  That's a bit of an oversimplification. Here is a more in depth explanation in the form of a video of a talk called 'Twitter: From Ruby on Rails to the JVM'[1] from O'Reilly Con by Twitter engineer Raffi Krikorian who leads the Applications Services group. [1] http://www.youtube.com/watch?v=ohHdZXnsNi8 http://www.youtube.com/watch?v=ohHdZXnsNi8
  - cygwin98 13y ago
    Didn't watch this video. But as far as I recalled back then, the guys at Twitter was complaining about the slowness of Rails and MRI, as Rails was not asynchronous and MRI was CPU-bound, so instead of fixing this root cause to apply the tricks from V8 to Javascript to improve Ruby，they chose the more "pragmatic" way to use Netty that is asynchronous and Scala that is way faster. I don't accuse them of not saving the world, but Ruby and Rails lost a great opportunity to dominate the web community. If Rails were as performant as Node.js, I doubt lots of companies would change gears.
    - foobarian 13y ago
      I think organization type plays a role here too. ROR is an excellent fit for startups where speed of iteration is paramount; but once an organization settles on a business model and functionality matures a bit, the code stops changing so rapidly and the ability to do rapid development is not important any longer. At the same time performance becomes increasingly critical due to costs of scale. Hence a switch to something like scala makes perfect sense.
    - laureny 13y ago
      > I don't accuse them of not saving the world, but Ruby and Rails lost a great opportunity to dominate the web community. They didn't lose this opportunity because of Twitter, they lost it because the fact that Ruby is dynamically typed puts a hard limit on how fast it can be. Twitter tried very hard to make it scale before making the decision to switch to Java, and they just couldn't do it. The task was just impossible, switching to Java was the only reasonable decision given their constraints.
adamnemecek 13y ago
> Doesn't seem like there is any fundamental reason for Ruby to run slower. I think that all the metaprogramming magic that Ruby allows is at odds with speed. That is not to say that it's impossible to make it fast, but it's probably tricky.
- laureny 13y ago
  > I think that all the metaprogramming magic that Ruby allows is at odds with speed. I don't think so, Java and C# also have metaprogramming (reflection, class loading, bytecode manipulation) and they are still plenty fast. Ruby's liability is that it's dynamically typed, and this puts a hard limit on how fast it can be (and also on how toolable it can be, but that's a separate discussion).
  - adamnemecek 13y ago
    I mean metaprogramming support is kind of a spectrum and neither Java nor C# support it to the same degree as Ruby. For one thing and for another, C# and Java have large corporations supporting those languages which try very hard to make the runtimes fast so it's not a fair comparison.
    - pjmlp 13y ago
      Then compare it with compilers for dynamic languages like Lisp, Scheme, Dylan, Smalltalk...
      - adamnemecek 13y ago
        I said tricky, not impossible but I will, even though I'm not sure I'm really qualified to talk about these languages for one thing and for another, I think that these sort of comparisons are pretty pointless to begin with. Also I'm not sure where you are exactly going with your comment. Lisp + Scheme: I mean if nothing else, people have been trying to make them fast for the last more than half of century. Plus AFAIK most Lisp meta-programming code is generated during compile time through macros not during run-time. Dylan: I don't really know anything about Dylan but it seems to have come out of Apple and CMU, so there's that. Plus it seems to be just a Lisp dialect. Smalltalk: You consider Smalltalk fast? Lol.
lucaspiller 13y ago
There was a good talk by Charles Nutter at Baruco this year about JRuby. It looks to be pretty much there, and from the benchmarks performance looks a lot better than MRI. http://www.youtube.com/watch?v=8ZEAwWLwmfQ http://www.youtube.com/watch?v=8ZEAwWLwmfQ
- the8472 13y ago
  Last time I looked into it jruby itself was faster than MRI, especially if you take multithreading into account. But rails-on-jruby was a different story because some metaprogramming things that rails does are terrible for the JIT compilers. Charles ominously called "dark matter" inside rails.
the8472 13y ago
One of the great problems that plagues MRI is the lack of real concurrency with its global interpreter lock and the single-threaded, single-generation, stop-the-world garbage collector. That is many years behind the state-of-the-art as far as runtimes go. Dynamic webpages consisting of several widgets are quite amenable to parallelization by rendering subviews separately and just assembling them in the layout in a final step. With parallelism slow single-threaded performance can still yield reasonable response-times if you can throw multiple cores at the problem. But even if you have parallelism, a slow single-threaded GC would halt all of those threads, again affecting your response times. I don't know about V8, but mozilla's JS is suffering from similar issues. They're currently working on generational GC and it's promising to provide quite some speed-up. But the javascript runtime, just like ruby, was not designed with parallelism in mind, that's why we're seeing those webworkers which essentially spawn an isolated javascript environment. Simply because it's hard to tack on parallelism as an afterthought. Similarly one of Ruby 2.1's major performance boosts stems from the generational GC.

gfodor 13y ago

This presumes the request time here is due to time in the CPU. Odds are what probably happened here is some underlying algorithmic or I/O change in Rails that would have slowed things down proportionally regardless of how slow the interpreter is.

cgcardona 13y ago

EDIT: Formatting For a while Phusion offered Ruby Enterprise Edition[1] which made improvements on the Ruby 1.8.7 interpreter including improvements such as: > * A “copy-on-write friendly” garbage collector, capable of reducing Ruby on Rails applications’ memory usage by 33% on average. > * The tcmalloc memory allocator, which lowers overall memory usage and boosts memory allocation speed. > * The ability to performance tune the garbage collector. > * The MBARI patch set, for improved garbage collection efficiency. > * Various analysis and debugging features. They've since dropped support of it because: > * A copy-on-write patch has recently been checked into Ruby 2.0. > * Many of the patches in Ruby Enterprise Edition are simply not necessary in 1.9. So it sounds like many of the improvements offered in Ruby Enterprise Edition 1.8.7 have been rolled into Ruby 2.0. Do you have any suggestions of what might be included in a Ruby Enterprise Edition 2.0? [1] http://blog.phusion.nl/category/ruby-enterprise-edition/ http://blog.phusion.nl/category/ruby-enterprise-edition/

gesman 13y ago
Is there a Ruby Startup Edition? :)
FooBarWidget 13y ago
I'm from Phusion. There will be no Ruby Enterprise Edition 2.0. REE has been discontinued. The original goal of REE was to incorporate our copy-on-write friendliness patches into Ruby, and to distribute it in a user-friendly form. Since then, its goal has been extended to include other useful patches as well. We've discontinued Ruby Enterprise Edition for the following reasons: 1. Ruby 2.0 incorporates (or obsoletes) all these improvements. 2. Ruby 1.8 is no longer supported even by its upstream authors. 3. We have limited resources and wanted to focus on Phusion Passenger. Since the discontinuation of REE we've made tremendous improvements in Passenger. The plan was to hand over maintainership to another interested party. Unfortunately nobody volunteered. http://blog.phusion.nl/2012/02/21/ruby-enterprise-edition-1-8-7-2012-02-released-end-of-life-imminent/ http://blog.phusion.nl/2012/02/21/ruby-enterprise-edition-1-...

cygwin98 13y ago

Twitter was in a nice position to better Ruby in terms of performance, though they chickened out and escaped to Scala. Even Twitter went public recently and posed to challenge big guys such as Google, Facebook, they've lost my respect as a technology company.

cgcardona 13y ago
That's a bit of an oversimplification. Here is a more in depth explanation in the form of a video of a talk called 'Twitter: From Ruby on Rails to the JVM'[1] from O'Reilly Con by Twitter engineer Raffi Krikorian who leads the Applications Services group. [1] http://www.youtube.com/watch?v=ohHdZXnsNi8 http://www.youtube.com/watch?v=ohHdZXnsNi8
- cygwin98 13y ago
  Didn't watch this video. But as far as I recalled back then, the guys at Twitter was complaining about the slowness of Rails and MRI, as Rails was not asynchronous and MRI was CPU-bound, so instead of fixing this root cause to apply the tricks from V8 to Javascript to improve Ruby，they chose the more "pragmatic" way to use Netty that is asynchronous and Scala that is way faster. I don't accuse them of not saving the world, but Ruby and Rails lost a great opportunity to dominate the web community. If Rails were as performant as Node.js, I doubt lots of companies would change gears.
  - foobarian 13y ago
    I think organization type plays a role here too. ROR is an excellent fit for startups where speed of iteration is paramount; but once an organization settles on a business model and functionality matures a bit, the code stops changing so rapidly and the ability to do rapid development is not important any longer. At the same time performance becomes increasingly critical due to costs of scale. Hence a switch to something like scala makes perfect sense.
  - laureny 13y ago
    > I don't accuse them of not saving the world, but Ruby and Rails lost a great opportunity to dominate the web community. They didn't lose this opportunity because of Twitter, they lost it because the fact that Ruby is dynamically typed puts a hard limit on how fast it can be. Twitter tried very hard to make it scale before making the decision to switch to Java, and they just couldn't do it. The task was just impossible, switching to Java was the only reasonable decision given their constraints.

adamnemecek 13y ago

> Doesn't seem like there is any fundamental reason for Ruby to run slower. I think that all the metaprogramming magic that Ruby allows is at odds with speed. That is not to say that it's impossible to make it fast, but it's probably tricky.

laureny 13y ago
> I think that all the metaprogramming magic that Ruby allows is at odds with speed. I don't think so, Java and C# also have metaprogramming (reflection, class loading, bytecode manipulation) and they are still plenty fast. Ruby's liability is that it's dynamically typed, and this puts a hard limit on how fast it can be (and also on how toolable it can be, but that's a separate discussion).
- adamnemecek 13y ago
  I mean metaprogramming support is kind of a spectrum and neither Java nor C# support it to the same degree as Ruby. For one thing and for another, C# and Java have large corporations supporting those languages which try very hard to make the runtimes fast so it's not a fair comparison.
  - pjmlp 13y ago
    Then compare it with compilers for dynamic languages like Lisp, Scheme, Dylan, Smalltalk...
    - adamnemecek 13y ago
      I said tricky, not impossible but I will, even though I'm not sure I'm really qualified to talk about these languages for one thing and for another, I think that these sort of comparisons are pretty pointless to begin with. Also I'm not sure where you are exactly going with your comment. Lisp + Scheme: I mean if nothing else, people have been trying to make them fast for the last more than half of century. Plus AFAIK most Lisp meta-programming code is generated during compile time through macros not during run-time. Dylan: I don't really know anything about Dylan but it seems to have come out of Apple and CMU, so there's that. Plus it seems to be just a Lisp dialect. Smalltalk: You consider Smalltalk fast? Lol.

lucaspiller 13y ago

There was a good talk by Charles Nutter at Baruco this year about JRuby. It looks to be pretty much there, and from the benchmarks performance looks a lot better than MRI. http://www.youtube.com/watch?v=8ZEAwWLwmfQ http://www.youtube.com/watch?v=8ZEAwWLwmfQ

the8472 13y ago
Last time I looked into it jruby itself was faster than MRI, especially if you take multithreading into account. But rails-on-jruby was a different story because some metaprogramming things that rails does are terrible for the JIT compilers. Charles ominously called "dark matter" inside rails.

the8472 13y ago

One of the great problems that plagues MRI is the lack of real concurrency with its global interpreter lock and the single-threaded, single-generation, stop-the-world garbage collector. That is many years behind the state-of-the-art as far as runtimes go. Dynamic webpages consisting of several widgets are quite amenable to parallelization by rendering subviews separately and just assembling them in the layout in a final step. With parallelism slow single-threaded performance can still yield reasonable response-times if you can throw multiple cores at the problem. But even if you have parallelism, a slow single-threaded GC would halt all of those threads, again affecting your response times. I don't know about V8, but mozilla's JS is suffering from similar issues. They're currently working on generational GC and it's promising to provide quite some speed-up. But the javascript runtime, just like ruby, was not designed with parallelism in mind, that's why we're seeing those webworkers which essentially spawn an isolated javascript environment. Simply because it's hard to tack on parallelism as an afterthought. Similarly one of Ruby 2.1's major performance boosts stems from the generational GC.