7 ms·

Every tiny little thing like this that gets further optimized in the MRI will result in major performance gains in advanced frameworks/codebases down the road.

Every tiny little thing like this that gets further optimized in the MRI will result in major performance gains in advanced frameworks/codebases down the road. So this is great news. I'm looking forward to a near-future time when the claim Ruby=Slow! is much harder to make.

dkarapetyan 12y ago
There is an inherent overhead to all dynamically typed languages like Ruby and Python, method dispatch. Overcoming this problem is not easy and even JRuby with all the muscle of the JVM JIT is still pretty slow compared to the statically typed equivalent in Java or any other language that doesn't have to pay for method look-ups during run-time. The situation is not hopeless though and projects like Truffle/Graal (https://wiki.openjdk.java.net/display/Graal/Truffle+FAQ+and+Guidelines https://wiki.openjdk.java.net/display/Graal/Truffle+FAQ+and+...) are pushing the boundary of what is possible in terms of performance for dynamically typed languages. There is also PyPy and RPython (http://tratt.net/laurie/blog/entries/fast_enough_vms_in_fast_enough_time http://tratt.net/laurie/blog/entries/fast_enough_vms_in_fast...) which again leverages some neat JIT techniques to make things fast.
- chrisseaton 12y ago
  This is how Truffle and Graal make Ruby method dispatch fast (linking to my own blog post) http://www.chrisseaton.com/rubytruffle/how-method-dispatch-works-in-jruby-truffle/ http://www.chrisseaton.com/rubytruffle/how-method-dispatch-w....
  - nly 12y ago
    Good article, thanks. It's amazing how such relatively simple techniques get some fancy names.
- vanderZwan 12y ago
  > There is an inherent overhead to all dynamically typed languages like Ruby and Python, method dispatch I can't claim to fully understand how they pull it off (not being that familiar with compiler internals), but I thought Julia didn't suffer from this problem?
  - chrisseaton 12y ago
    Most of the problems with these languages were pretty much solved several decades ago - it's just that most language implementations don't use the techniques as they need a JIT that supports dynamic deoptimization [1], which is non-trivial to implement. [1] U. Hölzle, C. Chambers, and D. Ungar, “Debugging optimized code with dynamic deoptimization,” presented at the PLDI '92: Proceedings of the ACM SIGPLAN 1992 conference on Programming language design and implementation, New York, New York, USA, 1992, pp. 32–43.
  - ihnorton 12y ago
    Julia is really designed to feel dynamic while minimizing the run-time dynamicity the compiler must account for. Type inference and method specialization play a big role, and you can read the Julia papers (on julialang.org) for a discussion of many of the design choices. Many modern JIT compilers use multiple techniques for aggressive specialization of code sections that meet optimization heuristics (whether tracing-based or otherwise), thus carefully written JavaScript (under V8 and others), Lua (under LuaJIT) and Python (under PyPy and others) can be quite fast. On these platforms there are usually implicit or explicit language subsets and coding styles required to get maximum performance out of the compiler (as with Julia: it is possible to write slow code in any language). For example, ASM.js is an optimization-friendly, explicit subset of JavaScript.
- gsnedders 12y ago
  To be fair, JVMs are typically pretty bad at method dispatch as they typically haven't needed to worry about dynamic dispatch (because, after all, typically the main concern has been Java). JS engines have done a fair bit around dispatch, but ultimately much of that is similar to what was done in Self over twenty years ago.
  - shellac 12y ago
    That's not really true. Java linking happens very late, and so invoking methods at polymorphic call sites does have more in common with 'dynamic' languages than you might think. Hotspot has smalltalk roots, and features like inline caching at call sites together with optimistic fast paths, guards, deoptimisation, and other things that would be familiar from, say, a ruby implementation.
    - gsnedders 12y ago
      Yes — HotSpot does much of this, but the inability until recently to encode "call this function which expects some number of arguments" in the instruction set has historically been the limiting factor. invokedynamic helps a lot, but it adds enough levels of indirection that AIUI often enough isn't inlined for it to really solve everything. I wonder if a tracing JVM would handle it better? Probably.
- jrochkind1 12y ago
  Doesn't ObjC do similar method dispatch? If so, is it considered a slow language also?
  - pjmlp 12y ago
    Yes. It is quite common to cache methods (selectors) or just re-write them in the C subset, when optimizing code.
orionblastar 12y ago
I used to program in Visual BASIC 6.0 which was considered slow at the time. It is just a matter of using the proper algorithms to speed it up. Almost any programming language targeted at beginners or newbies is going to be considered slow because beginners and newbies don't know the proper algorithms and code tweeks to speed things up yet. When you deal with sloppy inefficient code, almost any language is going to be considered slow. I remember trying to make a paint program with Turbo Pascal 3.0 back in the DOS days, it was slow until I learned better algorithms in drawing things and how to write directly to video memory instead of using built in commands like plot.
- perishabledave 12y ago
  I don't think Ruby is targeted at beginners or newbies if thats what you're implying. The language seems simple at first, but once you start delving into the features that make it a dynamic language it is quite deep.
  - Rapzid 12y ago
    This stuff is always fun : https://github.com/opscode/chef/blob/master/lib/chef/node/immutable_collections.rb#L79-L85 https://github.com/opscode/chef/blob/master/lib/chef/node/im... .

