On Apr 4, 2009, at 5:18 PM, Vincent Isambart wrote:
In the comments of Charlie's latest blog post, someone showed their benchmarks of the 0.5 branch running tak(). http://blog.headius.com/2009/04/how-jruby-makes-ruby-fast.html#comments I'd like to do the same but rake isn't giving me a macruby executable. How do I go beyond miniruby and get a ruby capable of running Charlie's bench_tak.rb?
You can't get a macruby executable with the current experimental branch. And anyway you can run the tak benchmark with only miniruby (./miniruby -I./lib bench_tak.rb 5)
But anyway it seems no one seems to see the only interesting point of Charles' posts: mini benchmarks are not a good indicator of the speed of an implementation. I've never seen any real-life Ruby code that does heavy computations and recursion like tak or fibonacci... Such mini-benchmarks are mainly a tool for the implementers themselves to see if some code modification did something good in an area, but they generally do not mirror real speed...
While I agree that micro-benchmarks do not represent the reality, generally they are written to cover a real-world scenario where the testing implementation suffers. Now, some micro-benchmarks written against implementation X might sometimes be meaningless in implementation Y. For instance, the optimizations that are (and will be) implemented in the experimental branch are not random but were selected after having profiled a big MacRuby/Cocoa application and found many areas where we performed badly. I assume that other implementations are using similar techniques.
And for real speed the new MacRuby VM is still young - it does not even run IRB yet anyway (well I would not be surprised if it does next week) - and lots of optimization are still to be done. Fixnum computations however is already well optimized and is probably not an area where you're going to see many changes in speed.
I think we can improve fixnum arithmetic a little bit (I would estimate 5-10%) once we enable secondary compilations, but this isn't clearly a top priority at this point. Laurent