[MacRuby-devel] Running the experimental branch

[Laurent Sansonetti]

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