5 ms·

Ruby is already the slowest widely-used programming language, by a fairly significant margin. Ruby 1.8.7 routinely runs a 1/200th the speed of C code. For compa

by ekidd 16y ago

Ruby is already the slowest widely-used programming language, by a fairly significant margin. Ruby 1.8.7 routinely runs a 1/200th the speed of C code. For comparison, other dynamic languages run at 1/2th to 1/60th the speed of C. This is better in Ruby 1.9 (getting up into the 1/60th range). But Ruby is still a painfully slow language. Some unscientific benchmark plots here (note the log scale!): http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php?gpp=on&java=on&luajit=on&ghc=on&sbcl=on&racket=on&v8=on&jruby=on&python3=on&yarv=on&ruby=on&calc=chart http://shootout.alioth.debian.org/u32/which-programming-lang... JRuby and Rubinius have been working to improve Ruby performance. In theory, it might possible for Ruby to run at 1/2th to 1/10th the speed of C using an aggressive tracing and optimizing compiler similar to LuaJIT. But this proposed feature really makes me cringe: If refinements require frequently invalidating method caches, Ruby performance will always be horrible. I'd rather sacrifice a tiny amount of expressiveness and have my code run 50x faster, thank you. :-) EDIT: Note that there are some very cheap ways to implement a similar feature, including the way Common LISP supports package-scoped symbols.

compay 16y ago
It amazes me when I go to conferences and I see how many people are still using 1.8 rather than 1.9 or JRuby, which may not be comparable to LuaJIT but offer much more respectable performance. I also really sympathize with the notion of sacrificing some degree of expressiveness for performance. If this feature is to be added, it needs to be done in such a way that it does not set back the hard-earned performance improvements of the last few years. Then again, expressiveness is Ruby's niche, and DHH's famous quote about "sacrificing CPU cycles in favor of developer cycles" is quite valid, IMHO. If you need raw performance you should look to another language because I don't think that will ever be too high a priority for Ruby. Github uses Node and (IIRC) Erlang for some stuff, and Twitter uses Scala - if you're lucky enough to have the kinds of problems those guys have, then the best bet is usually to use Ruby where it gets you a developer speedup and another language for the parts of your app where performance is absolutely critical.
- steveklabnik 16y ago
  While I try to start all of my new projects in 1.9, there are still good reasons to stick with 1.8. There are still a bunch of incompatibilities with gems, certain distributions coughUbuntucough still distribute 1.8 under the 'ruby' package, and large amounts of legacy code that's not 1.9 ready, for example. That said, even though 1.8 is slow as a dog, often, it's _fast enough_. Your last paragraph hits it on the head.
  - krainboltgreene 16y ago
    Anytime someone asks for help on installing Ruby on Ubuntu I tell them to avoid the package manager. Use RVM, it's a small bit of overhead that greatly increases productivity and reduces headaches.
    - steveklabnik 16y ago
      Absolutely, and with .rvmrc files, you don't even need to think about it.
      - krainboltgreene 16y ago
        God yeah, I just got introduced to .rvmrc files. Talk about insane awesome. The next programming language I use full time will have to have all the RVM features and utilities built into their RubyGem like utility, or I'm not even going to bother.
- ekidd 16y ago
  If you need raw performance you should look to another language because I don't think that will ever be too high a priority for Ruby. I reject this philosophy: Lua is also a highly expressive programming language, and LuaJIT runs 75 to 100 times faster than Ruby 1.8. There's no reason why the Ruby community should settle for lousy performance. I'm trying to track down a bug in the Rubinius JIT as I speak. Rubinius may be faster than 1.9, but I can still see dozens of really obvious optimization opportunities. If nobody screws up method caching, Ruby will eventually be 10 times faster than it is today.
willcannings 16y ago
Other implementations you haven't mentioned like MacRuby are much faster. In my totally unscientific and completely biased benchmarks (small tests related to the type of work I do mainly - Machine Learning) MacRuby is now faster than Python (2.6) and is closing the gap on V8 (which, in the tests I wrote, was even faster than Go, and less than twice as slow as C).

by ekidd 16y ago

compay 16y ago

It amazes me when I go to conferences and I see how many people are still using 1.8 rather than 1.9 or JRuby, which may not be comparable to LuaJIT but offer much more respectable performance. I also really sympathize with the notion of sacrificing some degree of expressiveness for performance. If this feature is to be added, it needs to be done in such a way that it does not set back the hard-earned performance improvements of the last few years. Then again, expressiveness is Ruby's niche, and DHH's famous quote about "sacrificing CPU cycles in favor of developer cycles" is quite valid, IMHO. If you need raw performance you should look to another language because I don't think that will ever be too high a priority for Ruby. Github uses Node and (IIRC) Erlang for some stuff, and Twitter uses Scala - if you're lucky enough to have the kinds of problems those guys have, then the best bet is usually to use Ruby where it gets you a developer speedup and another language for the parts of your app where performance is absolutely critical.

steveklabnik 16y ago
While I try to start all of my new projects in 1.9, there are still good reasons to stick with 1.8. There are still a bunch of incompatibilities with gems, certain distributions coughUbuntucough still distribute 1.8 under the 'ruby' package, and large amounts of legacy code that's not 1.9 ready, for example. That said, even though 1.8 is slow as a dog, often, it's _fast enough_. Your last paragraph hits it on the head.
- krainboltgreene 16y ago
  Anytime someone asks for help on installing Ruby on Ubuntu I tell them to avoid the package manager. Use RVM, it's a small bit of overhead that greatly increases productivity and reduces headaches.
  - steveklabnik 16y ago
    Absolutely, and with .rvmrc files, you don't even need to think about it.
    - krainboltgreene 16y ago
      God yeah, I just got introduced to .rvmrc files. Talk about insane awesome. The next programming language I use full time will have to have all the RVM features and utilities built into their RubyGem like utility, or I'm not even going to bother.
ekidd 16y ago
If you need raw performance you should look to another language because I don't think that will ever be too high a priority for Ruby. I reject this philosophy: Lua is also a highly expressive programming language, and LuaJIT runs 75 to 100 times faster than Ruby 1.8. There's no reason why the Ruby community should settle for lousy performance. I'm trying to track down a bug in the Rubinius JIT as I speak. Rubinius may be faster than 1.9, but I can still see dozens of really obvious optimization opportunities. If nobody screws up method caching, Ruby will eventually be 10 times faster than it is today.

willcannings 16y ago

Other implementations you haven't mentioned like MacRuby are much faster. In my totally unscientific and completely biased benchmarks (small tests related to the type of work I do mainly - Machine Learning) MacRuby is now faster than Python (2.6) and is closing the gap on V8 (which, in the tests I wrote, was even faster than Go, and less than twice as slow as C).