Talks
Speakers
Events
Topics
Sign in
Home
Talks
Speakers
Events
Topics
Leaderboard
Use
Analytics
Sign in
Suggest modification to this talk
Title
Description
Japanese: https://youtu.be/rE5OucBHm18 In Ruby 2.6, we started to use a JIT compiler architecture called "MJIT", which uses a C compiler to generate native code. While it achieved Ruby 3x3 in one benchmark, we had struggled to optimize web application workloads like Rails with MJIT. The good news is we recently figured out why. In this talk, you will hear how JIT architectures impact various benchmarks differently, and why it matters for you. You may or may not benefit from Ruby's JIT, depending on what JIT architecture we'll choose beyond the current MJIT. Let's discuss which direction we'd like to go. RubyKaigi Takeout 2021: https://rubykaigi.org/2021-takeout/presentations/k0kubun.html
Date
Summarized using AI?
If this talk's summary was generated by AI, please check this box. A "Summarized using AI" badge will be displayed in the summary tab to indicate that the summary was generated using AI.
Show "Summarized using AI" badge on summary page
Summary
Markdown supported
In this talk presented at RubyKaigi Takeout 2021, Takashi Kokubun discusses the performance challenges associated with Ruby's Just-In-Time (JIT) compiler, specifically the MJIT architecture introduced in Ruby 2.6. Despite the claim in Ruby 3.0 of achieving a threefold performance increase over Ruby 2.0, the actual real-world performance, especially for web applications like Rails, remained suboptimal. The main points covered in the presentation include: - **Introduction to MJIT**: Kokubun explains how MJIT uses a C compiler to generate native code, allowing for potentially better performance but also introduces complexity. - **Benchmark Performance**: The JIT compiler showed impressive results in synthetic benchmarks such as OptCarrot, but these do not reflect typical web application workloads. Ruby's performance when using the JIT compiler was generally slower than running under the virtual machine. - **Configuration Adjustments**: Performance improvements were possible through careful configuration; increasing the maximum cache and methods allowed for the JIT compiler can lead to approximately 5% better performance in Ruby 3.0, but still not being the default. - **Architectural Issues**: The presentation details design flaws within the MJIT architecture that contribute to slow performance. Key issues include inefficient memory allocation for compiled methods and high cache pressure from non-adjacent method placements in memory. - **Compilation and Warm-Up Time**: Long compilation times—exceeding five minutes for benchmarks in Rails—hinder the usability of the JIT in production applications, especially during the warm-up period when system resources are strained. - **Impact on Applications**: The slow compilation and warm-up compromise the performance needed in competitive programming and real-time web applications, where efficiency is critical. - **Future Considerations**: Kokubun emphasizes the need for better JIT architecture to compete with other dynamic languages like Python that currently have stronger JIT implementations. - **Collaborative Efforts**: There’s a call for collaboration within the community to learn from different JIT implementations to enhance performance collectively. In conclusion, while there have been strides made in Ruby's JIT performance, ongoing efforts are necessary to ensure that it can meet the demands of modern web applications effectively and maintain competitiveness with other programming languages. The talk highlights the significance of choosing the appropriate JIT architecture and making necessary adjustments for improved performance.
Suggest modifications
Cancel
