[MacRuby-devel] branches/experimental

Laurent Sansonetti lsansonetti at apple.com
Sat Mar 28 22:09:58 PDT 2009


Hi Charles,

On Mar 28, 2009, at 9:46 PM, Charles Oliver Nutter wrote:

> Laurent Sansonetti wrote:
>> Hi guys,
>> As some of you already noticed we have been working on a branch for  
>> a few weeks and I thought it's now time to describe what has been  
>> done and were we are going exactly.
>
> Very cool stuff...some low-level benchmarks seem to have really  
> excellent performance.

Thank you :)

> I know you probably don't need bugs filed against 'experimental'  
> yet, but I had a couple questions:
>
> 1. Is there a way to tell what's compiling and what isn't? Some  
> benchmarks I run are fast, and some others are incredibly slow. I'd  
> like to know what's representative of actual performance.

Currently everything is compiled. It is possible to dump the LLVM IR  
by turning on the ROXOR_DUMP_IR variable in roxor.cpp. Generally when  
something is incredibly slow it's because of a runtime bug and not the  
compiler, though.

> 2. Is there a way to turn off peephole optimizations? Lots of  
> benchmarks out there, including some we have in JRuby, have a lot of  
> dead code (like repeated assignments to a local variable). That's  
> going to confound a lot of benchmarking, since most of the benchmark  
> isn't actually being run. JRuby has a flag to turn off peephole optz  
> (though I often forget to turn it on).

It's possible by modifying the source code and comment the call to  
createInstructionCombiningPass() and createCFGSimplificationPass(),  
but I do not recommend to remove these because I think it would break  
the way we compile Dwarf exception handlers in blocks.

# In my personal benchmark suite I try to make sure these  
optimizations do not provide false positive numbers when comparing  
against YARV.

> 3. You probably know about these, but I noticed there are numerous  
> problems with eval:
>
> * Running an eval benchmark caused the system to blow up, claiming  
> it ran out of space for machine code

Yes, currently calling eval with a literal string will call the JIT,  
so doing this in a loop will most likely eat all your memory :-)

I plan to address that later by fallbacking to the LLVM interpreter in  
some cases, but I doubt this will affect real-world applications.  
Also, there are ways to improve the JIT (nothing has been done yet).

> * bindings appear to be missing altogether
> * The binding associated with a block does not appear to work, as in  
> p = proc { }; eval 'something', p.binding. This troublesome feature  
> is one reason many local variable optimizations are much more  
> difficult.

Yes as you noticed Binding has not been implemented yet :-( This is on  
the very top of my TODO list (needed for IRB) and I already know how  
to implement it without disabling our current "local variables into  
CPU registers" optimization.

> I'm looking forward to seeing future results and getting some  
> guidance on where we can expect to see the best performance right  
> now. I'd also love to talk about some techniques you're using to see  
> if they'd be applicable for JRuby.

Absolutely :-)

Laurent


More information about the MacRuby-devel mailing list