From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: poffice@blade.nagaokaut.ac.jp Delivered-To: poffice@blade.nagaokaut.ac.jp Received: from kankan.nagaokaut.ac.jp (kankan.nagaokaut.ac.jp [133.44.2.24]) by blade.nagaokaut.ac.jp (Postfix) with ESMTP id C00491960251 for ; Thu, 16 Jul 2015 12:18:20 +0900 (JST) Received: from funfun.nagaokaut.ac.jp (funfun.nagaokaut.ac.jp [133.44.2.201]) by kankan.nagaokaut.ac.jp (Postfix) with ESMTP id 11C40B5D8CF for ; Thu, 16 Jul 2015 12:47:03 +0900 (JST) Received: from funfun.nagaokaut.ac.jp (localhost.nagaokaut.ac.jp [127.0.0.1]) by funfun.nagaokaut.ac.jp (Postfix) with ESMTP id 7841B97A832 for ; Thu, 16 Jul 2015 12:47:04 +0900 (JST) X-Virus-Scanned: amavisd-new at nagaokaut.ac.jp Received: from funfun.nagaokaut.ac.jp ([127.0.0.1]) by funfun.nagaokaut.ac.jp (funfun.nagaokaut.ac.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AznMCapdO4_o for ; Thu, 16 Jul 2015 12:47:04 +0900 (JST) Received: from voscc.nagaokaut.ac.jp (voscc.nagaokaut.ac.jp [133.44.1.100]) by funfun.nagaokaut.ac.jp (Postfix) with ESMTP id 578BD97A826 for ; Thu, 16 Jul 2015 12:47:04 +0900 (JST) Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by voscc.nagaokaut.ac.jp (Postfix) with ESMTP id CC4DC95243A for ; Thu, 16 Jul 2015 12:47:02 +0900 (JST) Received: from [221.186.184.76] (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id B32EE12047C; Thu, 16 Jul 2015 12:47:00 +0900 (JST) X-Original-To: ruby-core@ruby-lang.org Delivered-To: ruby-core@ruby-lang.org Received: from sakura2.atdot.net (www4150ue.sakura.ne.jp [219.94.244.164]) by neon.ruby-lang.org (Postfix) with ESMTP id A8D3E120433 for ; Thu, 16 Jul 2015 12:46:57 +0900 (JST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by sakura2.atdot.net (Postfix) with ESMTP id 5759B1181BC; Thu, 16 Jul 2015 12:46:57 +0900 (JST) Message-ID: <55A72930.40305@atdot.net> Date: Thu, 16 Jul 2015 12:46:56 +0900 From: SASADA Koichi User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: ruby-core@ruby-lang.org References: <20150715194153.GA13673@dcvr.yhbt.net> In-Reply-To: <20150715194153.GA13673@dcvr.yhbt.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ML-Name: ruby-core X-Mail-Count: 69990 Subject: [ruby-core:69990] Re: [Ruby trunk - Feature #11339] [Open] [PATCH] io.c: avoid kwarg parsing in C API X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" 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