Project

General

Profile

Actions

Misc #17502

open

C vs Ruby

Added by marcandre (Marc-Andre Lafortune) 4 months ago. Updated 4 months ago.

Status:
Open
Priority:
Normal
[ruby-core:101881]

Description

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]]

Related issues

Related to Ruby master - Feature #16254: MRI internal: Define built-in classes in Ruby with `__intrinsic__` syntaxClosedko1 (Koichi Sasada)Actions
Actions #1

Updated by k0kubun (Takashi Kokubun) 4 months ago

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

Updated by k0kubun (Takashi Kokubun) 4 months ago

  • 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 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.

Actions

Also available in: Atom PDF