From: SASADA Koichi <ko1@atdot.net>
To: ruby-core@ruby-lang.org
Subject: [ruby-core:69990] Re: [Ruby trunk - Feature #11339] [Open] [PATCH] io.c: avoid kwarg parsing in C API
Date: Thu, 16 Jul 2015 12:46:56 +0900 [thread overview]
Message-ID: <55A72930.40305@atdot.net> (raw)
In-Reply-To: <20150715194153.GA13673@dcvr.yhbt.net>
On 2015/07/16 4:41, Eric Wong wrote:
> normalperson@yhbt.net wrote:
>> Feature #11339: [PATCH] io.c: avoid kwarg parsing in C API
>> https://bugs.ruby-lang.org/issues/11339
>
>> Note: I plan to followup commits for other *_nonblock methods
>> Eventually, I even wish to deprecate rb_scan_args :D
>>
>> For what it's worth, I'm more excited about this change than usual
>> and hope to use prelude.rb more.
>
> ko1/nobu/akr/others: any comments on this?
>
> My main concern is increased parse time from prelude during startup;
> but we may translate prelude to iseq array and use rb_iseq_load, too.
> The parser seems to be the worst offender for startup performance
> nowadays.
We have some ideas to solve this issue. We discussed about solutions.
Known problems about C-methods parameters:
(P1) slow to parse kwargs with Hash
(P2) difficult to write scan_args
(P3) C-methods can't support Method#parameters
Solutions:
(1) Introduce wrapping Ruby methods into prelude.rb (your idea)
Pros. Easy to introduce.
Solves (P1-3).
Cons. Increase parse time at Ruby launch.
(2) Introduce new API to declare Ruby-like parameters for C-APIs
like: rb_define_method(klass, "xyzzy", klass_xyzzy, -1)
(2-1)
-> rb_defnie_method_??(klass, "xyzzy", klass_xyzzy,
"(m1, m2, o1=nil, o2=nil,
*r, p1, p2, k1: 1, k2: 2)")
VALUE klass_xyzzy(VALUE self, VALUE m1, VALUE m2, VALUE o1, VALUE o2,
VALUE r, VALUE p1, VALUE p2, VALUE k1, VALUE k2)
or
(2-2)
-> rb_defnie_method_??(klass, "xyzzy", klass_xyzzy,
2 /* mandatory num */,
2 /* optional num */,
1 /* rest num */,
2 /* post num */,
2 /* kw num */,
"m1", "m2",
"o1", Qnil, "o2", Qnil,
"r", "p1", "p2",
"k1", Qnil, "k2", Qnil);
(2-3)
-> something = rb_define_method(klass, "xyzzy", klass_xyzzy, 9);
rb_define_method_argument(something, ...);
(or something like that)
Implementation: Make new rb_iseq only to call C func (klass_xyzzy, in
this case). We have also need several issues.
Pros. Easy to specify parameters.
Solves (P1-3).
Cons. Difficult to design API (it should be compatible in future).
(2-1) introduces parse time at definition.
(3) Introduce new IDL (Interface Definition Language)
-----
# File klass.??
class Klass
def xyzzy(m1, m2, o1=nil, o2=nil, *r, p1, p2, k1: 1, k2: 2)
# This decl. calls C func klass_xyzzy with parameters m1 to k2.
# We can't write any code here.
end
end
-----
Translate klass.?? to something like (2).
We don't touch such APIs. No compatibility issues.
Pros. We don't need to design cool API.
Solves (P1-P3).
Cons. Need to design new langauge (IDL).
(4) Introduce new IDL like Ricsin
I made a system calls Ricsin, which enable to embed C code into Ruby code.
http://www.atdot.net/~ko1/activities/ricsin2009_pro.pdf
(sorry, written in Japanese)
----
# File klass.??
class Klass
def xyzzy(m1, m2, o1=nil, o2=nil, *r, p1, p2, k1: 1, k2: 2)
# you can write any Ruby code here.
__C__ %Q{
/* Given string argument for __C__ is C code. */
klass_xyzzy(RV(m1), RV(m2), RV(o1), RV(o2),
RV(r), RV(p1), RV(p2), RV(k1), RV(k2));
}
end
end
----
Compile this file into something C-extension.
Pros. Easy to write Extensions.
Easy (and efficient) to write exception handling code
without rb_protect(). rb_iterate() is same.
(callback is difficult for C)
Solves (P1-P3).
Cons. Allowing everything can make other issues.
--------
Matz likes the middle of (3) and (4) (not allow everything, but allow
restricted). I like (4).
--------
I'm okay to introduce (1) because it is easy and practical.
If we can make (2)-(4), then we can replace from (1) to new mechanism.
BTW, I'm working on making AOT compilation support (it will be continued
to (3) or (4)). Recent rb_iseq_t changes were for this purpose. So that
prelude.rb is nice benchmark for me.
Thanks,
Koichi
--
// SASADA Koichi at atdot dot net
next prev parent reply other threads:[~2015-07-16 3:18 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <redmine.issue-11339.20150707215946@ruby-lang.org>
2015-07-07 21:59 ` [ruby-core:69892] [Ruby trunk - Feature #11339] [Open] [PATCH] io.c: avoid kwarg parsing in C API normalperson
2015-07-15 19:41 ` [ruby-core:69983] " Eric Wong
2015-07-16 3:46 ` SASADA Koichi [this message]
2015-07-16 7:01 ` [ruby-core:69995] " Eric Wong
2015-07-16 9:17 ` [ruby-core:69999] " SASADA Koichi
2015-10-09 23:35 ` [ruby-core:71035] " Eric Wong
2015-11-10 22:27 ` [ruby-core:71435] " Eric Wong
2015-12-02 2:23 ` [ruby-core:71789] " Eric Wong
2015-11-11 5:20 ` [ruby-core:71439] [Ruby trunk - Feature #11339] " matz
2015-11-12 2:03 ` [ruby-core:71459] " Eric Wong
2015-11-12 9:53 ` [ruby-core:71462] " Eric Wong
2015-11-18 2:07 ` [ruby-core:71539] " Eric Wong
2015-11-13 4:18 ` [ruby-core:71473] " Eric Wong
2015-11-13 5:46 ` [ruby-core:71478] " SASADA Koichi
2015-11-13 7:03 ` [ruby-core:71479] " Eric Wong
2015-12-27 22:49 ` [ruby-core:72527] " headius
2015-12-27 23:00 ` [ruby-core:72528] " headius
2015-12-27 23:40 ` [ruby-core:72529] " Eric Wong
2015-12-28 0:13 ` [ruby-core:72530] " headius
2015-12-28 1:12 ` [ruby-core:72532] " Eric Wong
2015-12-28 0:22 ` [ruby-core:72531] " headius
2015-12-28 1:50 ` [ruby-core:72535] " headius
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.ruby-lang.org/en/community/mailing-lists/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55A72930.40305@atdot.net \
--to=ruby-core@ruby-lang.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).