[ruby-core:101883] [Ruby master Misc#17502] C vs Ruby

Issue #17502 has been updated by 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 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 for JIT optimizations, and therefore we confirm VM performance is not degraded. Because it's very important that annotating a method doesn't make the method slower, the current situation where presudo-C in Ruby 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 and I'm personally fine with annotating C methods just using C. But that's what @ko1 has objected to. So please talk to him about why.

----------------------------------------
Misc #17502: C vs Ruby
https://bugs.ruby-lang.org/issues/17502#change-89725

* Author: marcandre (Marc-Andre Lafortune)
* Status: Open
* Priority: Normal
* Assignee: ko1 (Koichi Sasada)
----------------------------------------
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.

```diff
-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.

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



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>