From: ptkwt@...1.aracnet.com (Phil Tomson) Date: 2002-02-15T03:39:19+09:00 Subject: Re: Ruby performance on the Language Shootout In article , Christian Boos wrote: >Hello, > >> -----Original Message----- >> From: Mike Hall [mailto:mghall@enteract.com] >> Sent: Wednesday, February 13, 2002 8:35 PM >> To: ruby-talk ML; undisclosed-recipients: >> Subject: Re: Ruby performance on the Language Shootout >.. >> Also, there's a semi-shoot-out going on over in the Tcl newsgroup. >> Actually, they're seeing how Tcl fares in a Python-Java shootout. >> >> > Jean-Luc Fontaine wrote: >> > > Look at: >> > > http://www.twistedmatrix.com/users/glyph/rant/python-vs-java.html >> > > Maybe we could try those with Tcl? >> >> Perhaps some seasoned and adventurous Rubyists could see how Ruby >> compares? >> > >I don't know if I qualify as a seasoned Rubyist, but given the simplicity >of the code involved in this comparison, I took the chance to write the >ruby version plus a 'gbench.rb' script that performs the benchmarks >in a flexible way, so that one can add scripts or languages easily. Good work! > >Some notes about the test runner: > - benchmarks are given on the command line using the test's name > (i.e. "gbench.rb speed list object"); if none are given, > all those found in the current directory are used > > - To make echo to another thread, I've used the 'respond_to?' in > a way that I found quite appropriate. > So for those who wanted an example... > > - I used some Unixisms (" > /dev/null", 'Open3.popen3'), so the > script is not portable on Windows (ruby-cygwin *might* work) > > - well, enough said about this little benchmark, back to work :) > However, as you can already see on the original page linked > in the quote, this benchmark is quite sparse, and there could > be many more things tested in this way: regexp, maths, > networking, exception, eval, introspection, etc. > > >Download it on my Ruby page: > > http://www.bct-portal.com/opensource/ruby/gbench.tgz > > >Some notes about the results I've found: > > Ok, folks, do you really think it's worth putting a lot of > work in getting a byte compiler for Ruby? > I would say that the current model is quite smart and efficient. If it were a byte compiler with JIT it would probably have some speed advantages. However, as you point out, we're doing pretty well without a bytecompiler right now - a crazy thought: In a byte code VM with JIT some bytecode is converted to native code on the fly. I don't know all the details, but I suspect this is probably done a lot in loops (code that's going to be run again) otherwise it could be a waste to take the time to convert some sections of bytecode to native code (just speculating). Now for the crazy part: can a tree-walking interpreter (like Ruby's current one) be modified to be a tree walker with JIT? In other words, some parts of the tree (things done in loops) would be converted to native code.... Has anything like that been done? The impression I get is that JIT compilation is harder to do for a dynamic language than it is for a static one... > > - Python2 seems a little faster than Python1.5 (except for I/O). > Using '-O' (basic optimizations) consistently gives you faster > results. > Good! > > - Ruby 1.6.5 competes nicely with them: only slower for ONE test! > (test_hash). Should there be some enhancements for this one? > It is significantly faster than Python for I/O, and has > a very fast startup. > I would like to see the results for Ruby 1.7! > The results for this suite of tests seem to be different than the results for the computer language shootout's suite where Ruby was mostly slower than Python. Thanks for putting this together. Phil