47 ms·

Some of Ruby's more excentric semantics are really hard to optimize away by a compiler. It takes a much greater effort to compile Ruby source code to machine co

Some of Ruby's more excentric semantics are really hard to optimize away by a compiler. It takes a much greater effort to compile Ruby source code to machine code of similar quality than for Lua. Since time and money are not infinite resources, especially for compiler development, you'll get worse results in practice. So, yes, language design does impact performance.

haberman 17y ago
> Some of Ruby's more excentric semantics are really hard to optimize away by a compiler. Any examples in particular? Besides name resolution and method dispatch (and callcc, but I think that may have even been removed from Ruby 1.9) none of Ruby's semantics seem all that different from Lua. Am I missing something? I guess there's also throw/catch and exceptions.
- mikemike 17y ago
  Mostly resolution and dispatch. Some of this needs very clever caching or the overhead can't be eliminated or hoisted. The control-flow constructs and iterators come to mind, too. The Rubyists certainly know about these issues, so you'll have to ask them for details.
- blasdel 17y ago
  There's also the over-featured thread implementation (especially before 1.9) Dispatch is worse than you realize due to the hackish optimizations made in MRI: if you monkeypatch a natively-method from Ruby, other native code will call the original by default.
- WalkingDead 17y ago
  Here is a step by step comparison on how cutting off ruby's features can make the JRuby implementation faster, from the guy who worked on JRuby. http://blog.headius.com/2009/04/how-jruby-makes-ruby-fast.html http://blog.headius.com/2009/04/how-jruby-makes-ruby-fast.ht... Read it, you will find it interesting. The guy also wrote a small language called Duby which used Ruby like syntax but is much more faster, because he didn't include any of those slowing down features.

47 ms·

Some of Ruby's more excentric semantics are really hard to optimize away by a compiler. It takes a much greater effort to compile Ruby source code to machine co

by mikemike 17y ago

haberman 17y ago
> Some of Ruby's more excentric semantics are really hard to optimize away by a compiler. Any examples in particular? Besides name resolution and method dispatch (and callcc, but I think that may have even been removed from Ruby 1.9) none of Ruby's semantics seem all that different from Lua. Am I missing something? I guess there's also throw/catch and exceptions.
- mikemike 17y ago
  Mostly resolution and dispatch. Some of this needs very clever caching or the overhead can't be eliminated or hoisted. The control-flow constructs and iterators come to mind, too. The Rubyists certainly know about these issues, so you'll have to ask them for details.
- blasdel 17y ago
  There's also the over-featured thread implementation (especially before 1.9) Dispatch is worse than you realize due to the hackish optimizations made in MRI: if you monkeypatch a natively-method from Ruby, other native code will call the original by default.
- WalkingDead 17y ago
  Here is a step by step comparison on how cutting off ruby's features can make the JRuby implementation faster, from the guy who worked on JRuby. http://blog.headius.com/2009/04/how-jruby-makes-ruby-fast.html http://blog.headius.com/2009/04/how-jruby-makes-ruby-fast.ht... Read it, you will find it interesting. The guy also wrote a small language called Duby which used Ruby like syntax but is much more faster, because he didn't include any of those slowing down features.