[#81492] [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid — normalperson@...
Issue #13618 has been reported by normalperson (Eric Wong).
12 messages
2017/06/01
[#88695] Re: [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid
— Eric Wong <normalperson@...>
2018/08/27
> https://bugs.ruby-lang.org/issues/13618
[#81569] [Ruby trunk Feature#12589] VM performance improvement proposal — vmakarov@...
Issue #12589 has been updated by vmakarov (Vladimir Makarov).
3 messages
2017/06/04
[#81581] [Ruby trunk Bug#13632] Not processable interrupt queue for a thread after it's notified that FD is closed in some other thread. — sir.nickolas@...
Issue #13632 has been reported by nvashchenko (Nikolay Vashchenko).
4 messages
2017/06/05
[#81590] Re: [ruby-cvs:66197] ko1:r59023 (trunk): revert r59020 because it may fail some tests sometimes on some environment (http://ci.rvm.jp/). This revert is to check the reason of failures. — Eric Wong <normalperson@...>
ko1@ruby-lang.org wrote:
5 messages
2017/06/06
[#81591] Re: [ruby-cvs:66197] ko1:r59023 (trunk): revert r59020 because it may fail some tests sometimes on some environment (http://ci.rvm.jp/). This revert is to check the reason of failures.
— Eric Wong <normalperson@...>
2017/06/06
Eric Wong <normalperson@yhbt.net> wrote:
[#81596] Re: [ruby-cvs:66203] Re: Re: ko1:r59023 (trunk): revert r59020 because it may fail some tests sometimes on some environment (http://ci.rvm.jp/). This revert is to check the reason of failures.
— Eric Wong <normalperson@...>
2017/06/06
Eric Wong <normalperson@yhbt.net> wrote:
[#81825] [Ruby trunk Feature#13697] [PATCH]: futex based thread primitives — normalperson@...
Issue #13697 has been reported by normalperson (Eric Wong).
3 messages
2017/06/29
[ruby-core:81844] [Ruby trunk Feature#13434] better method definition in C API
From:
ko1@...
Date:
2017-06-30 06:05:21 UTC
List:
ruby-core #81844
Issue #13434 has been updated by ko1 (Koichi Sasada).
As I wrote before, I against this idea. My idea is to write definitions in Ruby with special form.
Comparison:
* Write info with C
* Easy to learn (people should know only C syntax)
* Easy to implement
* Write info with Ruby w/ special firm
* Easy to write
* Easy to read
* Easy to learn (people should know Ruby syntax and some restrictions) (I agree it is possible that "some restrictions" will confuse people.)
* We can compile it and know all of information before running Ruby (*1)
I'll explain more about (*1).
Now we can't know all of methods defined in C level before running Ruby interpreter. So MRI needs to process all of method definitions.
```
rb_define_method(...); // allocate table entry and insert it
rb_define_method(...); // allocate table entry and insert it
rb_define_method(...); // allocate table entry and insert it...
...
```
If we know the all sets of methods, we pre-allocate table.
```
table_allocate(3)
rb_define_method(...); // insert it
rb_define_method(...); // insert it
rb_define_method(...); // insert it...
```
Moreover, we can prepare tables.
```
struct method_entries table = [] = {
"foo", foo_func, ...,
"bar", bar_func, ...,
"baz", baz_func, ...,
}
//
rb_define_methods_with_table(cString, table); // convert C array to MRI method table
````
Furthermore, we can defer converting until first method call.
```
struct method_entries table = [] = {
"foo", foo_func, ...,
"bar", bar_func, ...,
"baz", baz_func, ...,
}
Init_String{
...
rb_define_methods_with_table(rb_cString, table); // register table to rb_cString
...
}
//
# ruby
p "xyzzy".upcase # the first time we convert registerred table to MRI method table
```
I'm suspect that most of classes are not used (think about many of Exception class) so that this kind of optimization will improve speed (reduce boot time) and memory efficiency.
----------------------------------------
Feature #13434: better method definition in C API
https://bugs.ruby-lang.org/issues/13434#change-65562
* Author: normalperson (Eric Wong)
* Status: Open
* Priority: Normal
* Assignee:
* Target version:
----------------------------------------
Current ways to define and parse arguments in the Ruby C API are clumsy,
slow, and impede potential optimizations.
The current C API for defining (rb_define_{singleton_}, method),
and parsing (rb_scan_args, rb_get_kwargs) is orthogonal but inefficient.
rb_get_kwargs creates garbage which pure Ruby kwarg methods do not.
[Feature #11339] was an ugly workaround to use Ruby wrapper methods
for IO#*nonblock methods to avoid garbage from rb_get_kwargs.
Furthermore, it should be possible to annotate args for C functions as
"read-only, use-once" or similar. In other words, it should be possible to
implement my idea from [ruby-core:80626] where method lookup can be done
out-of-order in some cases, and allow optimizations such as replacing
"putstring" insns with garbage-free "putobject" insns for constants strings
without introducing backwards incompatibility for Rubyists.
We can also get rid of the limited basic op redefinition checks and
implement more generic versions of opt_aref_with / opt_aset_with
for more functions that can take frozen string args.
The "read-only, use-once" annotation can even make it safe for
a dynamic strings to be immediately recycled to reduce garbage.
So we could annotate "puts" and IO#write in a way that causes the VM to
immediately recycle its argument if it's a dynamically-generated string:
puts "#{dynamic} #{string(:here)}"
I am not good at API design; so I'm not sure what it should look like.
Perhaps sendmsg_nonblock may be implemented like:
```
struct rb_method_info {
/* to be filled in by rb_def_method ... */
};
static VALUE
sendmsg_nonblock(struct rb_method_info *info, int argc, VALUE *argv, VALUE self)
{
VALUE mesg, flags, dest_sockaddr, control, exception;
rb_get_args(info, argc, argv,
&mesg, &flags, &dest_sockaddr, &control, &exception);
...
}
/*
* ALLCAPS variable names mean read-only (like "constants" in Ruby)
* "1" prefix means use only once, eligible for immediately recycle
* if dynamic string
*/
rb_def_method(rb_cBasickSocket, sendmsg_nonblock,
"sendmsg_nonblock(1MESG "
"1FLAGS = 0), "
"1DEST_SOCKADDR = nil), "
"*1CONTROL, exception: true)", -1);
/* rb_hash_aset can be done as:
* where 0KEY (not "1" prefix) means it is constant and persistent,
* and "val" (all lower case, no prefix) means it is a normal
* variable which can persistent after the function returns
*/
rb_def_method(rb_Hash, rb_hash_aset, "[0KEY]=val", 2);
```
Thoughts?
The existing C API must continue to work, so 3rd-party extensions can
migrate to the new API slowly.
--
https://bugs.ruby-lang.org/
Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>