Ruby Video
Talks
Ruby Committers and The World
Ruby Committers
11 talks
#ruby-committers
#garbage-collection
#ruby-3-3
#performance
#ruby-implementations
#optimization
#community
Summarized using AI

Ruby Committers and The World

by Ruby Committers

The video titled 'Ruby Committers and The World' features a session from RubyKaigi 2023, hosted by Gemma from Shopify, focusing on the future of Ruby, particularly version 3.3. The session is interactive, encouraging audience participation.

Key Points Discussed:
- Introduction of New Committers: Two new Ruby committers, Matt and another, introduce themselves and share their roles, particularly focusing on garbage collection and regular expression optimization.
- Performance Optimizations: A crucial theme is optimizing Ruby's method calls and garbage collection.
- Committer Maxime emphasizes the need for faster method invocation to enhance Ruby's performance, while Aaron presents a contrarian view advocating for a slower approach, highlighting the complexities involved.
- Coco and Alan discuss challenges and opportunities in improving compilation speed and exploring more robust methods for optimization.
- Garbage Collection Insights: Peter highlights the challenges his team at Shopify faces with garbage collection impacting response times. He proposes adapting garbage collection strategies based on application workload to minimize latency.
- Concurrency and Scalability: Samuel addresses the issue of scalability with Ruby's threading model, proposing to refine garbage collection processes to enhance performance for numerous threads. Jean builds on this by suggesting refactoring parts of the virtual machine to improve memory sharing post-forking.
- Localization and Community Engagement: Koichi encourages community participation to boost Ruby’s evolution and highlights the importance of collaboration in Ruby’s growth, especially concerning parallel garbage collection.
- Parser Improvements: Committers touch on advancements in regular expression parsing, with goals to enhance performance and usability of the Ruby parser, inviting community feedback for ongoing developments.

Conclusions and Takeaways:
- Audience engagement is vital for the success of Ruby's development.
- Ongoing discussions highlighted the commitment of the Ruby community to tackle scalability, performance, and memory management issues in Ruby 3.3.
- Collaboration and community involvement are emphasized as key drivers for Ruby's future enhancements.

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.
Edit
Explore all talks recorded at RubyKaigi 2023
+47