Forum: Ruby Ruby2CExtension 0.2.0 -- Now with optimizations

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Dominik B. (Guest)
on 2007-06-14 16:23
(Received via mailing list)
I am happy to announce the release of Ruby2CExtension 0.2.0.

Ruby2CExtension is a Ruby to C extension translator/compiler. It takes
any Ruby source file, parses it using Ruby's builtin parser and then
translates the abstract syntax tree into "equivalent" C extension code.

More information at http://ruby2cext.rubyforge.org/.


Ruby2CExtension is available as gem now, so installation is as simple
as:

   gem install ruby2cext

(There is also a setup.rb-release available.)


Ruby2CExtension 0.2.0 supports Ruby 1.8.4 to 1.8.6 (including the
patchlevel releases).

The two major new features are Eval2C and the new optimizations.


Eval2C allows transparent compilation of Ruby code at runtime. This
allows to compile (and speedup) code that is generated at runtime. It
also makes it possible to compile only selected parts of Ruby files.
This
feature is similar to RubyInline, but works with Ruby code instead of C
code.

More information at http://ruby2cext.rubyforge.org/eval2c.html.


The new optional optimizations can provide speedups for Ruby code by
sacrificing some compatibility. In particular the optimization of calls
to (C-implemented) methods of built-in classes can significantly speedup
Ruby code.

Example:

   max = 2000
   z = x = 0
   while (x+=1) <= max
     y = 0
     while (y+=1) <= max
       z = (x+y-z) % 32000
     end
   end
   puts z

The compiled version (with all optimizations turned on) of this program
is about seven times faster than the uncompiled version. This is an
extreme example, because almost all method calls are optimized, but it
shows what is possible.

More information at http://ruby2cext.rubyforge.org/optimizations.html.


Changelog:

* New features:
   * New plugin architecture for optimizations and other things
   * Optimization plugins: const_cache, builtin_methods, inline_methods,
     case_optimize
   * Other plugins: require_include, warnings
   * Eval2C for compilation at runtime
   * Available as gem now

* Improvements:
   * Implemented control flow "through" rescue/ensure clauses
   * Better vmode handling
   * Support for Ruby 1.8.5 and 1.8.6
   * Improved performance for global variables

* Fixes:
   * Workaround for an issue with ALLOCA_N in while loops
   * Fixed a problem with case/when (missing newline nodes)
   * Removed libraries from compile command
   * Various other small fixes
Eric M. (Guest)
on 2007-06-14 17:32
(Received via mailing list)
On 6/14/07, Dominik B. <removed_email_address@domain.invalid> wrote:
> I am happy to announce the release of Ruby2CExtension 0.2.0.
...
> The two major new features are Eval2C and the new optimizations.

Thanks Dominik!

I'd like to point out that Dominik's Ruby2CExtension is generates C
code that does the same as the original ruby code 99% of the time.  As
long as your code isn't doing things too crazy (like overriding the
built-in class methods), it should work.  The way I see it, the next
step could be a full-fledged ruby compiler.

I've used this with my grammar package (which I need to re-release) to
generate parsers that were 4-6 times faster.  To get the best
optimizations though, I had to generate the ruby code a certain way.
I use the Eval2C as an eval replacement on the generated lexer/parser.

Dominik, have you done any profiling (with gprof or something else) to
see where the majority of remaining time is being spent on a fully
compiled piece of code?  I think the major components would be:
Ruby2CExtension code, other C implemented methods (i.e. built-in), and
method lookup/calling code.  I'd expect the majority of time to
typically be in the method lookup/calling code.  If so, you may want
to ask Matz/ruby-core/ruby-dev to provide some way to just lookup a
method so that the calling overhead using this info would be minimal.
This would be useful where you detect a that an object calls a method
multiple times.  Better yet, it could be applied to a variable and
re-lookup the method only when the class changes.  Like many other
optimizations, this would sacrifice some compatibility - can't change
a method (including in a meta-class) after you start using it.

Thanks again for the great package!

Eric
This topic is locked and can not be replied to.