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
_______________________________________________
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
