Misc #17502: C vs Ruby

• Status: Assigned
• Assignee: ko1 (Koichi Sasada)

[marcandre (Marc-Andre Lafortune)]

Some features are coded in a mix of Ruby and C (e.g. ractor.rb).

External gems don't have access to this. The C-API to deal with keyword parameters is also very verbose the parsing and the engine does not know it.

Moreover, some optimization PRs are simply rewriting C-code into Ruby using pseudo C code.

I understand the intentions are great, but changes like https://github.com/ruby/ruby/pull/4018/files seem a symptom that something needs to be improved with the C api.

-static VALUE
- flo_zero_p(VALUE num)
- {
-     return flo_iszero(num) ? Qtrue : Qfalse;
- }
# in different file:
+ def zero?
+   Primitive.attr! 'inline'
+   Primitive.cexpr! 'flo_iszero(self) ? Qtrue : Qfalse'
+ end

It seems to me that this is a way to circumvent a deeper issue. Is this the right direction?

Is there a plan for an API that would:

1. be accessible to C extensions
2. can't be re-written any faster in pseuso-C in Ruby
3. has an easy way to define keyword parameters?

I realize that RBS may give perfect signatures, but ideally parameters would be more informative for C-functions too.

Ractor.method(:yield).parameters
# => [[:req, :obj], [:key, :move]] # good!
Fiber.method(:initialize).parameters
# => [[:rest]] # not good, should be [[:key, :blocking]]

[k0kubun (Takashi Kokubun)]

• Related to Feature #16254: MRI internal: Define built-in classes in Ruby with `__intrinsic__` syntax added

[k0kubun (Takashi Kokubun)]

• Assignee set to ko1 (Koichi Sasada)

First off, you may be interested in reading [Feature #16254] in case you haven't. (Note: __intrinsitc__ was renamed to __builtin_ first, and then renamed again to Primitive.)

Let me separately discuss multiple independent topics you raised in this single ticket:

Support Primitive. for gems and C extensions

External gems don't have access to this.

Is there a plan for an API that would:

1. be accessible to C extensions

Apparently the current implementation was not designed for this, but only @ko1 (Koichi Sasada) can answer about his future plan.

Using Primitive. to optimize keyword parameters of C API

The C-API to deal with keyword parameters is also very verbose the parsing and the engine does not know it.

Is there a plan for an API that would:
3) has an easy way to define keyword parameters?

I realize that RBS may give perfect signatures, but ideally parameters would be more informative for C-functions too.

Could you talk about keyword parameters in a different ticket, either in [Feature #16254] (because using Primitive. to optimize keyword parameters of C methods was a part of its design) or another new Misc ticket? At least the PR you quoted wasn't using keyword arguments, and the purpose is fairly independent from the thing described below.

Annotating C methods

Moreover, some optimization PRs are simply rewriting C-code into Ruby using pseudo C code.

I understand the intentions are great, but changes like https://github.com/ruby/ruby/pull/4018/files seem a symptom that something needs to be improved with the C api.
It seems to me that this is a way to circumvent a deeper issue. Is this the right direction?

2. can't be re-written any faster in pseuso-C in Ruby

My purpose of merging the PR was to annotate such C functions as they're safe to be inlined by JIT, using Primitive.attr! 'inline'. Even while the purpose is to optimize JIT, we should maintain VM's performance when we optimize JIT, and therefore we confirm VM performance is not degraded by benchmarking VM. Because it's very important that annotating a method doesn't make the method slower, the current situation where presudo-C in Ruby very slightly improves performance is somewhat helpful for adding annotations without thinking about its VM impact too much, although it shouldn't be the purpose of using pseudo-C in Ruby.

To be clear, I'm not fond of pseudo-C in Ruby itself and I'm personally fine with annotating C methods just using C. But that's what @ko1 (Koichi Sasada) has objected to. So please talk to him about why.

[Eregon (Benoit Daloze)]

@ko1 (Koichi Sasada) Could you reply to this?

I feel C code in the middle of Ruby code is not so great, and if moving C code to strings in Ruby is just to add Primitive.attr! 'inline' (like for Float#zero?),
it seems much simpler and nicer to add rb_impl_define_method_inline() or so (private API, not public C API of course).

For instance, there is no syntax highlighting for C code in Ruby code (Primitive.cexpr! 'flo_iszero(self) ? Qtrue : Qfalse'), looking at callers of flo_iszero() would only reveal generated code, not the Primitive.cexpr!, etc.

[ko1 (Koichi Sasada)]

1. be accessible to C extensions

I think it is better but not sure we can.

2. can't be re-written any faster in pseuso-C in Ruby

Do you mean Cython for Python?

3. has an easy way to define keyword parameters?

I believe the easiest way to write keywords is written in Ruby.

I feel C code in the middle of Ruby code is not so great, and if moving C code to strings in Ruby is just to add Primitive.attr! 'inline' (like for Float#zero?),

For me, for few lines I'm fine to mix Ruby and C.

[hsbt (Hiroshi SHIBATA)]

• Status changed from Open to Assigned