dkarapetyan 12y ago

There is an inherent overhead to all dynamically typed languages like Ruby and Python, method dispatch. Overcoming this problem is not easy and even JRuby with all the muscle of the JVM JIT is still pretty slow compared to the statically typed equivalent in Java or any other language that doesn't have to pay for method look-ups during run-time. The situation is not hopeless though and projects like Truffle/Graal (https://wiki.openjdk.java.net/display/Graal/Truffle+FAQ+and+Guidelines https://wiki.openjdk.java.net/display/Graal/Truffle+FAQ+and+...) are pushing the boundary of what is possible in terms of performance for dynamically typed languages. There is also PyPy and RPython (http://tratt.net/laurie/blog/entries/fast_enough_vms_in_fast_enough_time http://tratt.net/laurie/blog/entries/fast_enough_vms_in_fast...) which again leverages some neat JIT techniques to make things fast.

chrisseaton 12y ago
This is how Truffle and Graal make Ruby method dispatch fast (linking to my own blog post) http://www.chrisseaton.com/rubytruffle/how-method-dispatch-works-in-jruby-truffle/ http://www.chrisseaton.com/rubytruffle/how-method-dispatch-w....
- nly 12y ago
  Good article, thanks. It's amazing how such relatively simple techniques get some fancy names.
vanderZwan 12y ago
> There is an inherent overhead to all dynamically typed languages like Ruby and Python, method dispatch I can't claim to fully understand how they pull it off (not being that familiar with compiler internals), but I thought Julia didn't suffer from this problem?
- chrisseaton 12y ago
  Most of the problems with these languages were pretty much solved several decades ago - it's just that most language implementations don't use the techniques as they need a JIT that supports dynamic deoptimization [1], which is non-trivial to implement. [1] U. Hölzle, C. Chambers, and D. Ungar, “Debugging optimized code with dynamic deoptimization,” presented at the PLDI '92: Proceedings of the ACM SIGPLAN 1992 conference on Programming language design and implementation, New York, New York, USA, 1992, pp. 32–43.
- ihnorton 12y ago
  Julia is really designed to feel dynamic while minimizing the run-time dynamicity the compiler must account for. Type inference and method specialization play a big role, and you can read the Julia papers (on julialang.org) for a discussion of many of the design choices. Many modern JIT compilers use multiple techniques for aggressive specialization of code sections that meet optimization heuristics (whether tracing-based or otherwise), thus carefully written JavaScript (under V8 and others), Lua (under LuaJIT) and Python (under PyPy and others) can be quite fast. On these platforms there are usually implicit or explicit language subsets and coding styles required to get maximum performance out of the compiler (as with Julia: it is possible to write slow code in any language). For example, ASM.js is an optimization-friendly, explicit subset of JavaScript.
gsnedders 12y ago
To be fair, JVMs are typically pretty bad at method dispatch as they typically haven't needed to worry about dynamic dispatch (because, after all, typically the main concern has been Java). JS engines have done a fair bit around dispatch, but ultimately much of that is similar to what was done in Self over twenty years ago.
- shellac 12y ago
  That's not really true. Java linking happens very late, and so invoking methods at polymorphic call sites does have more in common with 'dynamic' languages than you might think. Hotspot has smalltalk roots, and features like inline caching at call sites together with optimistic fast paths, guards, deoptimisation, and other things that would be familiar from, say, a ruby implementation.
  - gsnedders 12y ago
    Yes — HotSpot does much of this, but the inability until recently to encode "call this function which expects some number of arguments" in the instruction set has historically been the limiting factor. invokedynamic helps a lot, but it adds enough levels of indirection that AIUI often enough isn't inlined for it to really solve everything. I wonder if a tracing JVM would handle it better? Probably.
jrochkind1 12y ago
Doesn't ObjC do similar method dispatch? If so, is it considered a slow language also?
- pjmlp 12y ago
  Yes. It is quite common to cache methods (selectors) or just re-write them in the C subset, when optimizing code.

orionblastar 12y ago

I used to program in Visual BASIC 6.0 which was considered slow at the time. It is just a matter of using the proper algorithms to speed it up. Almost any programming language targeted at beginners or newbies is going to be considered slow because beginners and newbies don't know the proper algorithms and code tweeks to speed things up yet. When you deal with sloppy inefficient code, almost any language is going to be considered slow. I remember trying to make a paint program with Turbo Pascal 3.0 back in the DOS days, it was slow until I learned better algorithms in drawing things and how to write directly to video memory instead of using built in commands like plot.

perishabledave 12y ago
I don't think Ruby is targeted at beginners or newbies if thats what you're implying. The language seems simple at first, but once you start delving into the features that make it a dynamic language it is quite deep.
- Rapzid 12y ago
  This stuff is always fun : https://github.com/opscode/chef/blob/master/lib/chef/node/immutable_collections.rb#L79-L85 https://github.com/opscode/chef/blob/master/lib/chef/node/im... .