Ractor reconsidered

by Koichi Sasada

In this presentation titled "Ractor Reconsidered" at RubyKaigi 2023, Koichi Sasada discusses the current status of the Ractor system in Ruby, its challenges, and potential areas for improvement. Ractors were introduced in Ruby 3.0 to enable parallel computing, overcoming limitations posed by the Global VM Lock (GVL), which prevents threads from running in parallel. However, the adoption of Ractors has been slow due to several barriers.

Key points include:

- Ractor System Purpose: Ractors facilitate parallel programming by isolating object spaces, thus avoiding common issues related to mutable shared states.
- Performance Challenges: The current performance of the Ractor system can diminish during garbage collection, where all Ractors are paused, causing overhead and latency.
- Knowledge Barrier: The programming model required for efficient use of Ractors entails a level of understanding that isn't yet widespread.
- Implementation Quality: The existing implementation of Ractors requires enhancements to ensure more robust and productive usage, as some complexities remain in the message passing API.
- Future Development: Sasada emphasizes ongoing projects targeting improved garbage collection and more efficient native thread usage to boost the Ractor performance.

In conclusion, while Ractors present a promising approach to concurrent programming, their current challenges necessitate community collaboration and strategic improvements to make them more viable and widely adopted within Ruby programming. Sasada invites participants to engage further in discussions during breaks, highlighting the importance of community contributions to the evolution of Ractor systems.

00:00:04.200 Foreign.

00:00:09.260 Good afternoon, and thank you for coming to my presentation.

00:00:11.519 Today, I will talk about the Ractor system, or simply put, Ractor.

00:00:17.060 We introduced Ractors in Ruby 3.0.

00:00:20.699 I want to review the current status and introduce our recent achievements and future work.

00:00:44.300 Honestly speaking, the Ractor system is not used widely.

00:00:51.059 There are some barriers, difficulties, and issues that I would like to discuss in this presentation.

00:00:54.120 I believe that to solve these issues, we first need to improve the performance of the interpreter.

00:01:18.720 In recent years, I have continued to work on improving this performance.

00:01:27.740 Today, I want to show the current status of these improvements.

00:01:33.920 Basically, I have been working on Ruby core, focusing on the virtual machine, garbage collector, and the memory management system for the Ractor system.

00:01:47.700 I am also the author of the debug gem and a member of the Ruby BBS Association.

00:02:00.659 There are great sponsors at the sponsoring area, so please stop by our sponsor booths.

00:02:12.560 I won't be attending RubyKaigi tomorrow because I need to return home tonight, but please feel free to approach me during the next break if you have any questions.

00:02:30.480 So, this is the basic idea: Ractors were introduced in Ruby 3.0 to enable parallel computing.

00:02:37.739 However, there is a Global VM Lock (GVL) that prevents threads from executing in parallel, which limits concurrent computing capabilities.

00:03:10.140 Ractor enables parallel programming on Ruby and can lead to faster Ruby applications.

00:03:15.060 Moreover, Ractors support robust concurrent programming, which is essential because managing shared mutable states between concurrent entities is challenging.

00:03:24.900 To avoid issues related to shared mutable states, we need to handle the Ractor system carefully to enjoy bug-free parallel programming.

00:03:43.980 While Ractor programming looks promising, its adoption has been slow due to several challenges.

00:03:58.799 Some difficulties stem from the programming model; Ractor requires additional knowledge that is not mature or widely understood.

00:04:11.459 Additionally, the current implementation quality could be improved.

00:04:18.660 So, I want to discuss these challenges today.

00:04:40.680 In summary, Ractor provides a way to avoid bugs common in concurrent programming by isolating object spaces, where most objects are unshareable.

00:05:01.860 If an object belongs to one Ractor, other Ractors cannot access it, which helps avoid concurrent bugs.

00:05:17.640 However, to maintain this isolation, we might need to introduce some limitations in the Ruby language.

00:05:53.639 To achieve compatibility with Ractors, there are some complex memory model constraints and limitations.

00:06:28.560 The message passing API in Ractor has two types: the traditional actor system, which uses send and receive, and a more advanced style that requires both sender and receiver to communicate simultaneously.

00:06:55.340 The latter style, while powerful, introduces complexity, particularly when integrating with multiple Ractors.

00:07:51.259 To maintain object isolation, we must ensure that message passing avoids unintended sharing of mutable states.

00:08:31.300 While Ractor offers benefits for concurrent programming, the current implementation quality may hinder its widespread usage.

00:09:44.740 Maintaining Ractor systems can lead to performance degradation, especially during garbage collection, where we need to stop all Ractors to reclaim memory.

00:10:03.480 This can introduce considerable overhead and latency, making it challenging to maintain efficient performance.

00:10:35.040 To improve performance, I am focusing on various projects to enhance Ractor, including better garbage collection mechanisms and more efficient usage of native threads.

00:11:34.799 In conclusion, while Ractor systems may currently face challenges, there are opportunities to improve their implementation and performance in the future.

00:12:01.480 Moving forward, collaboration and contributions from the community will be vital for enhancing Ractor systems.

00:13:03.300 Thank you for your attention, and I look forward to your questions.