vmakarov / redhat.com wrote:
>     **stack-based** insns to **register transfer** ones.  The idea behind
>     it is to decrease VM dispatch overhead as approximately 2 times
>     less RTL insns are necessary than stack based insns for the same
>     program (for Ruby it is probably even less as a typical Ruby program
>     contains a lot of method calls and the arguments are passed through
>     the stack).
> 
>     But *decreasing memory traffic* is even more important advantage
>     of RTL insns as an RTL insn can address temporaries (stack) and
>     local variables in any combination.  So there is no necessity to
>     put an insn result on the stack and then move it to a local
>     variable or put variable value on the stack and then use it as an
>     insn operand.  Insns doing more also provide a bigger scope for C
>     compiler optimizations.

One optimization I'd like to add while remaining 100% compatible
with existing code is to add a way to annotate read-only args for
methods (at least those defined in C-API).  That will allow
delaying putstring instructions and giving them the same effect
as putobject.

This would require having visibility into the resolved method
at runtime; before putting its args on the stack.

One trivial example would be the following, where
String#start_with? has been annotated(*) with the args being
read-only:

	foo.start_with?("/")

Instead of resolving the 'putstring "/"', first;
the method "start_with?" is resolved.

If start_with? is String#start_with? with a constant
annotation(*) for the arg(s); the 'putstring "/"'
instruction returns the string w/o resurrecting it
to avoid the allocation.

This would be a more generic way of doing things like
opt_aref_with/opt_aset_with; but without adding more global
redefinition flags.


(*)  Defining a method may change from:

    rb_define_method(rb_cString, "start_with?", rb_str_start_with, -1);

To something like:

    rb_define_method2(rb_cString, "start_with?", rb_str_start_with,
			"RO(*prefixes)");

But rb_define_method should continue to work as-is for old code;
but having a new rb_define_method2 would also allow us to fix
current inefficiencies in rb_scan_args and rb_get_kwargs.

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>