[#80531] Re: [ruby-cvs:65407] normal:r58236 (trunk): thread.c: comments on M:N threading [ci skip] — Eric Wong <normalperson@...>
SASADA Koichi <ko1@ruby-lang.org> wrote:
On 2017/04/02 11:35, Eric Wong wrote:
SASADA Koichi <ko1@atdot.net> wrote:
Eric Wong <normalperson@yhbt.net> wrote:
On 2017/05/08 9:33, Eric Wong wrote:
On 2017/05/08 10:53, SASADA Koichi wrote:
SASADA Koichi <ko1@atdot.net> wrote:
On 2017/05/08 12:01, Eric Wong wrote:
SASADA Koichi <ko1@atdot.net> wrote:
On 2017/05/08 15:36, Eric Wong wrote:
SASADA Koichi <ko1@atdot.net> wrote:
On 2017/05/09 12:38, Eric Wong wrote:
SASADA Koichi <ko1@atdot.net> wrote:
On 2017/05/09 14:12, Eric Wong wrote:
SASADA Koichi <ko1@atdot.net> wrote:
On 2017/05/09 15:23, Eric Wong wrote:
SASADA Koichi <ko1@atdot.net> wrote:
Thank you.
[#80763] [Ruby trunk Feature#13434] better method definition in C API — naruse@...
Issue #13434 has been updated by naruse (Yui NARUSE).
[#80844] [Ruby trunk Bug#13503] Improve performance of some Time & Rational methods — watson1978@...
Issue #13503 has been updated by watson1978 (Shizuo Fujita).
[#80892] [Ruby trunk Misc#13514] [PATCH] thread_pthread.c (native_sleep): preserve old unblock function — ko1@...
Issue #13514 has been updated by ko1 (Koichi Sasada).
ko1@atdot.net wrote:
On 2017/04/27 8:58, Eric Wong wrote:
SASADA Koichi <ko1@atdot.net> wrote:
Eric Wong <normalperson@yhbt.net> wrote:
[ruby-core:80626] Re: [Ruby trunk Feature#12589] VM performance improvement proposal
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>