From: Jan Wedekind <jan@...>
Date: 2008-12-06T06:54:54+09:00
Subject: [ruby-core:20394] Re: Achieving C-like performance with more indirection?

>> ... does not really address the problem since this approach leads to
>> an endless tower of reflective interpreters ...
>
> It depends on what you mean by "the problem".  If the problem is that
> you want improved performance, compiling by walking the AST is
> satisfactory.  This is what Ludicrous does (or in the case of YARV, by
> iterating over the YARV bytecode instead).
    I mean that I want to be able to write Ruby code for manipulating 
videos and I want to be able to translate it to machine code without
having to restrict myself to a subset of Ruby (i.e. I want to integrate
libJIT in a transparent way).
    By the way, your projects Ludicrous, Framed, and Ruby-Libjit are really 
interesting and the (partial) libJIT interface of HornetsEye closely
follows the pattern of Ruby-Libjit.

>>   f.until( proc { p == pend } ) do
>>     ...
>>   end
>
> IMO the syntax ruby-libjit uses for until is slightly less verbose:
>
>  f.until { p == pend }. do
>    ...
>  end
Yes, I saw that you implemented if-then-else in a similar fashion.

> BTW, does your jit_store method know to use insn_store_relative instead
> of insn_store?
    Yes. It is an optional parameter and I use it for storing composite
numbers (complex-numbers, RGB tripples, ...). The Ruby methods using
the libJIT interface currently can all be found in the file
$topdir/hornetseye/hornetseye_ext.rb of the source repository [1].

> Yes, it's been discussed before:
>
> [ruby-talk:38802]
> [ruby-talk:168164]
That's interesting. Of course it is possible to manually translate a
Ruby program into a program which avoids static control statements.

> ...
> or the while keyword were syntactic sugar for a while_true method:
>
>  while <condition> do <body> end
>  #=>
>  proc { <condition> }.while_true { <body> }
>
> It would be possible using RedParse or Ripper to perform this
> transformation before code is executed; code in the resulting new
> language could then easily run alongside existing Ruby code.
    Maybe I will try that next year if I find the time just to see how
far one can get with this. However I guess it may be difficult to
extend this to Ruby core libraries.
    I think this is not only about syntactic sugar. If I am not mistaken,
one could for example convert an existing Ruby method into a parse
tree simply by running it within a modified context. I.e. one could
write a Ruby-extension which acts as a generic optimizer.
    For the moment I am thinking about writing a set of Ruby classes
which map to machine code in an efficient way:

x = 0.to_lint
for i in UBYTE(0)...UBYTE(255)
   x = x + i
end

[1] http://bazaar.launchpad.net/~wedesoft/hornetseye/trunk/files