00:00:10.880
Good morning! Welcome to RubyKaigi Day Three.
00:00:15.960
Can we get some applause? This session is going to need your interaction.
00:00:24.779
This session is called Ruby Kaigi Committers and the World, and it’s sponsored by Shopify, where I work.
00:00:30.900
My name is Gemma. If we haven't met yet, I would love to meet you at some point. It's going to be a very exciting session.
00:00:37.860
We have all the committers on stage right here in their blue t-shirts. There are two main goals for this session.
00:00:43.860
One is for the committers to share their thoughts about the future of Ruby 3.3 and specific things they're working on. The other goal is to allow for audience interaction.
00:00:50.879
Please interact with us as much as you'd like. There will be some space at the end where we will ask for audience questions.
00:00:57.719
If you have something you want to ask, start thinking about it now.
00:01:03.480
To the committers, we don't have live Japanese to English translation, but if you need to speak in Japanese, please feel free to do so.
00:01:09.960
We have a few volunteers among you who will be live translators.
00:01:17.040
There will be four parts to this session. First, we'll introduce the new Ruby committers who have joined since last RubyKaigi.
00:01:23.400
We'll allow them to say a few words about themselves. Then, we'll ask some of the committers to share their hopes for Ruby 3.3 and elaborate on those wishes.
00:01:30.720
Next, we'll allow for some open discussion, and finally, we'll take audience questions.
00:01:38.340
If you're here in person, there's a microphone set up, and if you’re virtual, please feel free to write into the chat.
00:01:51.899
Okay! We have two new Ruby committers.
00:01:57.259
The first, Matt, will you come introduce yourself, please?
00:02:10.319
Hello, everybody! My name is Matt. I work for Shopify in the Ruby on Rails infrastructure team.
00:02:17.099
I've been working on CRuby for nearly three years now and I'm very proud to say that I'm now a committer.
00:02:22.860
I look forward to working with you all. I'm going to be predominantly focused on garbage collection and memory management for the near future. Thank you.
00:02:28.620
Thank you, Matt! Next up we have...
00:02:46.920
Okay.
00:02:49.600
I contributed our regular expression matching optimization.
00:03:12.840
Thank you! For the next part, we'll go over wishes for Ruby 3.3 which are grouped by category.
00:03:18.780
First up, we have wishes for performance.
00:03:24.060
Maxime, can we ask you to start by talking about your wishes?
00:03:30.900
Sure! I think much of the strength of the Ruby programming language is in its method calls.
00:03:37.140
It lies in the variety of ways you can call a method with different types of arguments and blocks.
00:03:44.159
This user-friendly approach also brings a lot of underlying complexity.
00:03:51.299
So far, this complexity has made it difficult to improve performance.
00:03:56.400
I believe we should find ways to make Ruby method calls perform faster, which could unlock significant performance boosts.
00:04:01.560
That's my wish for Ruby 3.3. Thanks so much!
00:04:21.540
Aaron, would you like to share your thoughts?
00:04:28.580
I disagree. I think Ruby should go slower.
00:04:34.919
This may be a controversial opinion right off the bat.
00:04:41.340
Coco, would you mind sharing your thoughts as well?
00:04:46.620
The design is pretty great for optimizing compilation speed.
00:04:52.320
However, we sometimes overcomplicate things and don't experiment enough.
00:04:59.759
We should spend time experimenting with complicated optimizations to avoid missing important improvements.
00:05:05.639
I'm looking forward to optimizing performance for production workloads.
00:05:11.699
If you are interested, please come to my talk today.
00:05:17.280
One thing I want to try is method designing.
00:05:23.400
The difficulty in syrup is that there are many sequels within the generated C function code.
00:05:28.440
When you create a C function code that calls another method, it complicates the optimization.
00:05:34.560
For lazily optimizing or de-optimizing, more robust methods are needed.
00:05:41.460
We're looking into allowing some lazy optimization techniques.
00:05:48.620
Alan will explain how we could push the frame inside these C functions.
00:05:54.419
I'm excited about developing this capability, as it could lead to better methods in Ruby.
00:06:01.139
Okay, let’s recap.
00:06:07.020
We've touched on some vital points regarding performance optimizations.
00:06:14.639
Performance optimizations in different workloads and our compiling strategies matter.
00:06:20.679
Could we implement tiered JIT compilation? That's another question worth exploring.
00:06:25.080
We need to discuss how to implement optimizations to keep Ruby efficient.
00:06:32.640
Let's explore more ideas before wrapping up this session.
00:06:38.280
Now, I would say let's open up the floor for the next topic.
00:06:44.160
On garbage collection, Peter, would you like to share your insights?
00:07:00.000
My topic revolves around a self-tuning GC that adapts to different workloads.
00:07:10.500
For example, at Shopify, we face high latency due to the GC impacting the P99 and P99.9 response times.
00:07:18.500
The generational garbage collector separates old and young objects.
00:07:25.600
In typical applications, old objects often remain static while young objects are created during requests.
00:07:32.819
We ideally want to avoid running a major GC and only execute minor GCs.
00:07:40.569
Benchmarks tend to be toy applications that do not reflect production environments.
00:07:47.670
In production Rails apps, major GCs can last several seconds, resulting in a high penalty.
00:07:54.040
By conducting benchmarks in high-traffic Ruby Rails apps, we learn how production works.
00:08:01.480
Those insights can guide us to make Ruby's GC more adaptive and capable for larger apps.
00:08:08.880
My colleague Jean and I are working on tuning the Shopify monolith, which is the world's largest Ruby app.
00:08:14.560
We found numerous optimizations that could impact large-scale Ruby apps significantly.
00:08:20.539
We've just gotten started, and I'm optimistic about exciting new features for Ruby 3.3.
00:08:27.820
These enhancements will help large Ruby on Rails apps see improved P99 and P99.9 response times.
00:08:41.640
Thanks, Peter. Next up, we have Samuel.
00:08:47.600
One of the biggest challenges with scalability in Ruby is creating many threads or fibers within a single process.
00:08:55.000
When we create many fibers or threads, we incur numerous stacks necessary for executing those threads or fibers.
00:09:01.660
When garbage collection runs, it scans every stack, and this creates performance issues.
00:09:07.800
If we can identify that a fiber or thread has not been active since the last GC, we should avoid scanning that stack again.
00:09:14.220
This approach can significantly improve performance.
00:09:20.900
For example, creating 100,000 threads or fibers could lead to a GC time of around 500 milliseconds.
00:09:27.920
This performance issue presents a considerable barrier to scalable Ruby usage.
00:09:33.780
I'm working with Joyce Chen, a student on Google Summer of Code.
00:09:40.799
We will collaborate on this problem and see if we can achieve significant improvements. Thank you!
00:09:53.520
Hello! Some topics are closely related to what Peter mentioned.
00:10:01.320
There is significant work being done on fibers.
00:10:09.760
I feel that for the foreseeable future, most applications will continue to use threads.
00:10:15.080
There remains a limit to concurrency in Ruby due to the Global VM Lock (GVL).
00:10:22.080
Memory usage remains a significant complaint regarding Ruby.
00:10:29.980
A potential way to reduce this memory usage, especially when using forks, is to be copy-on-write friendly.
00:10:35.880
This means any memory that was initialized before the fork and remains untouched can be shared.
00:10:42.759
My wish for Ruby 3.3 and later is to refactor parts of the VM, especially the garbage collector, to avoid writing to existing regions when not necessary.
00:10:49.840
Peter mentioned in his talks that most objects are created at boot time.
00:10:56.120
If an object in one page of Ruby objects can be garbage collected, but others are immutable, freeing that slot may cause harm.
00:11:02.780
Instead, it would be wiser to abandon that slot and leave the page unchanged.
00:11:09.780
This approach can essentially free memory quite significantly. Thank you!
00:11:18.600
Good morning! Before discussing localization, I want to emphasize that last year we held this session.
00:11:25.060
This year, Shopify is sponsoring this session.
00:11:32.440
Please understand that this contributes to ongoing development.
00:11:39.200
This collaboration is crucial to Ruby's growth as an open-source project.
00:11:46.920
I think it's fantastic to have this English session, and clear discussions are important.
00:11:53.720
As Samuel pointed out, scalability in Ruby needs addressing regarding the garbage collection.
00:12:01.040
It is absolutely true that garbage collection impacts performance.
00:12:09.600
We need parallel garbage collection, which could mean significant advancements for Ruby.
00:12:16.560
We can more effectively manage memory and allow ruby to scale better.
00:12:23.460
I'm optimistic about this year and next year; I'm sure we'll see great achievements in Ruby.
00:12:31.200
Thank you.
00:12:38.050
Next, we discuss parsing.
00:12:41.900
I believe there are significant advancements in the parsing technique.
00:12:54.120
I plan to absorb ongoing contributions and feedback from Ruby developers.
00:13:08.560
Our team is actively working on enhancing the Ruby parser.
00:13:16.280
We're primarily focusing on optimizing regular expression matching capabilities.
00:13:23.850
Our goals include making it more effective in handling complex regex patterns.
00:13:29.550
Optimizing around these metrics can vastly improve performance.
00:13:34.800
I'm excited to collaborate with everyone toward this vision!
00:13:40.280
We can analyze popular patterns within the Ruby community and streamline that process.
00:13:45.440
I want to encourage everyone to join in if you have any thoughts or contributions to parsing.
00:14:02.500
This involves thinking about forward planning replacements.
00:14:09.000
The relationship between relevant features and usability matters!
00:14:16.800
Having a more user-friendly parser is a hot priority.
00:14:22.820
Enhancing usability speaks volumes about Ruby's flexibility.
00:14:27.040
Let's have an open conversation around improvements and strategize an effective plan.
00:14:33.060
Who wants to partook in ideas around the user experience?
00:14:39.840
Share your thoughts openly, please!
00:14:44.360
Let's look deeper into our implementations and how we can go about improvements.
00:14:59.800
How to handle regular expressions efficiently is also a crucial point.